US dollars doing some good. Happy that this is succeeding.
Average backer in for a little over $35 US. Is that par for the course for a Kickstarter campaign?
It’s about 2 years before you expect to release 1.0?
We made it! Woohoo!!!
I want to release 1.0 by the end of 2020, but I’m trying to bake in the error bars a bit. It’s really difficult to predict how long software development will take, and unfortunately it always seems to take longer than expected, and rarely less.
Congrats!
Congratulations and felicitations!
Edit: I thought I heard a huge sigh of relief a while ago. :)
Congrats! Very excited for you and the game!
Thanks all :)
Replying to a post by @inactive_user in the RoTP thread regarding multi-threaded AI. Because it’s relevant to what I’ve been doing and what I plan to do. And because it’s past time I updated this thread.
Oh, for sure. To be clear, there are all kinds of tradeoffs to consider. IIUC (and I have no actual knowledge of the nuts and bolts of the thing, just my general software knowledge and observed behavior as a player) their games process AI turns during the player’s turn, which can lead to some weird situations but does make turn times all but nonexistent and allow them to scale bigly.
So, sometimes my development process can lead me in unexpected places. For example, if I’m working on a task which has a dependency, and there’s some deficit with the dependency, I err towards improving, refactoring, or straight up rewriting that dependency before slapping on a band-aid fix.
I’m not sure if this is a good or a bad thing… probably a bit of both. But since I want to support Dominus Galaxia for a long time after release, rather than moving onto something else right away, I’d like to think it’s mostly good. I believe a lot of game programming can be haphazard precisely because it’s seen as disposable.
When I started working on improvements to space combat, I ended up going down several levels deep to the point where I ended up reworking some really base stuff.
Dominus Galaxia is made in Unity, and the Unity API is inherently single threaded and frame-based. For AI processing, this led to an unfortunate trade off: Either the AI completes in a single frame (which can look like the program has hung when that frame takes too long to render) or AI processing periodically yields so that the next frame can render (which drastically slows down AI processing, and worse yet, means AI processing speed is affected by frame-rate. Low FPS = long turn times). Dominus Galaxia used the later method, and to be honest probably not the best implementation of it either.
So, what I ended up doing was completely extracting the Unity API from gameplay logic (just for the strategic layer now), so that you have a gameplay object which doesn’t reference the Unity API, as well as a graphical object which does and also contains a reference to the gameplay object. So when, say, a new fleet is created the gameplay object is instantiated immediately, while the graphical object gets instantiated during the next frame update.
The end result is that AIs execute on their own separate thread, still sequentially mind you, but there’s no longer a need to yield to render frames. At 60 FPS, this equates to about a 50% improvement in turn processing speed, and also means that the screen will no longer judder while an AI processes its turn.
Where multi-threading will come in is with the switch to a client-server architecture (not to be confused with actual networking) where the “server” references the master game state and the “clients” (eg. human and AI actors) reference their own local state. The idea is to have every actor completely and totally encapsulated from one another while they are taking their turn. When everyone hits end turn all changes to the local state will be sent to the server for consolidation, and turn processing will occur on the master state. When that’s done, the server dispatches fresh new states to each client. This means enforcing a pretty strict order of operations, so with this approach even diplomacy will have its own dedicated phase.
In general, I’m a pretty big fan of having a tight order of operations. It was one of the nice things about Stars! I believe it encourages good design on one hand, and limits the number of novel cases that could break things on the other.
(As an aside, my biggest bugbear with certain 4X games is how loosey-goosey they are with the order of operations. Seeing someone else’s unit move on my screen as I’m taking my turn sucks, but it’s an understandable trade-off in certain multiplayer contexts. On the other hand, I don’t understand at all why you would design the single player portion of a 4X in this way except to think “You played a lot of multiplayer Civ and haven’t considered alternatives”)
In one sense, I feel that this approach might be cheating a bit–taking the easy way out. Once actors are fully encapsulated from one another, multi-threading the AI becomes a cinch. Heck, networked multiplayer (at least sans tactical combat) becomes a (relative) cinch considering DG already supports hotseat. There’s no place for synchronisation errors to crop up because there is no shared data. And on top of that, AI processing becomes an effectively embarrassingly parallel problem… assuming you populate the map with enough AIs.
In comparison, if, say, Endless Space 2 makes use of AI multi-threading, I can only imagine the kind of monumental task that would be considering that actors take their turns in parallel on a shared map.
Whatever Stardock does for GalCiv, I imagine it’s substantially more impressive on a technical level than my admittedly simple plan. I wouldn’t be surprised if each AI was itself multi-threaded, whereas for now I’m only aiming at a single thread per AI (Eventually maybe one thread for colonies, and one for fleets). And if I’m playing GalCiv and I contact an enemy and sign a peace treaty, how does the AI handle that? Does it throw out everything it’s decided thus far and start over? Is it naive in that it will go on with business as usual? Or more intricate so that it only recomputes decisions that are relevant? I’d love to hear from @Brad_Wardell on this one!
Regarding closed beta keys, @Grifman has been relentless about keeping me on my toes. I feel bad that I haven’t gotten them out yet. A few things in and and out of my control affected that, the big two being that I put a lower priority on it than I should have (the thinking being, if I’m still updating the KS edition, there’s less of a priority to set up the closed beta) and the other being that the aforementioned refactor of AI processing took awhile to work all the kinks out of, and I didn’t want to start the closed beta with a build I didn’t feel was especially solid.
The good news is that the current build does feel especially solid, and everything is set up and is just waiting on some final crossing of t’s and dotting of i’s from the BackerKit guys.
So what will happen with the KS edition once the closed beta starts? Well, I can’t make any long term promises here. If an investor comes along, they may have something to say about updating the free version.
But my current plan, assuming that backers are generally OK with it, is to keep updating the KS edition, but to do so on a delay of one to two major versions, so that the KS edition will get the final release of a previous major version, and will only be updated when the closed beta moves to a new major version.
The open and closed betas will continue to get updates on the current version, which is 0.7.1, until it’s final release (assuming there are any more releases on this branch, since the current release is pretty tight already). When combat improvements (0.7.2) come along, the closed beta will move to that version while the KS edition stays behind. And then when spying improvements (0.7.3) come out, the closed beta will move there while the KS edition moves to 0.7.2, and so on. Of course, the KS edition will only move to the last (and therefore probably the most stable) release for each major version.
Hopefully this sounds OK to everyone who backed. Or maybe you have an opinion on how much of a gap there should be between the free and paid versions. If you have an opinion, let me know soon before I make the announcement on the KS page (which will coincide with distributing keys for the closed beta).
This is fine from my perspective. Frankly, I’d be fine with you keeping the KS edition at the same version as the closed beta, but I have idiosyncratic views on how Kickstarter should work.
Oh dang. You just named one of my favorite little games.
This is increasingly the direction I’ve taken on my Unity projects too, it seems to get around a lot of my frustrations with Unity but always left me feeling like I was working against the spirit of the engine.
Yeah I get what you mean, although I can see that being the case more for some projects than others. I’d feel it more, for example, if I were using this design strategy for an FPS or a 2D platformer. That said, Unity is in enough of a state of flux now that it seems a bit muddy what the spirit is anymore in any case. DOTS especially brings that into focus.
I got an email notification for a beta key. But the beta key cannot be registered on Steam. Is there an email I can write to to fix the issue?
Hi @cicobuff. You can reach me at jgraw -at- starchart-interactive.com. Alternatively, send me a DM here, or hop onto the DG Discord and DM me there.
I will say did get my beta key :)