{"author_name": "localcoder", "cat": "LD #15 - Caverns - 2009", "comments": [], "epoch": 1252049700, "likes": 0, "metadata": {"p_key": "72466", "p_author": "localcoder", "p_authorkey": "1113", "p_urlkey": "108288", "p_title": "Cave Flyer afterthoughts", "p_cat": "LD #15 - Caverns - 2009", "p_event": "LD15", "p_time": "1252049700", "p_likes": "0", "p_comments": "0", "p_status": "UPD5", "us_key": "1113", "us_name": "localcoder", "us_username": "localcoder", "event_start": "1251417600", "event_key": "1", "event_name": "LD15"}, "text": "

I started with the idea of doing a ‘cave flyer, plus something cool’. I figured i would make the cave flyer first and the something cool later.

\n

Play the competition version here and the much easier updated version here.

\n

Using ActionScript

\n

I have only been learning ActionScript for a little while but I’m very happy with it. I quickly got the basics of a cave flyer going, and whenever I got stuck I found plenty of tutorials and discussions online.

\n

I used free tools only (FlashDevelop and Flex 3 SDK) and found them perfectly sufficient.

\n

‘Next Actions’

\n

I think that the best way to write game fast is to act as though your next half-hour might be your last. If you could only add one more feature, what would you add? And how would you get it working as quickly as possible?

\n

When I follow this rule, I get good results. When I don’t follow this rule, I get bad results. So I think it’s a good rule.

\n

Distractions

\n

I did not follow the rule. I wasted my first evening working on a feature that I didn’t need and didn’t finish.

\n

I wanted to make an AI-controlled ship that flew around like the player’s ship, resisting gravity and avoiding obstacles. It would have been super-cool. I coding up a kind of crude AI navigation map, and made a big if-statement AI controller for the spaceship.

\n

\"ai

\n

I realised quickly that it wasn’t going to work. My if-statement AI couldn’t handle the compexities of gravity, obstacles and thrust. But I was having fun and I didn’t want to stop, so I spent hours tweaking it. I only stopped when I had to go to bed.

\n

The final game didn’t use the AI player. I should have spent all that time making life better for my human players.

\n

Difficulty

\n

The game is much too hard. I knew that it was too hard, and I made it easier, but not enough. I think the best thing I could have done is popped a link to the game in the irc channel – someone would have immediately told me that the difficulty was a problem.

\n

Level Editor

\n

I made a very simple level editor. It allowed me to lay out the terrain on each level with mouse clicks instead of hand-coding coordinates. This was my best idea all weekend – it did not take long to make and it let me create level screens in seconds.

\n

Cutting Features

\n

I wanted to combine my cave flyer with another simple game genre to make it unique. I had plans of making a trading game where you bought and sold goods at different cities (seperated by dangerous tunnels), or perhaps a Legend of Zelda-like game with a large world to explore and items to find.

\n

None of that made it into the release. Partly because I couldn’t decide exactly what I wanted to do, so I delayed the decision.

\n

Last Minute Save

\n

I was running out of time. I had a flying game with multiple screens to explore, but I still had no goal or motivation for the player. I finally started following the ‘next action’ rule and attacking the most important problems first.

\n
    \n
  1. There was nothing to fight – so I added a simple enemy that hovered and fired at the player.
    2. \n
  2. There was no goal – so I made enemies drop ‘metal’, and added a metal counter to the screen.
    3. \n
  3. Combat was unsatisfying, so I added some explosion-effects.
    4. \n
  4. The player couldn’t respawn, so I implemented respawning.
    5. \n
  5. You collected metal but had nothing to do with it.
    6. \n
\n

Number 5 hung around for a long time. Finally, I hacked up a simple upgrade system. I wanted to add icons for the upgrades, but cut it for time. I wanted to add some clever upgrades, but cut it down to what I could do with the code I already had – most of the upgrades simply change variables that were already in the game, like the player ship’s “mass” (resistance to impact force) or its refire rate.

\n

The upgrade system was crude, but it gave the rest of the game a purpose – now the player had a reason to fight enemies and collect their metal.

\n

Colours

\n

I stole an idea from Meritous, where the world gets redder when more enemies are around. I like it.

\n

Conclusion

\n

Next time I’ll try not to get distracted on ‘advanced’ features when there are more immediate features that the game needs.

\n

I will make sure to do a user test on my game, to catch obvious problems like “It’s far, far too hard”.

\n

And if I’m making a “Classic Genre + Something Cool”, I’ll try not to wait too long before I add the “Something Cool”.

\n

Ok, I better get back to rating entries now…

", "time": "September 4th, 2009 2:35 am", "title": "Cave Flyer afterthoughts"}