And back to coding again. As always, quick summary of what has happened recently: I've changed job, moved out from my city, and now I have the luxury of remote work from a house in a village. I'm coding, leaning back in a deck chair and listening to the trees (Ok, that's not necessarily true - right now I'm listening to Pink Floyd. But bear with me here), the kid is playing in the grass and I'm enjoying myself greatly.
I've done some work on the GAMIFICATOR. I've progressed it to what one would call early beta, and gave it to my friends to test out. I've received list of things they wanted to be improved upon, and lemme tell you - the list is big ;). Thirty features/change requests. Maybe it doesn't sound that much, but for a project I wanted to do over a weekend, it's a surprising amount of work. What I was happy about however was that they were positive about the app in general. So yay, go me I guess.
The galaxy generator was stuck on a back burner due to simple thing - I got annoyed at not being able to figure out easy frost line calculator for a solar system, and couldn't figure out where my planets with life would be. May not sound like much, but it got me annoyed and I paused the work on the project. Between that and moving/getting new job, I've halted my home development for three months or so. Time to get back in!
##################################################################
Project:
As the project progresses, the build HERE (click me) will be updating with more stuff. Click on button to start a mode, press Escape to exit back to main menu.
Ok, so what's this new awesome project? Back when I was working in games industry in Hamburg, I befriended a great designer, and we spent plenty days with couple beers, pens and notepads, jotting down ideas for games - especially games for iPhone which back then was a new and exciting platform. Utilising things like tilt sensor and touch screen seemed great for new games. Unfortunately, the company in which we were working crashed and we were separated, but the ideas stuck in my mind and from time to time I've pondered working on them.
One of those ideas we codenamed 'Klak', an onomatopoeia for piece of wood hitting another piece of wood. It was supposed to be a logic game based around the principles of Q*Bert:
Basically, the Q*bert is a really simple game. Change the colour of the blocks by jumping on them, till all of them are the colour you require. We thought about making it less of a direct clone, more a game inspired by this, Marble Madness, and maybe Sokoban. It was supposed to be a game in which you tilt the screen to move around a rotating tile to go through puzzle-levels. You'd start with really simple 'clean this area', and then switches, crumbling floor blocks, and other ways to make game interesting would appear.
Hope I didn't scare you off with this longish introduction. The idea I think really had chance (still has?), but I'm not sure if all of that is necessary for iOS game. Recently there has been trend for 'quick restart', as I call them, games: Flappy Bird, Timberman, Robot Unicorn Attack, Super Meat Boy and others. Games that you can turn on at any moment, play for couple seconds, and then put away. I totally see their appeal (having played them extensively. damn you, games!), and wondered if I could make a game like that.
So, how do I turn a puzzle game into rapid restarting arcade-y one? Long story short: No idea. I have however been religiously following Extra Credits. One of the things they said stuck: FAIL FASTER. Make a prototype as early on as you can, check what you see, ditch what sucks, keep what is good, iterate. And so I have. First up was the camera:
Original idea for the game for camera to be 3D, slightly from the side,but I also thought that maybe top-down view would be good. So I wrote a quick test of camera/controls in Unity, and what do you know - people liked top down view better.
Ok, easy part done. Now what?
How to translate the game to something quick and fun? I grabbed couple beers, sat down with my girlfriend, and as we sat and looked at the sunset, we wrote down what popped into our heads. So, we came down with ten possible ways the game idea could be translated into mechanics. So, here they are:
Terminology:
Tile: player controlled block. It's a 1x1x0.2 sized, rotates around one of its edges.
Block: basic building piece of a map
Dirty block: block that is not neutral colour, needs to be changed
Clean block: neutral block, you want all your block to be this colour.
Ideas:
- Standard game: rectangular game area, all blocks start clean except for one. Then, every X seconds (getting smaller every time), a new 'dirty' block appears. You have to keep cleaning as fast as possible before all board is covered in dirt.
- Exploding dirt: area, which you can fall off from. As with standard game, dirt appears, though after not being cleaned for some Y time, it explodes, leaving a hole into which you can fall. You have to survive on the board as long as possible.
- Electric fences: One dirt at a time appears, every X time a row or column of blocks is 'electrified'. If you touch it, you lose. Amount and speed of appearing of electric fences increases as the game progresses.
- Holes: Holes or trap doors appear, you have to stay on the board.
- Snake: Normal board, but your speed increases, you can fall off the board.
- Simon says: Dirt appears in certain colours, and you have to clear it in order given by game. The amount of dirt you have to clear increases every time.
- Bejeweled: Moving over dirt doesn't clean it, but changes its colour to next one in cycle. connect 3 or more in the same colour to clean.
- Sponge tile: Dirt blocks are in fact leaking water. You have to gather the water and move your tile to 'drain' area every time you're full
- Rubbing the dirt: like standard game, but instead of tile you just use your fingers
- Programmed levels: What we started with. Full puzzle mode. Maybe it's worth it.
Not all of them are great, hell, probably not all of them are playable, but they're supposed to give me something to play with and get a feeling for the game before final design.
Implementation and conclusions:
So far, yesterday I have implemented the first game mode:
I feel that it is not good at all, there's no real incentive to play, you can't lose fast, and when the tiles start appearing fast there's nothing really you can do. This however gave me plenty insight towards next builds. I have also realised that in the second game player can go forever just by bouncing between two tiles and preventing them from ever exploding. So already that's a good thing to know.
I have written the code so that I can reuse as much as possible, but since I still was just starting, I didn't know all the parts I would need. In second game I'll correct my library to be even more reusable.
Well, that's it for now. Maybe it doesn't sound great, but I'm really happy with where I am, especially with the fact that thanks to this approach I'm not digging myself into a hole with shitty game. Sure it hurts to realise that my ideas are crappy, but this helps me steer towards the awesome game at the end.
See you around!
