Devlog #3 – June 29, 2019

Commuter

Economy, Time Engine, Save State

Please note that images and features in this dev log a subject to change and may not be in the final draft.

Good day and welcome to the third instalment of our Commuter: The Game development log. Thanks again to everyone who has been following along on Twitter, Instagram and Discord.

Business Updates

Before I get started into whats new and exciting in the development of the game I just wanted to take the time to welcome a new addition to the team.

Jordan Tessier is a Toronto based artist and personal friend of mine. Jordan is an absolutely amazing artist and also has an equal passion for video games. Jordan has agreed to join the development team and will be assisting with the design portion of the game. Please join me in excitement for him joining our team. Below is some of the artwork that Jordan has created. It is absolutely stunning.

Game Economy

This wouldn’t be a simulation game without some sort of economy with it right? This past week we have been focusing our development on the economy engine of the game. With the style of gameplay we are going with we had to come up with a unique way to do this.

Frequency and Current Funds

The easy solution you would like would to have a script running and holding all the economy functions but that is proving to be more of a challenge to this game. What we had to do is a hybrid engine that both runs per level and overtop the whole game with them both talking to each other. There were several reason for this decision but the main reason was performance we don’t want a sluggish game.

The game has to not only count money collected by each sprite when they pass a “fare gate” but it also has to calculate the idle parts of the game such as profit per minute to ensure the game can run in the backround. I will admit that I am not 100% happy with the way the game is running this part of the game. But for building and development purposes it’s working. We can fine tune it later.

The only thing that we need to study is if we want to do a truly idle based game. That being the game runs in real time and when it’s night out for you, it’s night out for the game. The other option is to run the game in its own time based system. This will completely eliminate the need for an idle based system.

I/We are currently exploring both types and will make a decision soon about what type of economy I/We are going to pick. To be transparent I am leaning to the non idle based system as it allows the game to run smoother and provides the user with more depth in the game.

Time Engine

Time on bottom bar

It wouldn’t be a transit game if there wasn’t a time engine running. This was a simple to make engine but it will provide yet another important backbone to the structure of the game. I’ll even admit now that we have this part coded into the game it’s starting to look more like a game someone can play vs just a set animation that runs and runs.

The time engine is simply just figuring out when the trains should run at what user controlled frequency. How long until the next train. What time of day it is? Just to name a few key components of the engine. Yet another foundation piece placed for the game.

Save State

This honestly was not a part of the game I was looking forward to making. If you don’t already know. Save states are… complicated. I started to code my own system and quite frankly it just wasn’t working for what we needed for the game.

Thanks to the Unity asset store it made my life WAY easier. Now I just need to call one line of code to save and one line to run and thats is. Now, every-time the game restarts the users info is remembered! Woohoo!

Thanks for reading this weekly devlog for Commuter: The Game. Please follow us on Twitter and Instagram for more behind the scene looks. Also, take a visit down to our discord and join the conversation! I hope to be making some video ones soon. Stay tuned.

And finally, to all my fellow Canadians. Happy Canada Day!