After my satisfaction with last week’s game, I was feeling ambitious. I had a whole week to work on a game, and I was well rested from the weekend. Sitting down on Sunday, I made a rough outline of the game I wanted to make, and the tasks I’d need to do each day to make it. I even aimed to have the game complete on Thursday, giving myself Friday as an “overflow” day for any outstanding tasks. Despite all this, the game I made this week was a disappointment.

My original vision of the game had the player taking the role of a train driver delivering assorted goods to different stations in a small game world. The player would need to navigate the world by using landmarks that they would come across, with directions from the people at each train station, and with a basic paper map. I also wanted to have some humor and character interactions in the game, where the player would talk to the people loading and unloading the train at each station. The game structure would have been a bit like Cloudpunk, where the main enjoyment in the game comes from the dialogue and becoming familiar with traversing the world.

While this is definitely a large scope for 1 Game a Week, I thought it would be manageable. I’ve written dialogue before that people seemed to like in one of my first games for Ludum Dare: “This is NOT a Scam!“. Implementing the story would have been very basic. There wasn’t going to be branching paths or anything too complicated. The hard part of all this was going to be implementing the train movement mechanics. For a long time, I’ve wanted to make a “train game”, primarily because the implementation seemed like a fun programming challenge, and it’s quite different from standard grid-based or Rigidbody movement.

So with my justification for the scope out of the way, I decided to start the implementation by using Bezier Curves to define the train tracks. I’ll happily admit that Maths isn’t my strong suit, so this video by Freya Holmér helped me out a great deal with understanding how they work. I was surprised to find out that the logic behind them is quite simple, especially when using De Casteljau’s Algorithm.

After writing a very basic Bezier Curve implementation and a very crude editor script, I was able to setup a chain of train tracks. Things were running smoothly until I had to start implementing track junctions and tracks that cause the train to either reverse or run the opposite direction on the track.

So in my implementation, I’m able to get the t-value of each track segment, which is the interpolated distance between the beginning and end of the underlying bezier curve. A t-value of 0 will get the Vector2 position at the beginning of the curve, and a t-value of 1 will get the Vector2 position at the end of the curve. You can iterate over the curve, getting a Vector2 from each t-value and then using those positions to draw the curve, which is what I do here. So far, I think everything is simple enough..

If I’m writing a game where I need to move the player along the ground, I can add a value to the x position to move right, and subtract from x to move left. Unlike a simple 2D game where the x value can go off to infinity, each track segment has its t-values clamped between 0 and 1. I need to check for when I go above 1 or below 0 on the t-value, store the remainder, and then set my “current track segment” to either the next or previous segment. Immediately the movement logic is more complicated, and this doesn’t account for cases where you loop around the track and end up moving forward in the opposite direction, or even reversing the train.

I don’t want to get into the entire implementation in this post-mortem, but I just wanted to demonstrate my point that the implementation wasn’t as simple as I first thought it would be. This doesn’t even take into account trying to add junctions, which also needs to take into account the “direction” of the track.

I struggled with this for a few days, and if I’m totally honest my motivation really dropped off on Wednesday/Thursday, when I was hoping to have movement implemented and I could start working on the world design of the game. It wasn’t until the weekend when I was able to get movement working, and that didn’t account for the train’s momentum, or taking turns too quickly, or any of the “fun” movement mechanics. I basically had a way to move around the track and change junctions. Although I did also add in some code to create the train track graphics, which was quite enjoyable.

The junctions took a while to finish too. This was more of a game design issue, I didn’t know the best way to show the player the current junction setting and which junction would be changed when they hit the A Button / Space Bar. I originally wanted to have the track itself change, but that would have been tricky to implement, and I don’t think it would have been easy for the player to make a judgement on the junction setting when the train is moving at speed. The best thing I could come up with was a literal sign that shows the junction setting.

At this point I had a basic prototype built and it was almost the end of the week. I knew I wouldn’t have the time or energy to create my original vision. The idea of salvaging the project and turning it into a slot car racing game crossed my mind, but at that point I wanted to just abandon this game. I put it up on Sunday, and now here I am writing the post-mortem on Monday.

What went well

• Not a lot, I essentially made a small prototype, similar to my first week. At least I finished?

What could have gone better

• I could have cut scope earlier which would have made me less likely to procrastinate.
• My implementations were quite buggy.

What I learned

• I learned a lot about bezier curves and their uses. I think this will let me implement a lot of different and interesting game mechanics in the future.
• I have some ideas on how to improve my implementation, which will be useful the next time I have to write a track system.

Summary

In the end, I don’t think this prototype ended up in a good state. In saying that, it was a good learning experience. I still like the original idea I had for the game, and this is something I’d like to pick up again for 1 Game a Month. Knowing some of the pitfalls I can run into with this game mechanic, I think a 1 Game a Month project would have a better chance of success now that I know what issues to look out for.

As always, if you want to try out the game, the link is right here:

If you wanna play around with the code, I also have a link to the GitHub repo if you click here!