Over the weekend, I made a game for Krass Jam #5!
I streamed about 80% of the game’s development on Twitch. I took some breaks in between. I worked on the game on most of Saturday, most of Sunday night, and for two hours on Monday night. Overall not much time.
So, how did the development go?
When I first started working on the game, I had to choose a theme. For Krass Jam we have a generator make three crazy themes for us and we choose from the three.
My three themes were:
- Motivate superheroes to be a bad enough dude
- throw hats and buy extra content with real money
- collect crystals from unknown worlds with businessmen
I had Google choose a random number for me as I had no preference for any of these. I could easily imagine what kind of game I would make for each of them.
Google chose #3.
So I hit the ground running.
After that I made a game design document (GDD) to keep track of things I needed to do and to flesh out a good direction for the game.
I wrote out a little intro for the game’s story. And then I made a list of things to make.
I started with the frame for the game first. And then I went in and built the gameplay.
This is a first for me in a game jam. I built the menus, win and lose cases, volume controls, and instruction screens first. Then I built the pause screen and set the input actions. I also made some art in between to chisel out the look before I made any mechanics of the gameplay work.
I also built the hud after that and made a fuel gauge that depletes with time.
Then I started to work on simple player animations and movement. This movement is where most of the programming logic is written in the code.
Many Japanese game developers start with the player’s look and feel in the game first. And then they go and build the rest of the game. This is a good idea. It works really well for much bigger projects.
Well, if you build the environment and the menus and everything else before you focus on the player feel, you are wasting a lot of time. If the game ends up with a bad movement feel, the game won’t be very fun to play. Players will go and play something else.
So why did I chose to build the frame of the game and the menus first?
Well, for two reasons;
- The time constraints. I wanted to get a working program built first. I hate it when the developer leaves out menu settings, and a simple way to pause and quit the game.
- It’s low hanging fruit. Easy to finish. If I can accomplish a few easy tasks, then I will get into my groove and be ready to tackle more cumbersome ones.
However, looking back, I should have been a little more lean in the process. I should have made the smallest iterations, and kept on making the next iteration. Finish the simplest version first.
That means starting with the end in mind. Starting with the win and lose cases, and working backwards from there.
I did this for the last game jam game, “Ice Cream and Match.”
Why is being lean good?
Well, during a game jam life can get in the way and we have to stop working on the game. If we stop and we are lean, we still have the last iteration to publish and submit to the jam.
Many people enter game jams online, but about half of them finish and submit a game. If they worked in a lean style, they might have made a basic version to submit early.
Now let’s talk about my game’s gameplay.
The gameplay, in a word, is unfair.
There is a random chance of winning the game even if you put forth your best strategy.
Every block you destroy in the game has a random chance of producing a gem. There is even a chance of having no gems turn up after destroying every block. This makes the game impossible to win.
Although there is fun in losing the game, after the first time, losing gets really old as there are only two lose cases.
And that makes the gameplay short and replay undesirable.
The sound together with the animation is only slightly satisfying.
The digging animation is slow. If I sped it up or played it backwards, I could make the digging action feel less sluggish. But it is what it is for now.
Acceleration. There is no acceleration or deceleration. The velocity is constant.
The worst thing about the movement is getting stuck on the side of the walls when trying to move up. This happened when I watched my wife play. She didn’t realize that you should just back away from the wall and she thought she was stuck.
To me it was an obvious solution. But to a player it’s a point of frustration. It’s a point of exit from the game.
Also flying with the rocket booster has no sound. So there isn’t much satisfaction with flying. Only a quick animation.
Building the Game for Another Week
If I do decide to work on this game for another week, I would need to improve many things.
- The Game feel
- Build up the story and make more animations
- Build up the replay-ability
- Extend the game with upgrades and bigger levels
That’s all for now. Here’s a link to the game. Play it and let me know what you think in the comments.