• Register

39 Days to Mars is a two player co-operative puzzle-adventure game. Step into the shoes of Sir Albert Wickes and The Right Honourable Clarence Baxter, two 19th century explorers who have chosen to pilot the HMS Fearful on its maiden voyage to Mars. When the steam engine runs out of coal, the ship's cat shreds the navigation chart, and the tea gets cold, it becomes clear that interstellar transportation isn't a walk in the park. It will take the talents of two players working together on the problems that arise to get to Mars in one piece.

Post news Report RSS Rethinking the Art Pipeline

This update sees a number of exciting changes, in both the appearance of the game and behind the scenes. More level graphics have been added in, and I discuss how the content pipeline has changed to accomodate a faster turnaround.

Posted by on

This update sees a number of exciting changes, in both the appearance of the game and behind the scenes. More level graphics have been added in, and I discuss how the content pipeline has changed to accomodate a faster turnaround.

What's new this fortnight?


The ground level is taking shape, and you can see from the image that most of the graphics are now in the game. With so much going on, I'm hoping it's not too overwhelming to start with. However, it means that the puzzles and elements can all interact and with lots of things happening it gives the level a very 'mad-inventor' feel, which is exactly what I'm aiming for.The behind-the-scenes change this week is a complete revamp of the content pipeline. In non-programmer terms this means that I've streamlined the way that I draw pictures and put them into the game. I go into this in a bit more depth below.


Puzzles : 2 co-op / 0 stand-alone
Objects : 8 tutorial / 8 ship

Rethinking the Art Pipeline

One of the big changes this fortnight was an overhaul of the content production pipeline to make it faster and easier for me to put graphics into the game - and most importantly, change them easily once they're in. The old process looked a little like this:

  1. Draw the artwork.
    I use the GIMP and a wacom tablet, drawing the outlines first and then filling in the backgrounds once everything is finalised.


  2. Arrange the pieces into a spritesheet.
    A spritesheet is a single image file that contains lots of smaller pieces (called sprites), usually arranged into a square. This format is often used due to the technical advantages, such as faster loading and fewer texture swaps when rendering. The disadvantage in this case was that the spritesheet was manually created, requiring extra time and effort. Making changes to any artwork would mean re-creating the spritesheet and redefining all the sprites in step 3.
  3. Import into the sprite editor.
    This was a custom piece of software that loaded the spritesheets and allowed the user (ie, me) to cut the image up into the pieces that would be used in the game.
  4. Select the pieces (again).
    Each time the spritesheet changed, the individual pieces needed to be relocated and re-exported.

  5. Mark the centre of rotation.The most important property for each piece was the centre of rotation. For animations and mechanical puzzles, objects such as levers, cogs, and even tree branches need to rotate around the correct point, or they look very strange.
  6. Save the sprite information.This extra information was saved in a separate data file that was loaded by the game at the same time as the spritesheet.

This is a fairly standard 2D content pipeline and one I've used successfully in the past. Unfortunately, with a content-rich game such as 39 Days to Mars this process became time consuming and unweildy. Making the best of a bad situation, I sat down and re-wrote the content pipeline to look like this:

  1. Draw the artwork.
  2. (Optionally) Select the centre of rotation. This can now be done during the painting stage without any external software.
  3. Click the export button.

Perhaps the change is a little exgerated, and the new method looses the advantages of having large texture atlases (for the technically inclined, I've not noticed any speed difference due to texture swapping yet, and this is only likely to become an issue on mobile platforms or old hardware). The technical trade-off is well worth it, because the time it takes to make a change to in-game artwork has dropped from ~15 minutes per piece to ~2 minutes.

Puzzles


As well as working on the art and content production, I took some time to bring the morse-code puzzle up to scratch. This puzzle has been in the game since before the Kickstarter, and the original implementation was a horrific mess of input code, state tracking, and graphics display code. The code was around 200 lines long.

It took me less than two hours to re-implement the puzzle using the post-Kickstarter interface code and display tools. The code is 43 lines long and also includes sound and lights. I'm really excited by how fast puzzle creation has now become, and I'm looking forward to getting stuck into the ship soon!

Watch this Space


At times it feels like I'm simply treading water, re-hashing old systems and re-coding things that already exist. However, the ease of creating new game and story content using the new systems gave me a real boost in morale this week and made me confident that fixing these issues early on was the right move.

Over the next fortnight I'm going to get the level playable from start to finish, bring the character graphics in, and hopefully find time to look into game analytics to make it easier for me to balance the puzzles.

If you'd like to keep up with the development, remember to head over and subscribe to the 39 Days to Mars development blog. Updates are also posted to Facebook, and I'm trying to tweet more about the development procces on Twitter. And as always, if you've got questions or comments just leave them below.

Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: