For last April’s Ludum Dare competition, I had decided to do something a bit different than what I’m used to : a 3D game. Sure, I had played in the past with a couple of engines, but nothing I had done came close to a full-fledged game. So I took the opportunity to just dive and try to come up with something using the open-source Panda3D engine. With it, I knew I could create games writing only Python code, and I already had a good understanding of the engine’s inner workings.

The result, after 48 hours, was a game in the “autorunning” genre. Think Canabalt for instance. I was rather pleased by what I had achieved (the game placed 13th in the Graphics category and 40th overall), but it was still far from the game I had in mind. And that’s what those development logs are going to be about : the process of taking OUT OF HERE from a prototype to a full game.

Since then, I have started re-factoring the code, and extending it to accommodate some more advanced features. It’s still not back to a playable state, but the progress is steady.

• The first change is the control scheme. In the original prototype, you used the arrow keys to strafe, jump and slide in order to avoid obstacles. This was enough because the level was a big straight line. But while I plan on maintaining the autorunning core mechanic, I want to have more open-ended environment, and thus need another control scheme. Up to now, I implemented a standard WASD + mouse FPS scheme. It will obviously change once I start reintroducing the automatic acceleration, but at least I can navigate easily through the…

• …non-linear levels. The code now generates random levels which now include turns and crossings. It does so by stitching together small segments, generating the overall plan using a bunch of randomly placed rectangles. It is only a first rough way to improve the level generation, but it’s good enough for now. Here are two examples of such non-linear levels.

• The third main feature is a render limit. It helps keep the framerate steady by limiting the number of city segments that get rendered depending on the player’s location. At first, I was limiting the render to x segments from the player’s position if those were connected directly to the one the player stands in, but in the end I found that lessened the sense of depth of the city, and decided to simply render all the segments up until a certain distance around the player.

At this point, the game is still pretty crude-looking, mostly because I didn’t reintroduce the bloom shader used in the Ludum Dare version. The roadmap currently looks like this :

1. Prevent the player from passing through the buildings (it’s somewhat working, but I need to polish this up, and I found a more general way of doing it. It will probably be addressed in the next post.)
2. Add special city locations for the beginning and the end of the levels, enabling the introduction of a winning condition.
3. Reintroduce obstacles and autorunning. At this point, I’ll release a new version, it will still be far from what I want the game to be, but it’ll be playable again.

Work after that will probably focus on introducing new gameplay mechanics. For example, new moves or new obstacles types. The graphics will also need a lot of love, so that will also be on the list. Thanks for reading, and see you next time !