When the theme of last night’s 1hgj was announced as being “Trains”, my immediate thought was “hey I can reuse my assets and code from my LD35 game”! The idea was to change it up a bit, by making a frogger-style gameplay (well actually the opposite, since in the original frogger you want to avoid the cars). Initially there were going to be loads of trains coming and going, and perhaps that would have been more fun? Either way, I copied my project and started hacking.
Turns out retrofitting a project to a new gameplay is not a time-saving exercise. There’s a lot of useful code for loading levels, making the trains move etc - but also a lot of code that I wanted to disable or remove. I guess the code is not the most re-usable given it was hacked together during 48 hours. However, the biggest time-sink was not the code, it was the level design! Since I went for fewer trains, it’s vital that they actually line up at some point so you can jump from one to another. Each test took 20-30 seconds to get to the vital time in the game, and in a one hour game jam, that’s just not practical.
I ended up spending a lot more than the assigned hour due to this. I think the cumuluative effect of retrofitting code, level design, implementing new gameplay and above all, testing - caused the delay. I had hoped that re-using an old project would make the game quick and easy, but the lesson here is that it wasn’t. Maybe its fine if you have modular code or if you base your project on a skeleton code framework, that way there will be much less retrofitting issues. Potentially I could create a couple of skeleton projects for 1hgj’s - maybe one for platformers and one for top-down tile-based games?
Either way, you can play the game (jump with space) - note that I never implemented a win condition, so if you get to the lower platform, consider it a win!