Instalar Steam
iniciar sesión
|
idioma
简体中文 (chino simplificado)
繁體中文 (chino tradicional)
日本語 (japonés)
한국어 (coreano)
ไทย (tailandés)
Български (búlgaro)
Čeština (checo)
Dansk (danés)
Deutsch (alemán)
English (inglés)
Español de Hispanoamérica
Ελληνικά (griego)
Français (francés)
Italiano
Bahasa Indonesia (indonesio)
Magyar (húngaro)
Nederlands (holandés)
Norsk (noruego)
Polski (polaco)
Português (Portugués de Portugal)
Português-Brasil (portugués de Brasil)
Română (rumano)
Русский (ruso)
Suomi (finés)
Svenska (sueco)
Türkçe (turco)
Tiếng Việt (vietnamita)
Українська (ucraniano)
Comunicar un error de traducción
Normas y directrices sobre discusión
9 
Denunciar este mensaje
Distant Worlds 2 is easily at the top of my list; I've been waiting years for this one. Rounding out my top three are Knights of Honor II: Sovereign and Horizon 2.
Other 4x/GS games I'm anticipating: Alliance of the Sacred Suns, Grand Tactician: The Civil War, Remnants of the Precursors, Star Dynasties, and Stellar Monarch.
Games I'm somewhat looking forward to, yet I'm also cautious/somewhat ambivalent: Galactic Ruler, Humankind, and Old World.
Games I'm strongly anticipating, but haven't been announced yet: Galactic Civilizations IV and Warhammer III. Personally, I doubt either one will be released in any form until at least 2022 (sadly).
I'm looking forward to pretty much all the titles listed on Rob's "post-2021" games, albeit with varying degrees of interest/excitement. Lord of Rigel remains my favorite conceptually, but it's been in development for so long now that I'm concerned as to how it will look once it finally reaches beta/EA. And like Rob, I'm disappointed with the pace of progress on Dominus Galaxia; I'm already worried this one will never be finished.
KoH2 is already at the top of my wishlist. I'm just waiting to add DW2 and Horizon above it. ;)
Not to give you false hope, but Brad posted this[forums.stardock.net] in the Stardock forums last week:
So....maybe?
Gods, please no. If Stadrock implements a 1upt system, the game might as well not have combat, then.
I'm not so certain of that. Brad almost added tactical/instanced combat to GC3, and given some stuff he's said on the forums and social media the last 12-18 months, it's pretty obvious he's seriously considering it for GC4.
I think some of you forgot that Draginol created this topic in the GC3 discussion, which has accumulated 260+ responses since its creation: https://steamcommunity.com/app/226860/discussions/1/1798529872650018441/
That doesn't guarantee combat in GC4, but its clear they're aware and have been thinking about it and how it might work at the strategy and instance layers IF they were to do something, seeing what the community wants/desires, etc. They aren't promising anything, but they'd be crazy not to consider it as there's a lot of GC fans that want combat in the game, myself included.
I understand folks not wanting more combat, and for you I hope they have auto-resolve and auto-resolve + watch kind of like now but with more polish. Combat in GC4 should be a thing, I would be fine with 1UPT or WEGO honestly, I could envision both working well in my head at least and I realize what I desire goes against the grain of many of the hardcore folks here, and that's fine by me. I believe Stardock could pull it off and appease most folks, might take a few patches and adjustments but they could get it done should they choose to do so.
The GC haters will likely continue hating GC regardless. The combat haters will hopefully be appeased with an easy button. Or maybe Stardock can implement something fun. I'd like to see ship design be far more useful in GC4 for combat and roles, I might use it more.
There's also plenty of other aspects they could improve on GC while still keeping it GC. GC4 sure as hell doesn't need to be a carbon copy of GC2 or 3 to be a legit GC game, change is sometimes good and a lot of the changes during the last few years of GC3 development up to this point were improvements IMHO. For such a busy game, it really did hook me for a while, but invasions, shitty combat leading to what I felt was fairly useless ship design when accounting for combat beyond a couple of quick simple designs.
They will hopefully take a different direction with AI so it can play all aspects of the game better in the future without as much work as was put in around the 2017-2018 timeframe.
Invasions need a lot of help. Diplomacy could use some sprucing up. There's a few areas of GC3 that were almost too vanilla...and again, I'd rather not have a copy/paste of GC2. Some might desire that, GC2 was grand for its time, but also its time to move forward and try some new things in the series.
I'd love to see SoaSE 2, wonder if Ironclad and Stardock will get it done for 2021. That'd be epic. SoaSE is showing its age so much now, and its lost its luster for me after so many years and hundreds of hours. But damn is it a classic I will always recommend folks checking out RTS and wanting to dip their toes in some light 4X. I hope SoaSE 2 steps up the complexity a bit on the empire development side.
I've yet to try Horizon, and hearing more about 2 and the praise some of you give the first I am tempted to try it. As rough as I've heard it is, not sure I'll enjoy it. Also not sure I'll make time to play it in my current lineup of CW4, Hades when I play solo and Mindustry, BAR and Elite with my sons.
I'm also an RTS fan, so real-time combat would be fine too. I'm a fan of the SotS-styled instance combat, the IG2 combat, etc. I could see that working here too, but I'd expect far more people would be unhappy with that versus turn-based.
Not sure I'm interested in the Madden-lite play calls for spaceship battles though, but none of the ES games ever really kept me engaged or interested even outside of combat. Ironically I did enjoy GSB. And I can envision something like that, maybe a hybrid with a NuMoO style real-time combat.
If they're going to go that route, the commands and choices need to really count and make a difference. Maybe even have a cost, limit, recharge, etc. If you could maybe design your own "plays" or "routes" or whatever that could be an interesting mechanic that engages players just enough but doesn't make combat burdensome, especially in the late game. Though I would hope that we have admirals leading fleets that gain experience and boosting fleet ratings, etc. and maybe that's when you can start designing your "playbook" in such a scenario. Definitely interesting to think about.
As-far-as invasions, you're right...its generally a numbers game. And while I applaud Stardock's effort for trying something, the dot invasion just seems silly overall IMHO. I'd rather see actual battles like IG2 or go back to abstracted numbers game (meh). But depending on how much they went down this rabbit hole (assuming not far enough to show actual battles), they'd have to find a way to streamline this part to avoid getting bogged down late game and those that don't want to deal with this would need some way to effectively auto-resolve without it being unfair. Probably not worth the effort versus going back to the numbers game in all reality.
It is order based (like Dominions for example) and It's the perfect middle ground between wanting to have high level control and decisions but then have it all executed in an actual true tactical space as an auto resolve. It's perfect for those wanting some critical input (waaaaay better than ES2) but not having to actual fight out the battle.
I still maintain that Starbase Orion has some of the most clever ideas of any 4X game.
Not against that idea of pushing pre-planning + auto resolve I suppose if its executed in a way that's engaging, and sounds like SO does just that.
Edit: Looked into it, I'm not an iOS user and looks like their kickstart to port to Android and PC didn't make it. But I found a video showing a battle: https://youtu.be/jQsAaJrvGqM?t=240
Hmm. I could see something like that working with a little more depth and polish, and maybe the example I found quickly is a poor one. But for a mobile 4X that looked pretty decent.
* Rising Lords (Medieval 4x Strategy Game)
* Space Haven (Sci-fi Ship Building & Crew/Colonist Management)
* Suzerain (Text-based Political Simulator & RPG)
....caught my attention.
https://www.youtube.com/watch?v=eYaW1nvDI3E
The game could use more content, but it's very well polished for EA.
Rob et al, thanks for the main article! Was surprised to see it but not complaining in the slightest. :)
For whatever it’s worth, I am as well.
Brace yourselves, this is going to be a long post. Some of this will be recapping previous KS posts, and some of it will be new information. As much as I love you Martok, I'm not just writing a 3700 word reply for your benefit ;) Odds are a version of this will be made into a KS update.
Before I go falling on my sword however, I should defend myself a bit. In 2020 DG saw nearly 30 updates, albeit with around a quarter of those being smaller hotfix-style patches. Either way, it’s not a small number.
Huge improvements were made to the backend. Game logic is disentangled from the Unity Engine and turn processing occurs on a background thread. Even in the AAA space, that’s pretty rare for Unity games where it’s not unusual to see framerate stutters or outright pauses when there is heavy gameplay logic.
Compared to the initial KS build, turn processing times are at least four times faster. Part of that is the above disentanglement, part is various optimizations, specifically to pathfinding, and some limited multithreading of critical paths, and part is rewriting a few of the least performant portions of the AI.
The other big improvement is mod support (Ivan deserves a lot of credit here), which is now very robust indeed. There’s an in-game UI where you can enable and disable mods at runtime, as well as changing the order with which they load. You can also add new mods without restarting the program. Somewhat related, but more functionality is exposed now in the data files.
Not quite as significant, but Galaxy generation also saw huge improvements to speed, placement, and robustness as well. There is some limited multithreading here, and from a technical purely perspective the algorithm seems pretty close to perfect, if not a bit overkill. The old algorithm, for instance, would invariably fail if you tried to place too many empires in too small of a galaxy. The new one is designed so that it should never fail any scenario. The old algorithm also had trouble picking reasonable starting locations on non-standard shapes while the new one works equally well on even the most convoluted shapes.
There are smaller items, like object pooling for many UIs to increase responsiveness, as well as a host of other backend improvements on the admittedly oft-delayed combat branch. For example, combat events can execute in parallel. So, if we take an edge case scenario where you have hundreds of combat events in a single turn what might have otherwise taken a minute to process may complete in less than a second on, say, a 64-core Threadripper.
Regardless of any technical progress not that much has been accomplished that’s actually user facing. Off the top of my head:
-You can build system defense ships that don’t have warp drives and therefore can’t move on the galaxy map, but are much hardier than usual.
-Rally points can be chained together, so that if you have ten colonies rallying to a single point, you can then redirect everyone by rallying from that point to somewhere else.
-All races are playable, although the ones without finished graphics borrow from the ones with finished graphics.
-Instead of a hardcoded ship design limit of 5, this is adjustable in advanced options. This required some UI effort as well as time to make it work properly in combat. It was probably the most requested feature from non-MoO 1 players, but didn’t do much for MoO 1 vets since they already don’t mind the limit. As an aside, the new most-requested feature is refit, which probably won’t do much for MoO 1 vets if it ever comes to pass either.
-There’s a button in ship design to let the AI auto-fill a design for you.
-Lastly, or at least the last thing I can think of (I may be missing one or two minor items) is modding support, but this really depends on the community. So far, a few mods have been created, but most are minor and as far as I’m aware none have captured much community attention.
Taken as a whole, these are hardly significant additions compared against a year of development. And while the bugfixes, speed improvements, and increased stability might feel impactful when compared directly against the initial KS build, the same isn’t true when spaced over the course of a year and a bit.
And here’s where I fall on my sword, so to speak. The upcoming combat rework has proven to be both a bigger task than I anticipated, and at many times has been difficult to find the motivation for thanks to the immensity of all the various interconnected systems, UIs, Ais, and content that needs to come together to make everything work. The amount of work needed here is more or less the same as making an entirely new (albeit much smaller) game. Truth be told, with better motivation I’m sure I’d be finished it by now, so that blame lies firmly on my shoulders.
Part of the motivation equation is necessity, where necessity helps drive results. This was a factor in previous estimates for the combat patch. Since I tend to err towards looking at the worst case I assumed that necessity would drive me to complete the work by a certain time. In reality, things worked out better than I had anticipated for living expenses, which depressed that factor of motivation. Even though this “necessity” factor is coming into full force now, I’m hesitant to give an exact eta for the combat patch after missing previous estimates.
While there’s been a measure of scope creep, the initial and far larger delay was one of technical creep. The legacy combat system has become a bit messy over time. It’s firmly entrenched in the “Unity way” of doing things, which itself wouldn’t be too terrible even if it’s not the greatest, except that on top of this “auto resolve anywhere, anytime” and “background events use all of the same systems” got bolted on. Don’t get me wrong, these are great features and DG would be a far worse product without them, but building them onto a system that was never designed to accommodate them required a large helping of duct tape and black magic.
I didn’t set out with the goal of rewriting the entire combat system, but that’s what happened anyway. “I’m adding a feature and touching this system anyway, but I don’t like this thing here so I should tidy that up,” but then that system touches another system, and so on and so forth.
The rewrite wasn’t just divesting combat logic of the Unity API, but also changing many things fundamentally work. For example, in the legacy combat system line casts are used to determine things like “is an asteroid blocking this shot?” or “how much of an accuracy penalty should I suffer for firing through nebula tiles?” Pretty much all of these have unfortunate edge cases, but the later is an especially tricky thing since if you just add up all the tiles that a line intersects to determine the accuracy penalty you might arrive at a larger-than-intuitive number since some of those intersections may be tiny. The legacy system attempts to work around this, but it isn’t perfect.
The new system, on the other hand, doesn’t use line casts, and doesn’t use the Unity physics library for anything. It’s all just hex math now (much thanks to my friend Fabian, who is a mathematician, for an abundance of help here). The intersection maths are especially complex but allow for some really cool details that people will never notice (in this case, not noticing is a good thing). Taking the above scenarios, in terms of asteroids blocking shots what is now possible is that if the line intersects the boundary (as opposed to the interior) of a hex with an asteroid, the shot is allowed, but if it intersects the boundary of two or more such hexes the shot is blocked. Regarding firing through nebula tiles, the new combat system just adds all the lengths of intersections with nebula tiles (while only counting shared boundary once) and rounds to the nearest whole number.
Missiles and torpedoes, which exist somewhat outside and inside the hex grid at the same time, were a giant mess previously, but are now very robust.
One depressing issue with the new system, which is now fully MVC (model, view, controller), was that getting the view (In this case, the script that displays the 3D model of a combat unit) to follow the model (which informs the view of where and how to render) didn’t quite sync up. So, instead of a ship moving smoothly to a new hex it would judder and skip. Worse yet, I discovered this was a fundamental issue with the Unity engine itself (this can also be seen in the GNN chiron if you play close enough attention!) It was a big let down since a lot of work was needed to get to that point only to find such a glaring issue with no straightforward solution in sight. Thankfully Unity 2020.2, which was released in December, fixes such timing issues on most platforms so the animation is once again smooth.
To recap some of the upcoming combat changes quickly, the big improvement is that all types of ship equipment have a significant number of dials and knobs now, since the goal is that no equipment should need to be a +1 of previous versions. Shields, for example, have a massive degree of functionality (so much that I might end up taking some away if it ends up too overwhelming). You can still define a shield that functions exactly like it would in MoO 1, but by default shields now have HP, regeneration, bleed through, power consumption, and so on. Armor and shield DR is tracked separately, so some weapons are better against armor while others fare better versus shields. Weapons have a great deal of new functionality also, the biggest additions being firing arcs and per-hull size accuracy adjustments. In other words, that big death ray might be amazing at taking down big targets, but rather ineffectual against even a single small craft—think of the Death Star laser trying to down an A-Wing. This goes hand-in-hand with a primary goal of the rework, which is to have strong (but organic) roles for ship sizes and designs.
In any case, this new functionality necessitated some UI rework as well. Most significant is the ship designer, and specifically the equipment picker inside of that. Be warned, this might get a bit technical. In the live version of Dominus Galaxia, there are two presets for the equipment picker: One for weapons and one for everything else. For “everything else,” the “description” column is used to convey information that probably should have its own column, since equipment largely only does a single thing. For example, a Mk IV shield would just say in its description something like “blocks four points of damage.”
In the development version, this wouldn’t do. Instead of making a distinct UI for each type of equipment, these are now defined in code and generated at runtime. So, the code says “For this type of equipment, I’ll have these columns, with this width, and I’ll populate the columns with this data. When the column is selected I’ll sort the items in such and such a manner.” Then pools (“pooling” means reusing objects instead of expensively creating new objects all the time) for each type of equipment are generated. On top of that some items can be customized, so instead of having a “Nuclear Missile-2” weapons with 2 ammo, and a “Nuclear Missile-5” item with 5, you now just have a Nuclear Missile and you select the amount of ammo to go with that launcher. Presently by default, this is between 1 and 10, although these bounds are driven by the definition of each weapon in data.
Most likely, this rewriting and refactoring and of the codebase wouldn’t be worth the effort versus just adding features to the existing source. It’s understandably created some discontent among those that would prefer to see faster and more visible progress. I can’t help but to agree with that criticism, since I too shared this desire. Drifting towards the technical side of things wasn’t a totally conscious choice, but rather happened in bits and pieces, and from where I’m standing now, I’m pretty sure it was ultimately the wrong choice.
What might change the equation is the ultimate goal all this is converging towards, if we ever get there, which is a “client-server” approach to turn processing. This doesn’t literally mean that there’s a server and you need an internet connection to play (it will always be the case that you can play offline), but rather that turn processing is done on one machine/task/thread, while each empire is perfectly encapsulated on their own machine/task/threads.
The idea is that is an agnostic approach to whether these elements are running on the same or different machines. It’s something of a holy grail for me and I’m unaware of any other 4X that has reached, or is even trying to reach, such a technical height (admittedly, the design of many 4X games makes this idea untenable. You absolutely need a dedicated movement phase). Unlike many technical achievements, this one would be immediately palpable.
The two big outcomes would be that AI empires would all take their turns in parallel and at the same time as the player. In other words, if all AIs finish up before the player hits turn, which would likely be the case most of the time, then there would be no noticeable AI processing on the player’s end. In effect, AI processing becomes instantaneous. Since empires will be completely encapsulated from one another with no shared data, you can get more-or-less perfect scaling as you add resources. If you want to geek out a bit, imagine playing a 1000 empire game of DG on a 64-core ThreadRipper, ending your turn, and immediately arriving at the next turn. That would be pretty unreal.
The other big consequence is that this milestone almost singlehandedly enables networked multiplayer with very little additional effort (that DG already supports hotseat helps a lot here). And, because networked multiplayer and regular single player are effectively operating the exact same way under the hood, God willing, networked multiplayer shouldn’t have too many unique issues.
Keep in mind though there’s a near 0% chance that the first multiplayer builds of DG will have tactical combat in multiplayer. While the client-server architecture for the strategic layer should naturally flow into networked multiplayer, the same isn’t true for tactical combat where players are directly interacting with one another. At that point, the timeframe for multiplayer tactical combat will depend on player demand.
My rough estimation is that with all of the backend work in 2020 DG is at least half way along the road to this “holy grail.”
I’ve been hesitant, probably too hesitant, to move DG forward commercially. Both into KS, and into EA. I’ve been told a number of times that I should have been in EA a long time ago given the state of the game.
There are two prongs to this, one is accountability and the other is the financial success of the project. The former is probably self explanatory. Prior to KS, I was accountable to no one but myself. I could develop DG in whatever direction I wanted without anyone batting an eye. Post-KS I’m accountable to backers, and especially accountable to those who made significant pledges or significantly helped to signal boost the campaign.
My intuition tells me--and I don’t think it’s entirely wrong--that the way DG enters these financial stages is likely to have a huge impact on the ultimate financial outcome of the game. That, for example, $50,000 worth of art, sound, and other polish prior to EA might amount to hundreds of thousands of dollars in revenue across the lifetime of the game compared with adding that polish during the EA period. That a strong EA entrance might make the difference between being able to work on DG long term for years versus having to go some other direction. The state of the game when it enters EA will absolutely leave some degree of lasting impression, and regardless of the underlying gameplay I would much prefer a more polished exterior before entering EA.
I’ve even considered applying for jobs so that I can redirect paychecks towards this polish, despite the fact that EA revenue would likely enable the same while letting me continue working on the game full time. But the nightmare scenario is if after entering EA the game does not generate enough revenue to both sustain myself and also hire the contractors needed to polish things up.
In this context, the KS campaign was a great disappointment to me. Keeping in mind that it’s a very tough environment for any game project nowadays, and that I should probably count myself lucky for succeeding at all, I can’t help but be a bit bitter too. Truth be told, I was expecting to raise a good deal more, and the $20,000 CAD (about $16,000 USD) goal was a last minute “play it safe, just in case” alteration and originally, I was erring towards a more significant goal.
Keep in mind that I also bear some amount of blame here. Off the top of my head, I should have run a longer campaign and I should have hired an artist to help with the about section. I feel the campaign could have easily cleared $30,000 CAD if I had executed it better.
But the end result was that, while the KS didn’t accomplish much financially, it did massively increase my obligations. In hindsight, that might not have been a great trade. Regardless, I do take my obligations seriously and I intend to deliver on them. In the event I fail to deliver, which to be clear is not something I’m planning on, I intend to make the appropriate restitution to backers (specifically the high-tier ones) when I’m at the point it’s possible to do so. Again though, I must reiterate that we’re a far ways away from that scenario.
The KS created some additional discomfort because of the way the site is structured. Specifically, the $20,000 goal probably wasn’t all that realistic in terms of finishing the game. The KS rules stipulate that you aren’t allowed to ask for less than you need to finish a project. Usually, this isn’t a rule that’s strictly enforced, but from time-to-time KS does reach down and smite a project that they deem is too far outside the limit.
Personally, I think this rule is terrible and, while it might have made sense at one point in time, no longer does in the current environment where backers are hesitant to the point where the vast majority of projects fail.
Specifically, the situation for video game campaigns is so bleak nowadays that it more or less forces you to ask for much less than you need if you want to have any chance of reaching your goal, while the rules force you to pretend that what you’ve asked for is sufficient. The situation got this bad because backers are extremely jaded after being let down or misled by various projects back in the golden age of crowdfunding, and this rule is steering creators towards misleading their backers even more. That’s not helping the situation; it’s making it much, much worse.
For myself, what I wanted to say was something along the lines of “the amount I’m asking for probably isn’t enough to finish the game, but I’m hoping to exceed the goal, and if we only reach the goal we’ll probably need additional funding, either through publishers, or investors, or Early Access.” If I had said this, then in all likelihood KS would have delisted the campaign. Instead, I rationalized in two ways: First that the campaign was going to clear significantly more than the goal, making the point moot. Second, that theoretically, if everything went right, if I had perfect motivation and the money raised was spent as fruitfully as possible, then $20,000 could be enough. Of course, neither of these came to pass.
So here is where I fall on my sword the hardest. I’m a proud person, and a big part of that is an oversized, self-imposed concept of personal responsibility which includes being truthful. Suffice to say, I’m not proud of this aspect of how I conducted myself during the KS campaign. The KS rules guided me towards painting a picture that, even from the moment I launched the campaign, I felt in my heart was dishonest. At the same time, it’s not like KS put a gun up to my head and made me do it. I made the decision of my own volition, and it has weighed on me since then. Speaking about it now goes some way towards lifting that weight, but what will really help is when I have successfully discharged my obligations.
Another thing that went wrong was that my original intention was to split the KS funds between living expenses and contractors to polish things up for EA, but the second part of that never actually happened. One contractor was unavailable for a number of months, and when he did became available his prices had increased to the point that where I no longer felt comfortable directing the campaign’s limited funds in that direction. I also came close to hiring a composer, but in the end things didn’t quite align. However, as a result of our initial work together I changed music tracks to be loaded externally and added a number hooks for every event I could conceive of (eg. Combat prompt, ship designer, credits, etc.). In other words, the game is ready for a full soundtrack; one just needs to place the necessary files with the necessary names in the necessary directory.