Post Mortem February: What I've learned from Jetpack Pants

This is another Post Mortem blogpost, and it's all about the lessons I have learned from my second game: Jetpack pants! It' a real simple jump'n'runner game (the pants are automatically running, tho) and it was done probably in about a week (stretched out through February).

Less time leads to less game, no quitting, crunch through the end, bugs can be features, testplaying is essential, graphics are not

Less time leads to less game

I knew there was not enough time for the game I was imagining... I was happy for myself that I've learned this fairly early in the progress. I started early and had something playable even before February. But then finals started and I've spent most of my time learning for exams, obviously!

So basically the game wasn't progressing ... at all.

I had to cut down mostly ALL of my features I planned, aka level selecter, different levels, super-mario-like-jumping. But oh well, at that point I knew the product of this month was kinda trashy anyways, so I was okay with it.

I was very close to, but...

I did not quit.

I was super close. Really. At one point late in the month I was going back and forth from putting it down or quitting that month of gamedeving. And I think that in fact is the most important step in a project: Turn around, look for the reasons why you have started the project, and don't give a fuck about time or quality, just get the fuck up and end it properly! Every project deserves to be done, and after you have crunched through, you will be happy and satisfied with it, and you can be proud that you did it. Reeeaaal proud dude. I mean, now I can be all like "dude I've already made two shitty games hell yeah!".

Once I've reached the wall, I just crunched through it.

This was very helping. I was using the OneGameAMoncth Crunchtime to finish my game. I basically had a 48h deadline to have a finished game! And I was not alone. That way it was easy to get motivated and stay focused on my task. You I even had to finish early because I wanted to go to a party that night, and on the next day I was leaving for an awesome vacation, and I simply knew that theres only one way, that I would be going to other places with an awesome feeling: finish that damn game!

Testplaying is essential, graphics are not

The graphics all costed me about... maybe.... one hour in total? Well, they totally look like it as well, I know I know. And I should've put more testplaying time into it. I barely had time for level design tho, so I will use this knowledge for the next game!

Well. Today I wil start to dig into this month's game!

Let's go!

Post-Mortem January Game

I've got inspired by a fellow Game-Developer @tonyperriello for making a post-mortem Game blog post!

For those who are not familiar with the term: In the post mortem blog posts I would like to talk about what I have learned and achieved on a personal level from that project, and maybe give like a little insight of code if people want that?

Learned how game developing works, basic collision in java lwjgl/slick2d, 90x90 rule, wrapping up a game is harder than it seems. And to write a nice code!

I have started game developing because first of course I am into games, obviously, but second because I am studying it at a university of applied sciences.
It's crucial to know, how a game actually works (in the framework/engine you work with):

First, all the desired objects are being initialized, so they exist.
Then the game loop starts where first its updating like the positions, states, pressed buttons, collisions and so on.
Then the next picture is being rendered.

What actually blew my mind there is, that every freaking frame is rendered again, and again, more or less from scratch. And that every frame, 60 times per second for the most part, that poor computer has to to thounsands of calculations. Dude, thats hard work!

So, what I've learned in particular from my first game is a lot of java, and the super basics how collision problems work.
So the main task of a programmer is basically breaking down things in little problems, and the next steps are tackling every single problem. For collision it somehow goes like this:
1. Collision detection
2. What to do, when certain objects collide

Okay, now to the hardest thing  I was bound to learn in order to participate in One Game A Month (#1GAM):
The 90x90 rule.
Yes.
That rule again. I think I've mentioned it. When you think you're almost done, well, you're wrong. You are damn wrong. Actually you have barely made it to the half point really.
And that is a frustrating point, more like a wall you have to deal with somehow.
Just let me give you this advice: Don't give up!

Last thing I have learned from this first game: It's froggin important to write a nice and well-arranged code. Things you can't do with a crappy code:
1. Properly ask for help
2. Remember what the code does
And hence 3. Work on that code after some time passed

So, please kid, remember: Keep yo codes clean!

Some stuff about my life recently:
So, right now it's finals time, and tomorrow is my first exam. Maths! It'll be alright I guess. First time I'm in the middle of finals for me, so I am kind of excited, but already super tired of it really.
I have recently found that awesome site www.habitRPG.com, it's all bout gameifing you're life in order to build up new healthy cool habits you want to implement in your life. The first time to-do lists get actually checked off by me on a regular basis! Please check it out, and if you like it, think about funding their kickstarter project :) Good night!