You mentioned in places that you have separate cities. Since you're building the cities straight on the map, the world is several times larger than most 4X games, right? How computer intensive is SBR? My desktop is future proof, but my laptop much less so.
Ah! Sorry, I forgot to answer this part of it. In terms of its computational intensity, that's hard for us to say with certainty at this point because we haven't really done a huge job of optimizing everything that can be optimized. That said, I get better performance out of it than I have out of Civs 4 or 5 on the same computer.
Every so often we'll hit a trouble spot where we just have to optimize or else it gets crazy lag like 10 seconds between turns or something. Then Keith finds the issue and we're back to like half-second turns again.
Mostly this is accomplished by having designed the game in such a way that the AI factions are designed to be played by AIs. The structure of their economies is similar to yours, but different in such a manner that the AIs don't have to weigh certain options as much because they can work on things in parallel.
Aka, for instance, the AI doesn't have to prioritize working on the military or working on beefing up its citizenry. That is very computationally complex to figure out what is best. Instead, it is able to actively pursue both, and the two things come out of different pools. Instead, pursuing more citizenry is having to be prioritized against food, water, and so forth -- all of which are actually related things in some manner, so it's saying "what kind of fruit do you want in your salad," not "what kind of meal do you want out of all the meal possibilities in the world." Meantime, on the military construction side it is saying "how do you want your steak cooked, or would you rather have pork," not "you have $50 to spend on all your activities for today, what would you like to do?"
Basically what I did was find several related contexts into which the AI activities could be grouped, and then made those parallel rather than contentious. Then things within those contexts are contentious for the most part, although in a few cases not. That lets us have AIs that act quite intelligently, without cheating, and without having such computational and design complexity on the AI systems themselves. It's very much a case like AI War, though, where the AI players are playing one game while you are playing another.
Except here, each of the AIs is playing a game independent of each other, too. What they are doing is being free actors in a world with which they are already comfortable, and they are being simulated as societies that are reacting to what is going on around them. Some of them do want conquest, others seek wealth, others seek philosophy or simply to be left alone. Some want territory, but not to wipe others out unless they have to. Etc.
It's actually not possible for another race to "win the game" in the sense that they win before you do. Again like AI War, where the AI can't go "I win!" all of a sudden and you're out of the game. I mean, the way they do that is by killing you. Same here, except that you might be killed by the world itself, or your own citybuilding internal issues, rather than purely outside forces.
Anyway, so that's some insight into how the AI works and why it's able to be so vastly more efficient than other strategy games of this general sort. Same as with AI War, the gameplay design makes the AI design possible. The AI here is very different from in AI War, though, as the flocking stuff and emergent behavior isn't possible. However, we get emergent behavior in entirely different ways thanks to having what amounts to multi-agent governments with the different construction and action contexts I mentioned.
Internally we call these "governors" in the code. Each AI has a bunch of governors that kick off in a series of phases, and each governor says what it wants to do, or nothing if it sees no need to do anything. It also says if it thinks its thing is a really high priority or a low one, and it also says if its thing is non-contentious and should happen outside of any other contentious governors in that same phase for that AI. Within the decision making of a governor is some fuzzification of the data like in AI War, so that the governors don't always make the 100% best choice (which is predictable in a bad way), and there is then further fuzzification as to which governor wins out if two are contentious and can't agree.
And thus we wind up with AIs that are highly adaptable in a variety of ways. If we decide that we want to have the AIs respond better to when X sort of situation arises, then one way of having that happen is to make a new contentious governor that is in the appropriate phase for the AIs and which checks for that condition and then reports back its suggestion and its suggested priority. The core AI process might or might not take that suggestion depending on how urgent the suggestion is seen as. And thus the AI has a new skill, but it's not 100% guaranteed to happen right away, or even at all, if we don't want it to be. Or if it's urgent, we have easy ways of making sure that it always responds to that circumstance _for sure_, as well.
How did we come up with this...? Well, it's been over 6 years now since I first started working on AI War, and we've learned a lot since then. And then we've been working like crazy on this since Octoberish. The most challenging aspect of this, for me, has been keeping all of the individual simulations simple enough that they can be easily understood and played by players in a fun way. There are so many systems that if any are too complicated then the game becomes impenetrable, very slow, and un-fun.
I spent some substantial time playing the game, noting when my blood would start to boil, and figuring out how to calm myself down with a chance. I also have so far been expending as little mental energy as possible at trying to become truly good at the game. It's inevitable that I have a certain amount of skill because I know the game quite well. But I'm not really putting much thought into long-term planning, and in some respects playing "as stupidly as possible" without actively doing dumb things. This has been really revealing for me in terms of what feels intuitive and what I can accomplish with my brain sort of on autopilot for the default difficulty (which, with someone with my skill level and level of knowledge for the game, should indeed be a kind of semi-autopilot circumstance), and it's made it so that the blood-boiling situations go away and a lot of the GUI kinks get worked out. I actually have taken a lot of cues out of chemical_art's book in terms of stopping when I get frustrated and then assessing and making changes.
What is going to be different for me in the coming weeks, and even moreso beyond that, is that I will intentionally be upping my game and trying to get as good as possible with it. That then changes my focus from fluidity and fun into making sure that the game presents an adequate challenge and adequate counters for any strategies I can come up with. There will be holes and chinks in the armor for a while, hence a couple of months of testing with a lot of very smart folks here. For us, having the game react to those holes and chinks will involve new governors in some cases, rebalanced mechanics in others, and so forth. But that's about fine-tuning the game for expert players, not about making it baseline fun and interesting from day 1, which is what I've been focused on so far.
This division of labor between Keith and I, where he takes up 99% of the programming work, has been really paying off so far with this project. I couldn't have done this without him, and it's been a really amazing experience. He's been able to handle a lot of code architecture stuff that I don't have to think about, and has done an excellent job designing systems under the hood to make everything perform well and be extensible and easy to maintain. I've been able to focus more on the gameplay, while at the same time of course having the programming knowledge to design the gameplay in a way that is conducive to appropriate CPU loads. And in the case of AIs, sometimes I write out things very specifically in terms of what I want, or even fully code a "black box" algorithm that I maintain and Keith only calls into and gets the result from (and then deals with that in the rest of the simulation), and in other cases I just give a brief description of what I want and Keith goes and does it, absolving me from further thought about that specific governor or algorithm or what have you.
It's made for a really good partnership on that sort of thing. And then of course with the artists, Blue and Cath most of all, we're in emails many times a day and always showing work and critiquing and figuring out new and better ways to handle things, and just generally all making sure that everything comes through as great as possible. So again, just lots and lots of teamwork.
