It’s been about a month since I released Endless Lines so I thought I’d take a quick look back at its five weeks of development.

At the start of June I left my job at Lionhead Studios where I’d been working as a gameplay programmer for the previous seven years.  I went straight from school to university, spent six years at university and then immediately joined Lionhead – this was scary, at 30 I was suddenly in a world without a set structure for the first time since I started primary school at the age of 4.  Fortunately I was best man at a friend’s wedding the weekend I was leaving Lionhead so I spent far more time worrying about the speech than leaving my job.

The Plan

My plan was to start with a small, simple project I can complete on my own.  The reasons for this were quite simple:

• Get used to working at home rather than in an office environment.
• Get used to working on my own rather than part of 70+ person team.
• Finish something to prove to myself I can see a project like this through to completion before moving onto larger, more ambitious games.

The second part of this plan was to use SDKs and middleware wherever possible to save reinventing the wheel.  These things aren’t a magic bullet that will do everything for you but they can significantly speed up your development process if used correctly.  Every SDK and piece of middleware also has it’s limitations and flaws so be sure to look at their forums, talk to others using it and look at a wide a range as possible before deciding on one.  Of course you have to know what you’re making and what your target platform is before you go looking for an SDK.

A Concept

The initial concept for the game that would become Endless Lines was an idea I had last Christmas while thinking about (action) puzzle games for the iPhone and control schemes based around the touch screen rather than being button controls or virtual dpads.

I had an earlier concept filed away in my head about a falling block game where the blocks have lines on them.  The player arranges these blocks to form a line across the play area or forms a loop of with them.

These two ideas merged into a game where there is a full board of blocks, the goal is to create paths/lines from one side of the board to the other and this is achieved by moving the columns up & down rather than the block itself.

Corona SDK

After playing around with a few SDKs for iOS development I settled on Corona by Ansca Mobile.  Corona is a 2D SDK targeting iOS and Android platforms, ideal for my needs.  It uses the Lua language which is another positive from me as that’s what all the AI for Fable 2 & 3 was written in so I’d spent the previous five years with my coding split between C++ and Lua.

I imagine most people coming to Corona with experience of developing games have the same reaction as me – where’s my game loop, how do I set up objects, how do I associate this function with this thing, input?

Corona is designed to make development quick and easy, especially on the graphics and interaction side.  And once you get a handle on how to work with it, rather than with your old habits, it becomes very easy & fast to work with.

I’ll give you some examples of what I mean.  Retina support, as long as you supply a .png & a @2x.png and use the correct display function it’s all taken care of for you, it just works.  Open Feint leaderboards, I’d set aside a day to set these up and get them into the game but a few lines of code later and it was done.

To me the best thing about Corona is the community that’s grown up around it, sharing code and helping each other out.  There are guys giving away chunks of code just to help the community, want some code to manage the scenes in the game then look no further than Ricardo Rauber’s Director class.  How about some extensions to SDK functions and a great wrapping of the save load system, then check out CrawlSpace Games’ CrawlSpaceLib.  I took advantage of both of these and if you’re using Corona you should check them out too.

There are some things I think need improved with Corona and a visual debugger would be a most welcome addition, but I’m not going to go on about it as they are constantly updating and improving it and are very good about listening to feedback.

Development

So I’d picked an SDK and messed around with it for a couple of days, mainly looking at other people’s code, time to start my game.

After the first day I had a basic playable prototype up and running:

Not a looker with the titles quickly drawn in Paintbrush (some of the edges don’t even match up) but it was functional – the columns could be moved and the game recognised paths, but didn’t remove them yet.

Since it was designed for mobile platforms I was always concerned with the code for the path finding taking up too much CPU time.  The path finding code had to do two things:

• Highlight blocks that are connected to the left edge of the board and therefore are part of a possible path.
• Recognise a complete path from the left to the right side of the board.

These are two separate but linked requirements so were split for the overall goal of the simplest, fastest implementation.

The first uses a simple flood fill style recursive algorithm to find which blocks are connected to the left edge of the board.  If a block is connected to the left edge then it checks all the blocks around it, if it is connected to any of those they then perform the same check.  This continues until it’s flagged all the blocks that have a connection to the left edge.

There’s only a complete path when one of the blocks in the right most column is flagged as having a connection to the left edge.  When this is the case code is run which finds the path across the board from right to left only looking at blocks that are flagged.

Splitting it this way gave me code which never impacted the games performance and once written remained unchanged.

A significant change from the original concept was allowing the rows to be moved as well as the columns.  Durning first couple of weeks of development as soon as a path was detected it was removed, this was changed so paths weren’t found until after the player have finished moving, paths were cleared on the player’s terms.  These two changes allowed the creation of longer, higher scoring paths.

This type of gameplay lends itself very well to timed gameplay modes.  To me Blitz and Sprint are the core of the game, Zen is essentially a practice mode which I may have been better off not including.

The time focused core modes made the special blocks almost pick themselves.  There are three of these blocks:

• Multipliers – These appear when more than a certain amount of blocks are removed in one go.  The simply increase the points value per block.
• Bombs – These take out all the blocks in the row and column they are in.  Originally they just removed the blocks surrounding them but that wasn’t enough of an incentive to make players go for them.
• Locks – These prevent the row & column they are in from being moved.  These are ideal for Sprint mode where the player is trying to reach a target score as quickly as possible because they are a small obstacle to be overcome along the way.  Locks were also in Blitz mode, but just removed all the fun from the mode when they appeared so were removed.

In Sprint mode the sequence of bombs & locks is always the same for each of the three targets (each target has a different sequence).  This was suggested by my flatmate when testing the game, this way everyone has the same challenge so times are skill based rather than luck helping them get the quickest time.

My biggest worry was always the art, for this game I was doing everything myself so I had to pick an art style I could produce.  In the end I decided to try and make the blocks look like they were physical board game tiles.

The art was always the slowest part.  I decided to add an email feedback button to the main menu, the code to add this functionality was trivial, creating a button that looked good and read well took hours.

I got very familiar with Photoshop again and abused all the tricks I’ve picked up over the years.  I’m happy with the work I produced for the game, but in the future I will be looking for an artist to work with.

The only thing I didn’t do myself was the music, which I licensed.  This was quicker than doing it myself but it still took two days going through various music licensing sites listening to samples…

The End

Five weeks after I started Endless Lines I submitted it to Apple.

The main aim of this first project was to get used to working like this rather than as a cog in a big machine and it worked.  I’ve released one update for Endless Lines so far and there will be more but right now I’m working on a couple of other projects.  For most of the project I kept normal working hours, as things went on I worked at the weekend and did a few hours in the evening but nothing crazy and it was never a chore, I wanted to work on it.

Overall I’m happy with how Endless Lines turned out, especially given its short development time, and it’s picked up some good reviews, you can find the links in previous blog entries (here and here)