Let’s see what has been worked on this last 30 days. Spoiler alert - a lot of stuff!
Snapshots are taking shape
You can now save and load the game state. Pretty cool!
One of the biggest issues with the snapshots is what do we actually want to save and how, of course. The obvious thing is that we want to save the current state of the simulation. That’s obvious enough. But eventually we will want more than that.
One of the things we want to save is the values of the sim entities’ properties from the game states before the current state, or as I call them - the archival values. We want to be able to use those archival values in-game to display them on graphs and things, make the variable changes through time clear and make them easy to view analyze (using graphs and stuff). Saving them can be hard if you wanted to save all variables’ values for all time ticks ever processed by the sim. Both time to process this data and the amount of storage needed to store it is not feasible for this kind of game which is supposed to run smoothly even on lower-end machines.
Right now the default is using:
- last 30 day ticks worth of archival data
- all monthly ticks
I tried saving the last 24 hour ticks worth of archival values but lag was too noticeable, having the archiving function run every hour tick. There could be room for optimization still, but for now the hour ticks are out. And you probably won’t need the last 24 hour ticks worth to be able to plot trends from your data anyway.
One of the ways of making the archiving faster and more elegant in general could be to not save every possible variable (prop). There are two possible ways of going about changing that:
- check if the value changes or not, save only if it changes — this seems like a good idea, though it would mean we need to label our ticks somehow to know which ones were omitted.
- create a new flag for props indicating if we actually need to save archival data for it — think of built in things
_mapcolorfor example; there will probably be things that don’t need to be changed during the game, or if they are we might just not want them to be viewable in a graph.
There are other things we might want to save. Like info about what scenario is being played, or what org is the player playing.
First complete draft of the GlobeMap plate is complete. Together with a set of provinces and orgs for it. It doesn’t contain the sea tiles, but it will do fine for now.
The main idea for the plate is for the individual provinces to be sort of similar in size, for reasons related to simulating climate and environment and such. On the other there are good reasons to base the provinces on the actual administrative divisions as they exist in the real world, because of legislation, population, infrastructure and similar things, which usually differ based on these divisions - we will definitely want to simulate those as well.
The above approach kind of describes why some real world countries are represented as just one province, while others are represented as multiple provinces. There is also the fact that this kind of work - laying down this kind of map - is a hard, boring, repetitive work. It will definitely get better with time. This is still an early draft which will probably get revised many times in the future. And many other versions will come up.
Setting the plate from script
The next step is to load the plate from custom mod script. This is actually something I’m working on right now. It will probably be ready next month.
A similar thing is loading actual prop values from image plates. Let’s call those prop plates. The idea is to have the plate colored with colors using some color scale (like greyscale) to represent different values, and then be able to load this image in from a script and have the game convert it to actual values for the province/org props. This kind of tool will be even more useful for setting pixel-based value spreads for provinces. First I need to implement the pixel-based value spreads though.
I’ve created an partially functional main menu. It’s been pretty time consuming, but also pretty satisfying work. It’s looking pretty good so far. I wanted it to be clear and simple. So it is simple. And feels pretty clear too.
You can make a new game based on some scenario, or load a snapshot.
Making a new game comes with choosing an org. Using the globe, of course.
Moonscript on Windows
I have access to a Windows machine now and I have successfully tested Moonscript compiler windows binary. It’s working just fine, added rules for unity player to look for different files based on the operating system.
I have been thinking (fantasizing?) about making a simple launcher. Maybe using the Electron framework. It seems simple enough. The problem is - I don’t think I even need a launcher right now. Or ever. It could be a nice addition, but I don’t feel it’s needed. Probably no launcher for now. Or ever?
I’ve been thinking a lot about things related to the AI side of things, and what kind of infrastructure I need when it comes to decisioning system. I feel like I have a clearer understanding of how to implement all of that, though still need to write all of this stuff down.
I want to add some simple gameplay elements to have something ready for the January release, something very remotely resembling an actual gameplay situation, with decisions flying in, popups popping up, tooltips tooltiping, globemap showing data actual data, stuff happening.
We’ll see how that goes.