Level Editor

It might not seem the most obvious choice, but we’re building a level editor using Microsoft Access.  There are good reasons for the choice however.

Firstly, Access is a database system and so it’s ideal for storing the level data while we decide what the final format for the game data will be.  It also makes it nice and easy to add new data items as required.

Secondly, Access is fantastic for developing Windows applications quickly and easily.  And because the data and app are all bound up in one file, it makes it easy for us to deploy no matter where we are developing.

The editor will be ready for use later today, and as feature complete as the current scope not long after.  Pretty exciting, as we’ll finally be able to design some of those wicked levels we’ve been dreaming about.

Scope Agreed

We had a bit of a brainwave last night, and we think we’ve got the scope nailed down now, right from the menus to the number of levels through to the way everything is presented.  We’re limiting the colours of balls to just three colours for the time being, but introducing a padlock icon to a few puzzles to change things around a little bit.

The game will now consist of three difficulty levels, each with 36 levels in each.  There’s no longer a time limit, but there is a move limit and the option to ‘ace’ a level if you do it within an even stricter move limit, which will be reflected on the main level select grid.  We’re going to do a full ‘Puzzle Mode’ where you can pick the levels you want (with later difficulties unlocked as you go) and then a ‘Quick Play’ mode which will either push a non-completed level to you at random or give you the option to work through all the non-completed levels in sequence, which might be handy.

We’ve also made a start on the music, which will be subtle loops of background musak, at least initially, and we’ve got the main sound effects sorted, although XNA is struggling with MP3s as spot effects, so we’ll need to convert them back into WAVs.

So, yeah, full steam ahead still.  Just got to keep that motivation up and hopefully we’ll have something playable by the end of the weekend.

Coders’ Block

We’re trying to be organised about the development by keeping a proper (ish) task list, setting due-dates for them, and then working towards that with regular communication about any issues.

But even all that doesn’t always help.  Last night some minor things were ironed out: screen res, full screen, how to draw text on screen.  Then I was left with the big list and what to do next.  Just pick something, right?  I mean, it all needs doing?  Yes, it does, but then the coder inside you takes over and starts working out which order is the most efficient.  And that clashes with the other voice telling you to just get basic game working and do it ‘properly’ in the remaining weeks.

We’ve pretty much decided on XML as the storage format for game data.  Which meant learning how to manipulate that in XNA.  Or should we just hard code the data for the first level to test the game?  Or do it properly now?  And then 30 minutes have gone by and all you’ve done is read about XML Serialisation while your mind wanders onto whether John Sergeant should stay in Strictly*.

Tonight it’s onto making the target grid work.  To hell with XML for today.

* the answer has now been revealed as no.

A Gamer’s Work…

…is never done.

As usual, there’s always more to do than there initially seemed to be.  What started as a quick prototype of one basic level soon turned into a little re-write to set up a few constants.  And then a few more, because once you’ve done a couple you may as well go the whole hog.  Before you know it, you’ve spent an hour making the code more general and easier to maintain, but you’ve still not got anything moving on screen.  At least things are a tad neater.

Sometimes you just have to know where to draw the line, sometimes ‘it works’ is good enough.  We reached that stage last night, but far from feeling like we’re part-way through the journey, it feels like someone just built a new section of road.

That’s exciting though.  Because although there is always more code to write, or graphics to design, you can see where it’s headed.  We’re pretty set on the game now, we know what we want.  We’ve just got to get on the road – thumbing lifts of a few XNA pros as we go – and get to the end.

Up and running

After a tiring evening, the first prototype of the game mechanics is up and running, using the in-game visuals, which are all alpha’d PNGs from Photoshop.  You’ll also see it’s still under our original title of ‘Shift’ before we changed it to ThirtySix.  We’ll talk more today about a diary of sorts, try and plan this week’s development, so that hopefully we’ll have much of the game’s core done by the end of the week.

Simultaneously, we’re working on the music and the sound effects.  We made a list of what we needed yesterday so we’ll start on that aspect of the game tonight.  We’ll also drum up the boxart and the thumbnails required for the Community Games system, which officially goes live tomorrow as part of the Xbox 360’s New Xbox Experience.  Wait for us, guys!

There’s no target grid yet, you can’t see what the level is meant to look like, but as this is already reading from a text file it won’t be far behind.  Although each zone is meant to serve 10 levels from a random selection of 20, internally we like to think of this as the first level, 01/01.  It’s two moves, in case you’re wondering, but acts as a nice introduction to the game rules.

Sharp Coding

I was excited by the prospect of XNA and what it could do.  Especially with a background spanning several years of programming, including the wonderful AMOS.  More recently I’ve been a VB convert and especially liked mucking about with VB.NET in Visual Studio when creating ASP.NET sites.

So, it was something of a culture shock when I tried C# for the first time.  I was all Dim MyString As String, when I needed to be String myString;.  Still, it’s only words and it’s not like they ever got anyone in trouble, right?

I haven’t written game code for a few years and I’m enjoying the mental challenge that the switch entails.  There’s game state management to consider, and it’s all OOP based, and 60fps at 720p and goodness knows what else.

But mostly there’s nothing that gets my creative juices going like trying to make code work.  I’m abuzz now we’ve settled on the mechanic and I can start to code it.  We haven’t settled on a structured methodology for development, but here’s a few of my favourites we could try:

RAD: Really Arsey Development.  You know the sort, when a co-developer refuses to help debug your code because you’ve indented to 3 characters and not 4.

AGILE: All Great Ideas Leave Eventually.  Like scope-creep in reverse, where all your hard work and creativity is sacrificed to ship a generically bland shooter instead.

SCRUM: Scope Creep Rampant Under Management.  This is like AGILE, but it’s where incompetent managers try to cram irrelevant features into a perfectly working product and it’s 2 weeks until shipping time.

DSDM: Don’t Save, Don’t Matter.  Spend 8 hours working on a piece of code and deliberately don’t save it because you know you’ll be redundant tomorrow when the publisher pulls the plug on an eminently sellable masterpiece.

I’ll let you know when we decide.

Cost

Just a note, actually: we’ll be selling this at the cheapest possible price.  We’re expecting the download to be < 50 MB, so the price in Microsoft Points will be 200.  We’d do it for cheaper if we could.

Fleshing out the game

We’ve been debating how the actual game will flow, and we think this is the final set-up.  Basically, the main single-player game will consist of 5 zones, each offering 20 levels.  When you start the game, you’ll be able to start from any already completed zone and work onwards, and each zone will serve a playlist of 10 levels selected at random from that zone’s pack of 20.  You’ll have a set time limit to beat each of the 10 levels, do so and you’re through to the next zone.

Every level you complete will be added to your list of levels which you will be able to practice in a seperate menu.  We say practice, but in reality this will be used to obtain ’stars’ which will be awarded for beating a level in the minimal number of moves, and for beating the levels in a set time limit.  Think ‘challenge rooms’ in Portal, but with less portals.  We’ve not really discussed the two player mode yet, still working on the prototype of the game and devising levels.

We think the control scheme will either be a mix of the twin analog sticks (one to move the select rows, the other to scroll the bars) or movement with the d-pad and then hold the A button (with the d-pad) to scroll.  We’ll maybe offer both and let the user decide, then fight between us which method should be the default.  On the subject of levels, here’s an example:

The grid on the left is the target, and the grid on the right is how the balls will be presented to the player at the start of the level.  This can be beaten in just 6 moves, and very quickly, so the ‘practice’ stars will be 6 moves and something like 3 seconds.  We’re aiming to get a prototype of the game running with the 360 controller by the end of the week.  The screen below can be beaten in 8 moves.

ThirtySix – we’ve started

So, it’s been a couple of weeks of mock-ups, name changes and even core mechanic switch-a-roos, but we think we’re now happy with the basic idea of the game.  Essentially, it’s going to be a 6×6 grid of balls that can be shifted horizontally and vertically, with the aim being to match the main grid with a smaller grid off to the left.

Think picross, but simpler, and more colourful. There’ll be lots of levels, a random mode, time trials, leaderboards and (hopefully) some kind of two player battle, whether that’s local or over Live we’ve yet to decide. The art-style is almost there, but we’ve yet to decide on final graphics, and there’s zero work on the sound effects and music at this stage.

So, welcome to our little developers diary.