I have always loved programming - its like Lego without gravity.

Basic on my ZX81 graduating to assembler and Turbo Pascal during my teens.

Developed phone OS software - engineer, architect, product manager - but got made irrelevant by the iPhone and redundant by Android.

These days I mostly work with data, big data and fitting big data onto small boxes.

Cage Flight post-mortem #2: the graphics guy

(Originally posted to Ludum Dare; this was written by my co-conspirator)

At the ungodly hour of 7am on Saturday 25th August we found out the theme, and had a bit of a brainstorm whereby we arrived at fighting, in space, in a cage. Obvious really.

To play Cage Flight: http://www.ludumdare.com/compo/ludum-dare-24/?action=preview&uid=10313

For a more technical post-mortem see http://www.ludumdare.com/compo/2012/08/30/cage-flight-autopsy/

We started a bit behind due to time zones, and we had a bit shorter anyway as although the deadline for jam entries is not until Monday evening, Monday is a work day for both of the team. But that’s no excuse, we still had plenty of time to build a game. Our team this time were:

Concept: Joint between Will (http://www.ludumdare.com/compo/author/william_edwards/) and me, with him having final vote

Coding: Will

Art & Audio: Me

Special thanks: A guy called Philip (Dev in 0AD) for timely advice, Glest community for play-testing and game-play videos

Start

Not a bad start. For a moment our hearts sunk as going in we’d assessed Evolution as one of the more challenging themes as it implies characters having to evolve. But despite the initial glumness we suddenly made the association to Natural Selection and Survival of the Fittest and saw that that can be misinterpreted to me conflict, combat and generally fun/cool things. We put aside our ideas of simulated deer populations and focused on the essence of conflict, one against all combat to the death. Um, in a cage, in space. In parody of MMA/UFC, we called it Cage Flight. It’s a multi-player in-browser flight-combat game, quite arcade and really basic in the sense it’s just you against everybody.

Graphics

This wasn’t really a challenging graphics assignment for me. Unlike the LD23 entry which was two days of solid drawing (http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=10313). Overall we are quite pleased with the graphics; they give it the feel we wanted and look decent enough. Of course we’d do more and better if we had more time.

2D graphics

I did the game intro flash within the first couple of hours. I had a brainwave to pay homage to the Streetfighter logo:

It’s not a straight copy of course, but by-eye that’s the feel I wanted to give it. A bit comic/pop-art, a bit retro and not taking itself too seriously. To balance the Streetfighter bias at the beginning, I made the death splash a Mortal Kombat reference. We also had a splash for winning but it isn’t used as the player just plays until they are either killed or close the browser window.

At the end we also had the idea of combining the intro flash with the help menu, so we added a graphic to show the keyboard controls. Except that we kept changing the controls as we play tested so I kept having to re-do it.

Models

We opted for G3D models created in Blender. This is the format Glest RTS uses so we are familiar with it. It’s not the best format in some respects but completely adequate. A few tricks I employed to speed up the mass-production of models:

a) All models use the same base texture. It’s a 256×256 PNG with no transparency or team color etc. I don’t do the typical way of skinning models, I can’t explain it but an ex[erienced blender artist would think it’s quite basic what I do, but it’s quick.

b) Each model is an evolution of one of the previous ones. Not starting from scratch. I manipulate base meshes like cubes and cylinders, and never use sculpting. Everything is by eye.

c) Little re-work; generally I make it up as I go along and live with the results.

We intended to have 8 ships – I wanted to have a pre-game lobby where you pick your ship and maybe even your camouflage scheme. Each ship would have different stats, so you would chose firepower against armor etc.  Will didn’t think it added anything so we just made the player have a random ship. All the ships perform equally. Also, firepower and armor became irrelevant – due to time we went for 1 hit 1 kill which played better anyway.

Early iteration of ‘Rhino’ space fighter, and in-game version. Every time I tweaked the texture it was applied to all ships.

The design of this ship is influenced by helicopter gunships and mechs

Audio

Not my thing but I’d found Audacity and Bfxr. Great for sound effects. I made masses of sound effects for power-ups, explosions and collecting coins. The only one we ended up needing was the lasing zap (yep, we know lasers don’t make sounds).

We had planned to record human voice for intro and narrative. We tried but my microphone wasn’t up to it and I couldn’t figure out how to remove background static. So frantically I searched for text to speech programs and found an online version of Mary text to speech engine. Great, very pleased with the results!

Things we dropped

  • Client-side slerping
  • Coins, credits and scoring. Health points, power-ups
  • Ships having distinct flight/combat charactristics
  • Explosion effects
  • Winning criteria and flash, high-scores board
  • Cockpit-view

Good and bad

Well the graphics were a success, and well within the time limits. We didn’t have time to add explosions, particles or better laser effects (currently draws a line programmatically).

During the build our main pains was around Quaternions. See Will’s autopsy for details of that. Due to that we ditched some features but actually simple is better anyway.

In the final play our main problem is simply server FPS. Our server was running at 8 FPS and now 12 FPS. From feedback people are expecting more.

Another problem is that it’s multi-player. That was what we set out to build, but it means that if you join the game and no one else is in, there’s not much for you to do. A third problem may be the flight controls. They are configured for things like speed and turn rates to be cumulative, and I think some people may mistake this as lag or general unresponsiveness.

Evolved version

Are we going to continue building the game with credits, health points, player personalisation, high-score keeping, client side drawing… no. We are deep in playing and rating other people’s LD submissions and already we are inspired to build completely different games.

BRING ON LUDUM DARE 25!!!!

jump to ↓



performance
Faster searches with non-prefix fields in composite indices
Compressing MySQL databases
What highscalability.com says about Scaling my Server
Scaling my Server: follow-up
old classics
The kid's computer
Making the History of Worlds Religions map
If you defend those involved in the OpenGL ES specification, you are an idiot
Stackoverflow unwinding?
general
Why Swift?
Python annotations and type checking
pycon 2014 Sweden: the bad bits
Table-based Template Translation in C++
recreation
games programming
Perlin Noise
Perlin Noise
Drawing RTS maps fast
WillCity update
ludum-dare
Ludum Dare #35 Mosaic
LudumDare 33 wallpapers
SSIM vs MSE for Mosaics
Ludum Dare 30 results are in!