Flash Game Development: part 1

So for a project for Uni, we have to build a Flash Game about whatever we want (within reason), and this seemed like the sort of opportunity that doesn't arise very often, so I brainstormed tons of ideas in my head for a while to try and come up with something that was simple but that was still good enough to draw people in for more than the typical "boredom time", and would hopefully gather a lot of plays on whatever website it would be hosted on. Bascially, something small, simple, fully realised, fun, and a decent length, which will be hard unless I have the right approach. I started by using some examples.

I started by exploring some of the games made by last years students. One of them is James Brittain's "Awesome Adventure", which despite looking a bit crap (Sorry James) is the best one on there, and it's the best one because it A: Works and B: Works for more than one level and C: Builds upwards; The player is taught the basics of the game on the first level, and gradually more elements get introduced. There are plenty of elements, but not so many that you will get bogged down and confused at any point. Sometimes you know exactly what to do, but it's the skill that proves to be the hardest obstacle to you, rather than the puzzle's solution. It's small and simple, which is exactly the sort of game that's good to start off with, I guess. It also has an interesting and different control scheme, rather than controlling the character directly, you have to guide them by clearing thier path and interacting with thier world with the mouse.

The second place I looked for inspiration was more "first time" games. Looking at games that were essentially someone's "First try" at programming ever, seeing what their overall aim was, and seeing what it was they eventually produced. Being so full of myself, I used myself as my first example. (pointless introspection ahead, but I figured it would be worth mentioning, since I learned a lot from it):

Back in 2002, I decided to create a fully free-roaming world that would be enourmous, full of detail, have a working ecosystem, deep combat system, compelling plot, and be filled with wonder and discovery. The early designs were promising as me and my brother pretty much threw everything at it, and the wonderous nature of the world we planned to create allowed us to throw almost any idea at it and it still to essentially "gel" together.

That project didn't achieve our high hopes, When I gave up on it four years later, we had:

• 0 levels polished to final quality.

• A combat system with an astonishing amount of depth, but only one enemy type with AI so basic it was no fun to defeat.

• Lots of parts of the world just floating off the map, waiting to be repolished to final quality but instead just sitting there never to be touched again.

• About two miles of mostly empty, uninteresting terrain. One mile of interesting empty terrain.

• basic physics.

• Worked with a plugin controller.

• Bad collision system.

• Most environments could only be traversed by debugging, partially because they took so long to walk across, since the computer struggled under all the world that was loaded at any one time.

• Horrible, clunky camera system.

• No semblance of story.

I feel the biggest mistakes I made on the big project were:

• No coordination: Me and my brother started working on this together, but since he was more of an artist than a coder, I pretty much took over the whole thing and made it mine, and eventually I know he began to feel left out of it, and I had essentially slammed the entire workload on myself. It gradually stopped being fun, and with me on my own, that team spirit was gone. I feel stepping away from it eventually was a really good idea, as I only realised these mistakes afterwards. We also both had different ideas on where we wanted the game to go, and since I was the coder, I essentially had authority, and it made it easier for me to shoot down his ideas. I didn't quite realise I was being such a control freak, and it resulted in me rejecting most of his ideas, including stuff that in hindsight was good.

• Bad ideas: Famous delayed game Duke Nukem Forever was originally set for release in 1997, until 3D Realms made the bizzare decision to switch from the Quake II engine to the newly released Unreal Engine. and I made several similar dumb decisions, like overhauling a lot of actually decent content, changing several key concepts during development (such as the switch from "wacky comedy" to more edgy and serious) and eventually it seemed more like there were four or so seperate games that this game wanted to be.

• Management: I had no idea of decent file management or RAM management, and as a result, I couldn't figure out why the game ran so slowly, or ran slower when I faced certain directions. It was because all the areas in this free-roaming world I had created were loaded in memory at once. It also explained the inhumanly long loading times. I built in a system to load and unload areas depending on how far away they were, which took about three months of lazy coding. This didn't work either, as objects placed in these ares would fall through the floor when the area was not loaded. So much stuff was happening that we hadn't even considered. This bug was not solved when we stopped. Another thing worth noting was the fact I actually started the game multiple times in the past, and not deleted old resources or versions of the game from several years ago, the folder was full of tons of unused crud and it would be a lot of effort to have gone through it and filtered it out.

On top of that, I had poor file management, the mesh files were all dumped in the same folder as the program, and the bitmaps for the textures, and the .x files that the meshes were exported as, there was no structure to it, and within the code it grew increasingly hard to figure out what did what. Fixing the file structure took about another series of months.

After I stopped, I started work on my newest game, which I'm still developing now, and actually getting somewhere with. On my new game I am:

• Still doing it in 3D, but using a fixed camera, and having it load and unload rooms when you go between them, it feels more enclosed, but that goes well with the nature of the game, which isn't as "outdoorsy" as the last one.

• I'm keeping things simple, There are about two classes of object: Scenery, and things you can interact with. The scripts for objects you can interact with is still slightly messy, but cutscenes are kept in text files and loaded when needed, rather than dumped in with the actual code. This makes levels easier to map and plan out. Content can be written into the game pretty much the minute it is finalised (which doesn't actually happen often enough, since writing is not my biggest strength.)

• I'm more organised. I'm doing this one on my own now, since my brother's working on a game of his own too. I only recently drew out tables and file structures on peices of paper pinned to my noticeboard, so I can keep track of what content needs to be produced, the order to produce it, and when it needs to be done, and what actually is done. I need to keep the workload from being too much for one person, and this is an area I'm still struggling with.

That's quite a big tangent I've gone on now...


The point I wanted to make was that you can learn a lot from your own mistakes, and that's why I definitley want to try something simple. Even games that seem simple on the outside are deceptively hard to make. One-man games that are actually top-quality, such as Cave Story or Iji took around five years to make, and are still shorter than most commercial games (but, also a lot better than a lot of commercial games, at least in my opinion. They've both certainly stuck in my memory.)

When I think of making games in a month, I think of Indie master Cactus, who is probably one of the most original and prolific indie game developers around today, he has made over 40 games, usually releasing several a year. What strikes me the most is how they all feel so complete and polished, and are often deceptively deep as well. His abstract approach to games is something I like, he forgoes usual pitfalls like pointlessly detailed graphics and walls of text in cutscenes in favour of creating a fully realised world using abstract ideas and characters, using as much as he needs to to make it work. This is similar to what Doug Church was talking about in the article Formal Abstract Design tools in regards to Super Mario 64, specifically:

"No one who plays Mario complains that they want to hollow out a cave and make a fire and cook fish, but cannot. The world is very simple and consistent. If something exists in the world, you can use it."

I've also been playing a lot of Nifflas' Knytt recently, a really simple platformer with about 5 buttons. Down to save, left and right to move, s to jump, and a to point to the nearest item. It sets you loose in a surreal, free roaming world with just these and the knowledge you have to find a ton of items, and then you do it. It's a "pick up and play" game in a way, it feels very "ambient", and you can just sort of launch it, play in the world a bit, then close it at will. I'd recommend playing it to see what it does so well. It feels like a tiny "anthill" world in a way, fully realised and abstract. An idea like this, but just with a perhaps smaller world (because the world in Knytt is pretty collossal), would be a good thing to make for practice (just as long as you don't rip it off, because that's bad)

So, in the end I started thinking of ideas that could incorporate simple controls and ideas and wring the most mileage from them it could. I'll go into that in part 2, if I'm still alive by then.