Introduction
Endless Lines“. The rest of this post is from Matt’s perspective (with an editorial pass from me).
A Studio Is Born
It has 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.
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 being scared about leaving my job.
The Plan
My plan was to start with a small, simple project I could complete on my own. My goals were to:
- 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.
I chose 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.
My advice to anyone doing this themselves is to talk to others using an SDK and look at a wide range before deciding on one. Every SDK and piece of middleware has its limitations and flaws so be sure to check their forums. 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. I thought about action puzzle games for the iPhone and control schemes based around the touch screen, rather than those using button controls or virtual D-pads.
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 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. 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 – another positive for me as that’s what all the AI written for Fable 2 & 3 used. I’d spent the previous five years with my coding split between C++ and Lua.
I imagine most people with experience of developing games evaluating Corona 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. Once you get a handle on how it works, it becomes very easy and fast to work with.
I’ll give you some examples of what I mean. Retina support is all taken care of for you as long as you supply a .png & a @2x.png and use the correct display function. For Open Feint leaderboards I would set aside a day to get them into the game… but a few lines of code later and it was done.
The best thing about Corona is the community that has grown up around it. The community share code and help each other out. There are people giving away chunks of code just to help the community. For example if you want some code to manage the scenes in the game then look no further than CrawlSpace Games’ CrawlSpaceLib. I took advantage of both of these. If you are using Corona you should check them out too.
There are some things I think need improved with Corona. 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 the product. They are very good about listening to feedback.
Prototype
I took a couple of days to make my technology choices with confidence after familiarising myself with the SDK and looking at other people’s code. Now it was 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.
Path Finding
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.
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 is 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 game’s performance. It was written once and remains unchanged.
Evolving Design
A significant change from the original concept was allowing the rows to be moved as well as the columns. During the first couple of weeks of development if a path was detected, it was immediately 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, more satisfying, high 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 considered 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. They 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 flat-mate when testing the game. This way everyone has the same challenge so times are achieved based on skill rather than luck helping them get the quickest time.
Art
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.
Release
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. There will be more but right now I’m working on a couple of other projects.
During most of the development of Endless Lines 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. It’s picked up some good reviews; you can find the links in previous blog entries (here).
About This Article
Matthew can be found on twitter as their blog.
@paulecoyote) edited the article for AltDevBlogADay.