The original “psycho bean” is an idea my brother came up with many years ago during one of our sugar-fuelled game idea sessions. This challenge seemed like the perfect time to bring that idea to life.

Getting Started: Mind Mapping

Below are computerised versions of the two mind maps I used when coming up with ideas for the game. There are plenty of dead ends, but a few of the ideas filtered through to the final game. The decreasing energy seemed like a good way to go, and the transformational aspect tied into the whole “psycho” idea.

The original game was going to be a platform game with shooting elements (i.e. Mario with guns). As you can see, things didn’t end up that way.

A Brief History

I didn’t make a time lapse video, but instead took screenshots at key times of development.

	Version 1 The very first screen, taken about 2 hours into the coding process. Most of the assets were borrowed from Monster Mash to help get something playable as quickly as possible.
	Version 2 The first version with shooting and collision. At this point in development it was possible to spawn enemies, shoot them and jump onto the platforms.
	Version 3 This was taken at 8:30 on Sunday morning, roughly 10 hours before the deadline. The platforming was gone (as explained in “what went wrong”), and replaced with top-down shooting instead.
	Version 4 Two hours later, and the bullets were flying. There was still plenty left to do (more enemies, the weapons, points etc), but it was playable and more fun than the platforming.
	Version 5 This is the version that was entered. Bullets, AI, “Sugar Rush” mode and a statistics screen at the end.

What Went Wrong

I made most of the mistakes from Monster Mash, and some new ones too!

Even Slower Start — Saturday was the Reddit Triangle meetup, which took up most of the afternoon. Needless to say, not much code was written until the evening.

Scrapped Everything — When development ended on Saturday night I wasn’t happy with how the game played. The platforming didn’t feel right, and every now and then the player would stick to the ground after jumping. I didn’t think I’d be able to fix things in the morning, so a total rewrite was in order.

Graphics Dictated Gameplay — Switching to the top down perspective had a few side-effects. The biggest was the lack of diagonal movement and firing, which made the game less enjoyable than it could have been.

What Went Right

It Got Done — Like Monster Mash, at the end of the jam I had something playable. There were a few features that didn’t make the cut, and a lot of the game is unpolished.

Development Screenshots — Although I didn’t make a time lapse, I did want to capture what the game looked like at various points in development.

Scrapped The First Version — Moving from a platformer to a top-down shooter meant a lot of time was wasted, which can be a killer when there’s a tight time limit. Fortunately the changes made the game far more playable which is the most important part.

Lessons For The Future

Lessons for next time:

• Iterate faster. Get it playable. Make it fun.
• Don’t be afraid to throw things out if they’re not fun.
• Don’t worry if it looks stupid. It’s not a beauty contest (although having a nice looking game certainly helps to attract votes)

You can play the latest version here: Psycho Bean.

View all of the entries here: Reddit Game Jam #6: Final Submissions

The theme was "Metamorphosis", so straight away I was looking at things like Dali paintings, insects and mutations. My first idea was to mix a puzzle game with a festive picture, such as decorating a tree. I’m not much of an artist though, so a game where art is the primary feature wasn’t a good fit.

One idea that constantly came up was changing the appearance of something over time, either main character, the enemies or the world. I really liked the idea of attaching enemy parts to make yourself stronger, almost like Cyborg Justice or Biomotor Unitron.

In the end I settled on a simple version of "half minute hero", with some mutation bits thrown in for good measure. There’s lots of room for improvement, but the game was playable and pretty fun after a bit of tweaking.

What Went Wrong

Slow start — I didn’t actually start coding until about 16 hours in, which didn’t turn out to be a big problem, but those 16 hours would have been handy for polishing things up at the end.

Awful balance — The number one comment I got was that the game was far too hard. I’d originally intended to have about a dozen enemies to fight, but only had time to sprite 3 mutations so the rest were cut. This left the level caps and final boss out of balance, so the game was impossible to finish (although this was fixed shortly after the final submission).

Hidden Stats — There was no way to find out how much experience you had, your level or how many of each enemy you have defeated (to figure out how you’ll evolve). Again, this was planned but was cut at the end.

Unintuitive — Probably the worst part. There’s no obvious explanation of what’s going on, or how to get the various enemy parts, it just happens as you play.

What Went Right

It got done – This is the big one. At the end of the 48 hours, there was a playable game. Considering it was my first Flash, I was super excited. More importantly, it was a big confidence boost.

Planning saved a lot of time — I did jump in to code at the start, but took a break a few hours in to design the screen layouts and game flow. All the features I wanted were listed on a piece of paper in order of important, which really helped towards the end when things got tight.

Lessons For The Future

There were some excellent games entered, and I’ll admit the high quality really surprised me, especially given the short development time. Presentation played a big part in the higher rated entries, so that something to work on next time. Having a distinctive style is important to help you to stand out, although having a fun game is the key factor.

Lessons for next time:

• Spend time polishing and play testing. If possible, have someone else play the game too. I knew the rules inside out, so I couldn’t see the bigger problems.
• Join in. I worked alone and missed out on chatting with other developers. Next time I’ll hook up a second monitor and join the party.
• Make a time lapse video. I didn’t make one this time as it would mostly be me reading the Flixel documentation to see how things work, but I’m sad that I missed out on seeing how the game evolved over time.
• Start early, design more, get it playable ASAP. As soon as it’s designed, get something playable working. This helps with motivation, but also lets you know if you’re onto something fun.

You can play the latest version here: Monster Mash.

View all of the entries here: Reddit Game Jam #4: Final Submissions

Moaning aside, what’s been going on?

• Planning — As usual, I’ve been doing a lot of planning work. This includes designing screens and interface elements, as well as cleaning up some of the dirtier aspects of the specification. Some of it is fun, but most of it is quite dull.
• Coding Nuts & Bolts — More dull programming tasks, such as cleaning up resource management and creating a state manager. It’s as exciting as it sounds.
• Graphics — As you can see from the wonderful illustration, art is not one of my strongest skills. There are quite a lot of graphics that need to be done, so I’ve been spending some time on them. The game has a very “unique” look…
• Object / Entity System — Creating a component based object system took a while to get working, but it finally did something interesting. Unfortunately it’s a little bit too slow for production purposes, so it’s been left on the sidelines for now. It’s definitely something I fully intend to write about in the future, and I’m planning to use it in future games once it’s been optimised significantly. The best part was seeing all those sessions of design and coding pay off, even if it was only a moving box. Sometimes it’s so easy to get caught in the theory that you forget how much of a boost seeing something on the screen is.

Other fun things include the sale of my first and second Text Link Ads. Although they’re hardly going to fund a new lifestyle of champagne and caviar, it was a welcome confidence boost.

I’m not sure whether it’s a proper rut, or if I’m just struggling because nothing fun is happening. It doesn’t seem so long since I was able to code up a nifty demo in a few days, and yet I’ve been at this for several weeks and have virtually nothing to show.

Perhaps I should dye my hair black and write some poetry.

Moaning aside, things are going well in other areas. I’m getting to grips with a few project management applications, which I’ll be writing about in the future. I’ve also been polishing up a few of my libraries so I can release them into the wild. Writing unit tests and documentation aren’t the most entertaining tasks on the planet, but someone has to do them.

So what’s in store for the next few weeks and months?

I’m cleaning up some of my internal resources so I can release them to the public. They’re not exactly earth-shattering, but I find them useful and sharing things is always good. I always imagined this site as somewhere I could share my tools and code, so it’s about time I actually started doing it.

I’m also working on some interesting blog topics, including the next article in the “Game Design Lessons” category. I’m also preparing a few surprises in a few months, and I hope you’ll stick around to see what they are.

Here’s what’s been cooking (almost literally) over the last few weeks:

Flexible Resource System

So far this has turned out to be a huge time saver. Instead of altering code every time a new resource should be loaded, the application will scan the resource directory and load resources as required.

The current system uses XML to define which resources should be loaded. XML makes the whole system nice and flexible, and it’s easy to read and modify. Every resource used by the game can be loaded using this system, and each resource file has a namespace to avoid naming collisions.

Future improvements will add a “load on demand” system and a resource cache to help lower memory consumption.

Debugging System

The standard Blitz debugging system is somewhat lacking. It does the trick if you’re running your program from the IDE, but once it’s in the wild it’s useless. Naturally, I had to write my own system.

The logging component is quite simple, uses XML for storage and XSL to make it look pretty. It’s not particularly powerful, but it’s useful for getting system information and tracking function execution times. So far it’s saved me from a few problems, and helped me to smooth down a couple of time consuming functions, so it’s powerful enough.

Debug Console

I created a Doom style console that allows the user to manipulate game objects using a command line. It can also display internal information that can be useful for debugging purposes. It’s the sort of component that isn’t vital, but is super handy when it’s there. Just the ability to spawn objects manually is worth the time it took to create.

An Object / Entity System

This is easily the most time consuming thing I’ve worked on, and it’s also the most complex and frustrating. It’s still not finished, but it’s usable.

The main idea is to have a “pluggable” object that will be given different behaviours. At the moment, each object is made up of States, and each State is made up of Triggers. These triggers fire “Actions” when they are activated. For example, a treasure chest would have two states (“Opened” and “Closed”). A chest with the “Closed” state would have an “onInspect” trigger, which would run several actions when the character inspected it. These actions could include giving an item to the character, as well as playing sounds, animations and changing the state of the chest to “Opened”.

BlitzPlus doesn’t support true Object Orientation, so the whole system has been a bit of a battle. I’ve been using the “Blitz Virtual Machine” to script behaviour, and it’s working nicely so far.

Some Flexible Tools

To save time, I created an automatic build script that will build resources using a simple script. At the moment it’s a series of batch files and smaller tools, but I’ve started writing a Blitz builder that’s loosely based on nAnt.

The Blitz Builder uses an XML script to build the application and its resources, and each script can have various configurations. It’s quite simple at the moment, but it’s being built in a flexible way so new commands can be added easily using plugins. It also has much better output, so the full build process can be built and timed. No prizes for guessing what file format the output logs use…

Other Bits and Pieces

Other tasks I’ve been working on include designing a nice website for the project, trying out various project management tools and cleaning up some of my code libraries so they can be released at a later date.