krawaller

Having finally got Golingo out the door and into the app store, we’re in the process of dreaming forth our next project. While Golingo will keep us occupied for some time to come;

• As my brother promised, he’s going to detail the creation of it in a forthcoming post, highlighting the use of web technologies and the benefits of the Titanium Framework. Start typing, Jacob! [edit: read that post here]
• Community feedback has given more than enough ideas for an update, so Jacob is now working on a new version containing..
  • more languages (initial release has English and Swedish)
  • more game modes
  • wifi multiplayer (to complement the split-screen multiplayer already in place)
• We’re also considering getting an Android version out, which will hopefully result in a blog post on what that transition will entail. The fact that web apps are (mostly) platform independent is one of the main arguments against using Objective C, and this conversion will put that to the test. Will it suffice to simply throw a switch in Titanium and search&replace some proprietary CSS, or is a more deep-going refactoring needed?
• Of course we also want to keep pushing Golingo sales, trying our hand at the very strange field of internet marketing. We are completely oblivious as to what makes success there, so it’s a journey of discovery (advice much appreciated!). Golingo did however recently reach the 1000 units sold mark, meaning an wage of $2 per development hour! We just need to release 49999 more apps to get our Mediterranean beach house!

But, being developers we need to develop, so in parallel to the Golingo caretaking we’ve also started hunting down the next idea. Now, like all of you we of course have several dream projects that we’re itching to work on, projects of life-fulfilling promise but of equal complexity. Time, however, is in short supply – Jacob is in the process of securing a contract to create a travel planner application for a major Swedish infrastructure company, and I spend 80% of my time teaching mathematics & programming to the inmates of society’s penalty box. I’ve finished the Advanced JavaScript course for Linnaeus University, but still, 1 free day a week (minus household chores) doesn’t amount to much. So with the lessons from the angry carpenter fresh in memory, I realised we need to keep things simple and our heads on our shoulders.

Because of that, and because it’s also in line with a common perversion of ours, we decided to create some kind of puzzle game. They are by nature rather confined, and might therefore be doable within our limited time. I earned my programming badge in the dungeons of a beautiful MUD called Midnight Sun, where one of my favourite pastimes was making puzzles for the heroes to solve, so as to put their wit to the test and not just their character’s stats. I’m hoping I can draw on that experience to shorten development time even further.

Now, being a mathematician, I started thinking – what actually constitutes a good puzzler? Are there some mathematical traits that we need to pursue or avoid? There are some obvious answers:

• First off, the idea needs to be both simple and clearly defined. The rules of our universe must be few and unambiguous. Take Subway Shuffle, an early iPhone favourite of mine. To play it, you only need to know that...
  • You can move all cars, but only along tracks with the same colour
  • Only one car per station at a time
  • The goal is to get your red car to the big red station.
• You need to have a rich choice tree. Here Subway Shuffle becomes an anti-example – at any given point you only have very few options available, and more often than not the correct one is also the only one, if you eliminate backtracking.
• There also needs to be some possibility of lookahead. If the game is completely opaque and you’re not sure how you’re doing, it’s hard to have fun. Colorbind is an excellent example of this, where it’s always possible to deduct how close you are to your goal, and whether or not you can get there from the current point. Side point: Colorbind is also really beautiful, which definitely doesn’t hurt sales nor gaming experience.
• However, the lookahead shouldn't be too allowing. Case in point: Cross Fingers. After having stared at the board for a while and having realised how to solve a level, the actual solving is just a tedious walk through the motions.

Subway Shuffle	Colorbind	Cross Fingers

Having reread the above list umpteen times without managing to come up with a novel idea of our own, we eventually decided to do like all successful developers - steal one! There are innumerable basic puzzle concepts that have been reincarnated more times than Buddha, and can therefore be considered part of the public domain.

One such concept quickly rose to the top of our list of potential thieving targets: Labyrinth. At least, that's what the first reincarnation I encountered was called, which I played in the attic on my father's Macintosh more than 20 years ago. You've all experienced it in one form or other, I'm sure. Below is a screenshot from Roadblocks, a more recent (but less beautiful) flash incarnation:

The idea is very simple: You have to reach the goal. You're able to travel in any cardinal direction, but cannot stop mid-flight. In a way, you could say you're controlling gravity - whenever you press an arrow key (or tilt the iPhone, perhaps?) in a certain direction, the player object will travel as far as possible in that direction.

And, that's pretty much it! I think the simplicity explains the longevity of this seemingly bland concept. The labyrinth will always be much smaller than it seems, since only a few positions are actually reachable. To make things more interesting and to increase the branches on the choice tree, various spices are usually added: teleports, breaking blocks, etc. So while the basic concept is simple enough to implement, there seems to be ample opportinuty to breathe some fresh air into it all by thinking up new ways to spice things up!

Having finally decided on what to aim for, I sat down to make a sketch of the project. First I jotted down some basic thoughts & premises:

• We will of course follow the path Golingo cleared, and program this game using only web technologies. Probably we'll pack it up in Titanium, but we don't need to make that decision until way further down the path.
• To allow for lots of exotic spices, I want to make an abstract, flexible game engine that can easily incorporate the new ideas which will inevitably pop up along the line (movable blocks! enemies! multiple player objects! levers! inventory! delayed effects! etc etc ad infinitum).
• Will Wright has many claims to fame, but for me the most important lesson he taught is that of the humongous size of peoples' pride. How come The Sims, a game by definition utterly boring (your characters use the toilet, for Christ's sake), has had such a remarkable success? It is based on user generated content, that's why! Incorporating a level editor into our game would be a neat way to capitalise on that, as well as making it easier for us to create the levels to be packaged with the game.
• Since we're short on both time and graphics skill, we'll use our otherwise unhealthy fascination of new web tech to give the game a simple but hopefully stylish look using mostly (only?) CSS.
• I also want the game to feel at home on the iPhone. Colorbind is again a prime example, using the touchscreen and gimmicks (shake the phone to clear what you've done) to great effect. Contrast this to Puzzle Quest, which was ported straight to the platform without any regards as to what makes it special, leaving the game feeling rather alien to play.

A further brainstorming session in front of this list gave birth to the idea of the Analyzer. If we are to allow players to make levels of their own, they need to have some tools to make sure that their level is actually solvable. So why not put all game logic into this tool? I'm going to make a module that analyzes a given level, and spits out a data object containing all possible board positions, and the connections between them. That allows us not just to check the integrity of a level, but also to sort them difficultywise programmatically. 

The gaming module will therefore not contain any game logic at all, but just perform the animations when transitioning from one state to another, and keep track of the current state. This should allow for a very neat separation of concerns in the codebase.

It also makes the whole project split neatly down the middle, meaning me and my brother can wrestle with one half each! I already have most of the Analyzer code written down in my head (I have an editor in my brain, but unfortunately it can't yet run any code), so I'm going to call dibs on that. Which will suit Jacob fine, as he's quite skilled in the CSS graphics department anyway - he made Golingo using almost no actual pictures, save the wooden background. 

So that's where we're at now! I'm in the process of writing some specs of the data objects to be passed around, but when that's done we can both get to work individually, without depending on the progress of one another. Time (and a follow-up post) will tell how it all turns out!