A cool game jam to learn from

Our submission, "I Reboot", was fun to make and we learned a few things in the making. So here some thoughts about if.

The preparation, release the speed boat !

As we were getting ready for this game jam, I offered to my team to test the "speed boat" technic to identify what could motivate us, slow us down, scare us and what were the main goals of this jam.

Major points we identified

Here an abstract of what we got with that speed boat technic :

• What motivate us :
  • A big point was working with friends and the solidarity and the teamwork that results from it. (we had a lot of fun)
  • Our passion for video game (no sh$t sherlock ! :stuckouttonguewinkingeye:)
  • Using Unity (we really like this game engine...)
  • The Ludum Dare community. Shoot-out to :
    • @jk5000 for quickly point out that I forgot to make the game public on the ith.io page (dumbass me...)
    • @cesargary for our little cross advertising :p
    • @erlioniel for making little advert for other participants' games on his twitter
    • All of you testing games and leaving useful and cheerfully comments !
  • Playing lots of games to discover bright ideas and have fun doing it! (and we did !)
• What was slowing us down :
  • Being too ambitious was a major issue on our two past Ludum Dare.
  • Some of us don't use Unity that often and coding with lack of knowledge on how Unity actually work was a drag on past jams
• What we were afraid of :
  • Not making it in time
  • Being AGAIN too ambitious and finishing the game in rush and pain
  • Being stuck with something we don't understand (sometime Unity is hard to understand...)
• And our goals were :
  • We wanted to learn things
  • Improve our workflow and process
  • Make a game (and a good yet simple one !)
  • And we reached all of those :smiley:

We then dive into the making of our game with all those points in head.

The making

So we started with a really simple concept :

So the idea is basically that you start with just to "entities". You control the blue one. You have to shoot the red one. That done it end the loop's iteration. Then the loop restart but you took the place of the red one and the red one start to re-do the actions you've done past iteration. So you have to move to dodge his attack aka your past one. You then can shoot to the red one and the loop repeat, the red one repeat your past actions and so on and son ...

We try implementing it really quick - Unfortunately I don't have a gif of the early concept but this one is faire enough to illustrate (don't mind the portal or the station there weren't working at the time) -

But we quickly figured-out that there was something missing... To "win" (you can't actually win because it loop for ever) you just had to do a side step, shoot the red in every loop... So we came with the idea to add to step, one before and one after killing the enemy (the red one) : first you have to activate your gun, and after having defeated the other one you have to go to a portal before it disappear. Both the station to activate your weapon and the portal spawn the farthest possible of the the player. These two more actions were forcing the player, and so the enemy on the next iteration, to move from point to point. So you have to chase your past self for ever but not being to fast at it or your next one won't be able to kill your self... What a loop !

- The activation station -

- You have to go to the portal before it's too late ! -

The last big part of the game making was to add a map procedural map generator and wire up with the added feature. And voilà ! Our game was complete !

After thoughts and lessons

Proud of what we achieved we celebrate with a drink and went to test your games :smile:

But we learned important things : - Think simple but effective. We had our first prototype at the end of the first day. It had no sprite, was ugly and no map generator but it was a working game. Thanks to that we had time to focus on the map generation. - Peer programming is good, don't think that teammates have to always be working on their own, in their corner. Peer programming (or art-ing, sound-ing, what-you-wanting) is a very efficient way to overcomes problems - Be focus on the core design, do not go for more feature until you have the prototype more than finish. We had the map generation after we had a working prototype. By the way, the map generation wasn't mandatory for the core design and we may should had work on a better tutorial than on that complicated procedural map (but, hey, we now got one to be re-used in future projects :stuckouttonguewinkingeye:) - Using unity is not just "coding", there is a philosophy behind it, if you're a beginner working with someone that have experience in Unity, do not hesitate to do some peer programming to get that way of thinking. Same on every game engine though... - Ludum Dare specific : Take numerous screenshots/gifs of your game making and final product and post about it ! Knowing how to communicate about your creation is a something important !

Hope this post taught you something. Keep on rockin' y'all !