More Animation Work

I failed to update last night, I was -not- having a good evening with Gather Up code. The new control scheme seems to be working out, I'm held back in testing because it's as buggy as hell since it doesn't really fit with my old state machine that ran the character code. Additionally I had to do a ton of animation work since you can now be locked on and not carrying a gun. On the bright side I have wipped up a kinda nice flip animation for the overhead dodge, (although the hover part of it is still questionable).

I uploaded Level Up to Kongregate today and I've been swamped by another bunch of bug reports I feel like I'm probably going to miss my deadline at this rate. Which is annoying, since there is a new Ludlum Dare competition I would like to enter over the weekend.

The Toy and the Tech

I didn't do much in Gather Up today, so instead I'm going to talk a little about *drumroll* developmental process. One I've been using since I started making Flash Games solo over a year ago. If I liked to coin redundant terminology I would call it something like "The 2 T's". The Toy (the fun part of the game) and the Tech (unique features that the Toy depends on).

Right after conceptualisation (Hey! A platform game with levelling would be fun) the first two things I identify are The Two T's. For level up, the tech was the platforming engine. I spent about a week familiarising myself with Flixel and seeing what it could do. How tool chains would have to be set up and stuff like that. During this time I also started working on the toy.

The Toy is the part of your game, that no matter what HAS to be fun. It's especially important in a game where you are taking risks or you have some kind of message to get across. A well designed Toy, that makes the heart of your game fun, will save you against a lot of poor decision making down the road and makes the game easier to market. It's not to be mistaken with the 'main feature' as it isn't always the focus of the game. Just the moment to moment behind the scenes 'fun generator'.

To give a few examples of this. In Assassins Creed the toy was free running. However dull the rest of the game was, care an attention had been placed into the free running to make it fun no matter what. In Spore the toy was the various editors, the game itself was dull and repetitive in so many places, but the fun of being able to edit everything made it survivable.

In Level Up the 'Toy' was exploration. When I let people loose on the simple platformer prototype I had put together they mentioned a few things, that gems where fun to collect and that they enjoyed exploring the level. The 'Toy' in Level Up, thus became exploration. The level would be big and detailed with a wide variety of locations to visit. The breadcrumb trail of gems would give initial motivation to explore and give significant reason to level and reach even more areas of the map.

If a project fails at this hurdle, it gets scrapped. No second chances. You can develop a fun toy in about two days flat in flash so there isn't any point in trying to jam something into working when you could start over. If it passes the fun test at this point, then I turn back to tech and look at what I need to enhance the fun. Exploration is great but what this game needs is some background and character, so the need for Cut scene/Event handling tech is born.

The important thing here is I've now secured the safety of the new tech I'm working on with the fun toy I've developed than ensures the project is going to hit off.

In Gather Up, the first line of tech was handling multiple areas (I already have the engine from Level Up, so I don't need to worry about that). I knew it was a game that was going be bigger and have more environments than Level Up, so it needed area transitions. The Toy is the gun combat. Fluid movement between exploring and fighting. Focus on movement rather than aim. With the auto aim and jump the game stops being so much about how good your aim is and more about how good your reactions are and your strategy in battle which is why I developed the fighting core first. This makes the guns the tech that is need to support this toy and give it some depth.

In my opinion you can make a game about ANYTHING as long as your toy is good. You could make a game about things as dull as being a waitress or an amoeba. You can even get away with injecting some meaning into them without totally alienating players.

Level Up Fan Art

It's only been out a week and I've had a couple of fan works for Level Up!

This is from Rumrusher :


This is from Crell :


Really cool!

Level Up A Post Mortem

Back in July of 2009, I had just finished working on my word game, to an underwhelming reception and decided it was time for something different. I have a secret love affair with RPG's, and a public one with Platformers and after playing Upgrade Complete I felt inspired to create some kind of weird mashup of the two. The concept was very simple, a game with platforming movement mechanics and goals but with RPG stats for all the actions the user could perform. Jumping would level up and players could jump higher, Running would level and players could move faster. So on and so fourth.

I pulled together this fun little prototype of moving a girl around a 2D world collecting gems gaining levels. It was good, satisfying and I was getting lots of positive feedback about it. I had fulfilled that most important requirement most designers will tell you about 'make the toy first'. Building on my strengths, I started to add more exploration to the game and fleshed out the world a little. The JRPG parodies started to creep in at this point. This is how I finally arrived at having a narrative present in the game. Something interactive.

There was still something missing though. It was fun, but in a shallow way and once you where done exploring the world there wasn't really a big enough reason to continue playing. I had intended some kind of message about Levelling Up in video games (I had also been playing a WoW trial), but it wasn't really coming through. Which slotted the final piece of the puzzle, the Nightmare into the game.

It worked in three ways, firstly it created a situation where players lost something that took no skill to gain if they couldn't work out how to apply it. Secondly, it connected players directly to the character, she is suffering frustration with her losses, as did the player. Thirdly it added an element of challenge to the game, there was now an economy of time when playing.

Overall development went rather smoothly. The game took about 16-18 weeks to develop. I had originally planned a 3 month deadline, but extended it after adding the extra elements to the game to make it less arcade-y. To me it feels like a one of a kind game not because of the product, but the crazy chain of development choices that lead to the final product.

What went well:

1. The Flixel Framework

I cannot express how much of a joy it is to work with. Using Flixel I went from knowing nothing to having a fully working prototype up in about 3 weeks. The framework is pitched perfectly between simplicity and usability and still doesn't punish the game much speed wise. It really takes the edge off exclusively using FlashDevelop to create with.

2. Development Mantras

As I added new layers to the game, each one had it's own kind of mantra I associated with it. The rule of the level design was "Detail Detail Detail" as I wanted to the player to enjoy exploring the world as much as possible. The mantra of the overall game was "short but sweet". The mantra of the graphics was "Nothing but Cute" By sticking to these simple ideas I solved development dilemmas much faster and with a much more cohesive result. If it didn't add to the original intention it didn't go into the game. It's certainly a good solution when time doesn't afford for extensive documentation.

3. Mappy

When I first started working with Flixel, there was no editor for tile maps that was designed to work with it. Since then Flan has been released, but at the time I had to find a solution for designing the world. Like Flixel, Mappy works in a bare bones, no frills kind of way. Importantly, it supported Lua scripts for adding extra functionality. This worked perfectly for me, it took few days to come up with a script that exported in a Flixel Friendly form. Since I had complete control over how the data was exported, I could create something that was easy to import and it was simple to add extra data to the map file on import.

4. Characterisation

I worked a lot of detail into the world in the environment, but that wasn't going to be the end of it. The game needed NPC's to be truely reminiscent of a RPG. Thus the Roundites and Squarians the live in the world where born. Designing them was a challenge, inspiration of 'NPCs the reflect shapes' is pretty non-specific. The thing that really brought them to life was the writing of Keith Evans. I had been looking around for a writer/editor for a while, not only did he do it quickly and in a format that made it easy to get in the game but also turned each of the ten NPC's into a memorable and quirky archetype.

5. Ongoing User Feedback

I have a policy of getting player feedback from as early as possible. It can save a lot of trouble down the road in the sense that you don't spend a lot of time creating a feature that players don't use or aren't interested in. Very occasionally people will come back with things that lead to absolutely INSPIRED ideas that enhance the game

And some stuff that went not so right:

1. Bugs.

These absolutly SLAUGHTERED me on release.

I was amping down on the round of bug testing near the end for two reasons. One is that I wanted to keep certain details of the game a secret until release (this turned out to be unessential) the other is that since a lot of testers had started early, they where getting bored of playing the game. I know I was. So a couple of pretty nasty bugs made it into the initial build that went Live with the first release. This problem was then further compounded by two things. Firstly I didn't know that once a certain number of people had viewed the game I wouldn't be able to update for 6-12 hours after compiling. Secondly, I tried to push fixes to hard and fast that caused further bugs because I didn't take the time to test thoroughly.

It's been four days since release and I am STILL trying to fix bugs that appeared from the release version. The silver lining is that with the success of Level Up I should easily be able to find enough testers to make sure my next release is as bug free as possible.

2. Art.

I wanted some fancy art for the game. My own pixel art has come under criticism other game artists and I wanted something to help sell the game on the visual side. In the end I think it was a fairly unnecessary expense to go to. Only one bit of art was used in promotional material and a lot of users criticized the cut scene art. It didn't end up having quite the impact I intended it to have. In future I've got to look for a higher impact solution, more bang for my buck.

3. Mappy.

Whilst Mappy went right a lot of the time, there where a couple of initial teething issues that really killed me. There still are a few things about it that I still haven't nailed down. Specifically some features like enabling tile transparency and the lack of some kind of update/refresh button for importing graphics really slowed down level design initially. It wasn't that they didn't exist, it was just hard to find in a not particularly well documented, bare bones but robust tool. Having now established a pipeline these issues have been reduced. I have yet to find a better alternative, having tried several other Tilemap programs.

4. Feedback on Features

A couple of the game features where not signposted well enough. Particularly saving/loading, although also in a way the CODEX which had some hints on game completion. Many players where not away these features existed or how to use them. Some players where also confused by the game completion code. All of these features needed to be pointed out better in game.

5. MOD Playback

Early on in development I had decided the game should use MOD music to fit with the retro theme and to keep file size down. Less waiting time means a lower entry point and more people playing the game. Initially I started using a mod player called FlodPlayer, and wrote a Flixel Wrapper for it. This was seamless, but when the music came in from my musician (TripleFox) Flod completely distorted it. This put all my work to waste and I was basically lucky that the musician himself provided me with a packaged version of ModPlayer that I could use. A big drawback of this is it added part of a seconds loading time delay when playing when frame rate crawled. Based on this I think it would have been better to just go all out and use Mp3 music.

At the end of the project I am incredibly pleased with what I produced. The game radiates the attention to detail and care that went into it's development. It's given rise to a series that is going to keep me occupied for a fairly long time. All around I've been astounded by how incredibly well received it was considering I started out with the simple idea of a genre mashup game.