Another 1GAM entry: 3 out of 12, a quarter is done. In a marathon this would mean 10,5 km (of ca. 42) are behind me already.
Background story: Evil dice from outer space have come to destroy humanity. You steer the last remaining starfighter and are earth´s only hope. Destroy all aliens by turning their poison against themselves: “Die, dice!”
Instructions: Shoot dice to make other dice explode. Dice with the same value explode. Colliding dice with different values will shoot back at you!
Where did the inspiration come from?
Well, I knew that I wouldn´t have much time for my 1GAM game this March. Therefore I thought it would be great if I made something that builds on the game code of last month game. So why not something where you shoot at Tetris-style objects? Coding shoot-em-ups is not too difficult.
So the most important inspiration is from Quarth. A game that initially came out on NES and also had a great GameBoy version.
But since I always plan to never simply copy existing ideas of course I had to change something. I thought of using some logic or mechanic with six-sided dice because they have this natural affinity to randomness (a necessary ingredient for endless play) but still can get matched with / compared to each other by their rolled value.
In the first version of my game I experimented with the shot die to stick when the values of the other colliding dice did not match (I call those: “mis-shots”). But that was too slow, boring and also too difficult because it let the playfield grow too fast instead of letting the player shrink it with every shot. Furthermore it seemed that the player inevitably had to perform some mis-shots because there were plenty occasions when none of the remaining rolled shot dice did fit to the dice to shoot. Still I wanted to punish the player a little for mis-shots to prevent a behavior of simply shooting on without thinking. So the idea came about of why not have mis-shots return to destroy the player? Usually it´s a fair challenge since the player has enough room to escape.
Also that gives two nice trickshot mechanic: the player can deliberately mis-shoot – but before the shot returns the player moves to evade – and the returning shot now can hit some other die behind the player that has a matching value. I detected such situations in the game code and played a nice sound (“Trickshot!”) to honor such an actions.
The other trickshot is to have two shot dice of the same value collide with each other, one of them a mis-shot.
The laughter sound sample played on the player´s death is of course reminicent of / inspired by the classic 16bit game “Wings of Death” (Atari ST and Amiga) which has one of the greatest soundtracks of that time (by the legendary Jochen Hippel).
What didn´t work as expected?
Initially I planned to go very lo-fi with all assets since I did not have much time this month to code the game. That holds especially for the menu / controls / credits graphics. I thought it would suffice to quickly sketch them on my digital drawing board – but the results were quite unusable – lololo-fi. I had to do them again properly which was not necessarily time saving in the end. Lesson learned: the digital graphics board is for graphics not for handwritten text to be used in UI.
What did work out?
The timing of the elements did work out almost at once. Usually there is a very annoying phase where each element must get tweaked in several iterations to fit to the other elements. The game is no fun at that point and it´s unclear if by tweaking the fun will emerge. And then some new elements get built in and many other elements have to get re-tweaked. But with this game there was almost no tweaking phase necessary. The “fun” was discovered when I implemented an explosion radius for colliding dice. The basic game mechanic was thus complete and I could focus on other things e. g. the soundtrack.
Which is another thing that worked out well: the 0:37 min. menu loop and the 2:07 min. ingame track. Having not too much experience with FL Studio I still find it easy to construct little techno/upbeat tracks with this fine tool. Each time I make a new track I try to find out something new in FL Studio. This time I tried out controlling the mixer of some patterns by the x and y variables thereby changing the sound filters dynamically. I like the results.
Lastly it was a good thing to build on the code basis of last month´s game. Instead of having to code many timeconsuming errorprone conversions (e. g. between 3D and 2D spaces and so on) and mapping functions I could just go ahead and build on some raster cell coordinates, using the orthographic camera.
What could get improved?
Besides giving the game a better look, I thought about adding some enemies just like in usual 2D-shmups that would force the player to move, probably crashing into enemy dice unexpectedly, which ought to supply more tension and also speed up the gameplay a bit. And a real highscore list stored somewhere on a server. And a webversion… still had no time to fix the problem in my custom Unity3D code that prevents it from running in the webplayer.
Plan´s for next month?
No idea yet what I will code in April. At some point this year I´d like to make something with a little story – some action adventure maybe?! And also I should break free from 2D and start making something small in 3D. But for this I first want to have an idea that really *needs* 3D instead of working out better in 2D.
Let´s see, let´s see…