Database migrations

No cool pictures to show today but I think there's something very cool for behind the scenes, and that's that I've built a tool for managing database migrations.

As we develop online games there's many smaller updates and changes that we want to make to the database, and we need a way to store and edit those so everyone and the databases remain in sync.

The most straightforward way is make every change a SQL file, and then we just work through, applying them in order till we are up to date. The gsMigrator tool does just that, with a few extra features for safety and reliability.

One is being able to revert changes. Each SQL file can be paired with another that will revert it, assuming it's changes can be reverted, and developers are not too lazy to create it.

The other feature is optional transactions. By default the SQL of a file is ran in a single transaction, so if anything breaks, the whole thing will be rolled back to be corrected and reattempted. This is very useful and makes things much safer as we won't end up with half applied changes. The problem is sometimes we don't want a transaction as it stops some other cool things from working. Index creation can take a looooong time if you have a lot of data, so there is the option to build them in the background, but this is not allowed when you are in a transaction. So i've added support to turn off transactions if there is a special comment on the first line of the SQL file.

Setup auto post to mastodon

In my own simple version of POSSE, these devlogs are now auto posting to Mastodon! There's not much to it, as mentioned in a previous devlog, posts are extracted from a self hosted kanban board into markdown to then to generate the static HTML. Now there's an extra app that scans those files, and if it detects a new one, creates a new toot from it.

Move to company id instead of company index

It's a bit weird that we can create and remove companies, but companies are also referenced by their index. So in theory we could try to action a company, but in the mean time an earlier company was deleted, and suddenly our index is wrong.

The straightforward fix for this is to give each company a unique id, then we can always safely reference them by it.

It's a little wacky with our as everything needs to be defined as the action is created, which for creating CPU opponents, means the player needs to generate that id and not the server. If it was just the server it would be easy and we could just have a variable we increment by 1 every time. Since it's just for CPU opponents in a game, and there's only going to be like 4, I think it's fine to let the player pick a random number as the id.

There's definitely more controlled things we could do, but its just not worth the effort currently.

Fixup operator handling

The initial code for my custom programming language would use the character token to define what an operator was eg: + or *. The problem is that some operators are more than one character, eg: += or >>. So what I had originally done was when tokenizing the source code i'd squish anything that could be an operator into the one "character".

This worked 99% of the time, until we get to nested templates, eg: Template<Class<SubClass>> the last two characters should be two separate right angled brackets, but get merged into a special double angled bracket. Then the template parser would fail as it specifically needs a single angled bracket to complete.

When I first ran into the issue, i added a quick hack to work around it, if there was a >!> in the code it would always parse as two angled brackets. Now quick fixes can survive forever, but the time has come for this one.

The operator code now handles a vector of tokens instead of a single one, that means we no longer need to merge characters, and so we don't need the hax on top of it.

Fix cross name class lookup

In my custom programming language, it had a very lazy system to resolve classes. This caused a bug where a class in a different namespace was being selected instead of the intended one. It's a bit surprising that it took so long to actually hit this issue, but unfortunately it required a large rewrite of the resolution code to fix.

Select airline flair

You can now select the colour theme for your airline, in a popup GUI during game setup.

Game setup screen revamp

I've done a revamp of the game setup screen, moving away from the placeholder UI to something more final.

It's still pretty placeholder tho, haha. Hopefully a real artist will help in the future with everything.

Manually set starting airport for CPU players

If you are the first human player, you can edit the CPU opponents.

There was a bit of background work to this, as previously CPU opponents were virtually connected clients. So the server could not tell them apart from real humans. That was neat, but was a bit annoying with things like this, where to the server it would look like a hacker trying to edit another player. Also it would be a problem in the future with adding CPU opponents to multiplayer and mixing virtual and real clients.

So now they are companies created and managed on the server, and flagged as CPU.

Also these CPU opponents would set ready right away, which would then conflict if the player would try to set their starting airport later. So now CPU opponents will wait until all the humans have finished before taking their actions.

Select starting airport UI

In the pregame screen you can now select your starting airport, and see the selections of other players.

Multiplayer AeroCEO!

After much suffering i've got multiplayer somewhat working.

Here you can see two different perspectives on the world map. Note that a players routes are in solid black and the opponents are transparent.

Previous to this, the game itself has been theoretically multiplayer compatible. As it always runs with a server and client, and instead of using the network, actions are passed via a simple memory buffer.

So upgrading to real multiplayer still involved a lot of work around getting networking setup. Also there was a bunch of other tweaks and fixes and whole new menus that needed to be created so a player can even get into a game.

Simple Lobby

OK this took a little while but it's very exciting, AeroCEO now has a real networked client/server setup.

Here you can see the two games connect to the server and join a simple lobby, then one can make a game and the second one can join it.

Now technically they are both in their own single player games, so that will need to be worked on next. But now the players are connecting and being forwarded onto a game room where they can communicate.

Rework route create

I've updated the route creating and editing to be a nicer experience.
Now there's an initial step where the player picks the destination, rather than clicking around the full edit dialog. The route is shown in white, and the camera moves to display it.

I had to revamp the camera systems a bit, as previously there was only the user controlled position, and focusing on an airport, with the only transition being moving back and forward between them. Now we also have and additional option, focusing on a route, and moving between any of the three options complicates things.

Update airport UI

I've updated the airport UI to be closer to my idea of what the final setup will be. Having the city name and some details at the top, and a horizontal selection of actions across the bottom.

Better UI states

The UI is a little nicer now with knowing what state things are in.

So when a UI window is up, you can no longer click the ones below, this was leading to some weird states and crashes.

And also now the range rings only appear when you are actually creating a route, and they are needed. I'll need to add an extra "range finding" mode to airports as well, as you might still want to plan ahead and check ranges before you can make routes.

Camera zoom when selecting airports

Here's a bit of flair, when selecting an airport, the camera will now swing in to give a better view.

This is leading to the background / flavor image for each airport. I'm thinking that we show some kind of big sprite on the map that's unique for each city. Like a Sphinx in Cairo, or the opera house in Sydney.

I've setup a new Camera class to handle this stuff. Originally it was just a bunch of numbers in the world rendering. Now it manages the user controls, and dynamically swinging over to the targeted airport.

You can also see in the video that it switches back when creating a route so you can actually see what you are doing.

Airport range rings

I had initially setup the game to display little pips on every airport to show how far away they were from the currently selected airport. But that causes a bit of visual clutter. So I'll try out drawing some concentric circles instead.

We'll try this out for a little while and see how it goes.

Camera dolly

We can now move the camera in and out with the mouse wheel.

I've put a little acceleration on it, and also scaled the rotation when clicking and dragging so things feel nice and smooth.

Route arcs

I've made the routes cooler looking by making them arc between airports, as opposed to being a straight line.

I've also setup thicker lines for international vs regional routes.

World lighting

I've added some simple lighting to make the 3D globe pop a bit more.

It's pretty simple, just a single light in the corner. I've gone for flat shading as well for a more retro look.

Oceans

I've now added simple ocean rendering to AeroCEO.

It's a simple blue sphere, created by geodesic tessellation so the triangles are equally spaced. As latitude and longitude will bunch up towards the poles.

I did a bit of play with the depth buffer again, to avoid z fighting where the water is very close to the land. The ocean is pushed back so the land has priority.

I've also turned on back face culling so the back side of the world is no longer rendered, since it can't be seen now with the water in the way.