Monthly update for October 2017.

7 minute read

It’s only been a month since the last update, but there has been so much stuff going on! Time flies.

Globemap 3.0 in the works

As mentioned in the previous update, I started working on yet another version of the globemap. This time I want to display stuff using writing to textures at runtime.

Right now the basic functionality is there. The game is able to take in a plate texture (like the one below) and process it so that it makes a list of provinces, storing their “pixels” for later use.

Globemap province plate testing

Processing time depends on the size of the main plate. The main plate size is now 8192x4096. Smaller versions of the plate are made (in the future they will be created at runtime) and processed to pixel lists accordingly. These smaller pixel lists can be used for things that don’t need that sort of resolution main plate has.

For example we get scaled down plate version 2048x1024 which is used for finding province center algorithm. It’s much faster to use this smaller plate for this task, instead of the bigger one. And we don’t really need insane resolution for finding province centers anyway.

Another use I got for the 2048x1024 plate is displaying selection live on the globemap. The writing to texture operation is fast enough to be performed on a 2048x1024 size texture without getting too much of a frame hiccup. I’m still not sure whether this kind of pixelated selection display is what I want. Though it will probably not be visible when lines rendering for the borders comes in. Performance-wise it will probably get even better when future optimization of splitting the globe texture into smaller parts is implemented. This could mean the resolution for the selection displaying could get higher. We’ll see.

Globemap selection screenshot

One important thing about this resolution aspect of the globemap textures, and the use of different-resolution-versions of the same plate, is that we can spawn different globemap-modes for different uses. Ideally, the API will allow for spawning such modes from the lua scripts and for setting the pixels to whatever is needed.

Things like satellite-image style view of the earth will get

Welcome Moonscript

Scripts can now be written in Moonscript. Moonscript is a language which compiles to Lua, so it was not really difficult to implement at all. The only thing that needed to be done was performing the actual transpilation.

While it sounds simple, making it work took me more time than I would like. But it was worth it.

Compiling to Lua

Using srlua I managed to compile a “standalone” version of the moonc compiler, having Lua itself already integrated into it, so that you wouldn’t have to install anything to play the game.

That’s for linux though, I haven’t touched windows yet, though there are actually ready to use binaries on the Moonscript website. They should work no problem. I will probably test that sometime in the coming weeks.

Compilation process basically copies everything from mods directory into a new mods-c directory (deleting the old mods-c first of course), then compiles any Moonscript .moon files to Lua .lua, and deletes the .moon files afterwards. So the game will actually use the files from mods-c. This directory could be better hidden, to not create any additional confusion when modding, but I’m not sure if it’s necessary at this point.

Cool features

Moonscript has a cleaner syntax than lua, especially when dealing with things like tables. Declaring key-value tables, something we do a lot of, is just so much cleaner.

Lua compared to Moonscript - example element registration

There are other things that can make things simpler, additional operators like += and ..=, optional parenthesis for calling functions, and more. Strongly recommend learning the basics in 15 minutes.

While we probably won’t use most of it’s more advanced features, Moonscript is still a nice addition. Simplifying the scripts and making them more readable is important.

Keep in mind you can still write scripts in pure Lua. Both Lua and Moonscript are supported.

Bootstrapping with load

I implemented the register and load data at once registering functionality for sim objects. Just give it the path to the .json data file and you’re good to go. Of course the data file will have to be structured properly (files with incorrect nesting will be ignored). This functionality will be added to all registering bootstrap functions.

As an example, here’s an excerpt taken from the base mod’s province.moon:

-- Here we use a version of boostrap.provinces that takes in a path
-- to a .json file containing a table of provinces. It will automagically
-- register them and, if it's a two-level table with props, it will also
-- perform a bootstrap.load on it.
bootstrap.provinces "propdata_province.basics"

More concrete specification for snapshots

Snapshots are the way for the game to create save-files. Sort of.

They are a mix of saving game-state and saving replays, so to speak.

When playing the game you can specify if you want to save snapshots at some specific times, like every game-month. Those can be either full-game-state snapshots or select-a-set-of-properties snapshots. The former ones are also treated as saves which can be used to load the game and continue playing from that moment in time. There is a non-interactive game-mode for previewing snapshots, where you can load the snapshots you want and track different values as they changed over time. This is a great feature

Regarding the full-game-state loadable snapshots - they will save information about the scenario used to generate them, so the game will be able to tell exactly what mods were used. This should probably include some hash generation to be able to tell if the mod was modified or not.

So yeah, good stuff. More on that some other time.


I put up community forum for testing. It’s using Flarum, since I wanted something modern, but fast, and easy on resources. From what I’ve seen so far it’s pretty cool.

I’m still testing it, but it will probably stay there for good.

Check it out.

What’s next

There is a number of things I’m working on right now:

  • globemap - creating map-modes from scripts, reading data for map-modes from images
  • API - add even more functionality
  • new UI functionality
  • docs on the website - should be more or less complete soon
  • API documentation generation tweaks