Badass Pinguin Post Mortem

April 30th, 2014 9:08 pm

Hello everyone! We submitted a small little game yesterday for the LD 29 Jam and I wanted to write a post about the process that we took, how things were planned and what went right and wrong! Click here to play it!

Initial Game Design: (French google doc stating our ideas)

The first thing to do was trying to find an idea for the game. We knew we wanted 3d-ish graphics because the strength of our engine was mostly the rendering part. We had a lot of ideas but the best one was a Canabalt style game with an “under the surface” level.

We had a lot of ideas for the theme of the runner. The “above ground” would be a kind of desert/canyon where there would be sandstorms that would push you faster or slow you down. It would also have quicksand that would bring you to the underworld when you step into it. We also planned on adding traps like falling bridges or fireball falling on your head! :)

For the underworld, we wanted to have something really dark, that would be painful to experiment to represent a bit the other meaning of “beneath the surface” which is more psychologic (the inner self of the character). The platforms would crumble behind the character and there would be tons of traps like falling rocks or spikes, maybe have some ghosts or wisps that would kill you if you couldn’t dodge them.

What happened:

As we mentionned when posting the game, we created the game content and code from scratch but reused our old game engine/editor we did for a school project. We decided to go with that since neither of us knew how to use a commercial engine like Unity or Unreal and we already knew most of the code from our engine. The project was more oriented towards the 3D rendering part and less towards the low level stuff like memory management, object systems, game states, etc. We did a couple of fixes before the competition like adding a sound library and remove the UI of the editor that was in place but that was about it.

Because of the engine, everything we wanted to implement took a lot longer than we thought it would at first. There were a lot of issues we ran into while doing our game that we didn’t plan when we original did the engine (for example, the ownership of objects within the code, who creates what and who gets deleted by whom and when wasn’t properly determined). We knew, about 15 hours into the competition that we had to cut a lot of features and come up with a simpler game.

We didn’t have any gameplay before the 36 hours mark. After that, we got some of the graphics done, fixed a couple of issues with the platforms, added a foreground and a background and it began to take shape really fast. By the end of the second day, we had a playable version with sound, arts and even a nice particle effect. We just had a couple of issues related to the physics and the level generation to fix before submitting.

Either of us could work on the game on Monday because of work so we ended up doing some quick fixes 2 hours before the deadline. The final result is a pretty, fun and cool game which we are proud of, knowing the tools we used weren’t fitted for the task.

What could have gone better:

  • Preparation: We could also have prepared some librairies for the LD but we decided to join a day before it so it’s kind of hard to setup everything in less than 5-6 hours.
  • Better estimates and priorizing: We thought we could do a lot more in the time and tools we had. We should have prioritize on things more important and set up better estimates, taking into account the down times and the possible problems with the tools we use.
  • Clean code: We should have fixed the engine and wrote some proper game states, fix the memory leaks and clean the code to remove everything not useful before doing any gameplay related code. That way, a lot of our stuff would have been easier to implement and debug and it would have prevented a lot of hacks inside the code.
  • Better communication / location: Me and Vincent don’t live in the same city so we had to communicate through skype. It kind of works but there isn’t the same energy as if the team was in the same room where you can motivate one another.
  • Get feedback from others: We could have sent the game, screenshots or even just some ideas you have to some friends and try to get their feedbacks on what seems good or bad. You don’t always have a clear vision of what you are doing when you have been into the code for 30 hours.

What went right:

  • We did a game in about 60 hours and it’s fun to play! \o/.
  • Arts: The arts we’re awesome and the music also! Once we put them in place, it felt like the game was begining to take form and become alive!
  • Bug fixes: We were responsive to crashes and bugs. As soon as we saw them, we would fix them to prevent any further issues.
  • Code sharing: we used GitHub for sharing the code and assets and it went pretty smooth. It took us 30 minutes each to figure out what to do with conflicts but once you know how to merge, you’re good to go!

Final Thoughts:

I really enjoyed doing the Ludum Dare. I didn’t learn as much as I would have want to (I’m not really proud of the code I wrote) but it feels great to do a complete game in less than a couple of days. I’m really proud of the team and of what Vincent, Gabrielle and I accomplished.

I’ll take some time over the next few weeks or months to create some better adapted tools for 2D game creation and probably try to join the next LD.

One Response to “Badass Pinguin Post Mortem”

  1. Tetriste says:

    I enjoyed it just the same 😀 personnally, I think we learned a lot. Doing unclean code does not mean, not learning. On the contrary, it gives ideas on what would be clean and ideal for game making. I’ll also be working on something for 2D creation, and I probably will join the winter LD if not the next one. I’ll want to try my hand at the solo compo, it feels challenging 😀 (and I will make a time-lapse this time and I’ll come prepared too)

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]