But more than anything, I really want to get some eyeballs on the game and show an interested audience what BEEP is all about.

So my new goal is to have a ‘release candidate’ build ready by October 18th (the submission deadline for the IGF). With some blood, sweat and tears… that might actually happen.

Back in the early 2000’s, I experimented with various distributions while going to school. Since then, I’ve used Red Hat and Suse Linux at work (for computer graphics and animation work) and experimented heavily with Ubuntu at home.

In the past, I tried desperately to make Ubuntu my primary desktop system, but I always came crawling back to Windows when the mountain of incompatibilities forced me to admit that it ‘just wasn’t ready yet’. In those early days, I think I liked the idea of Linux, more than Linux itself.

Boy have things changed in just two short years.  My recent experience porting BEEP to Ubuntu linux has been a very pleasant one.  Linux has really come into it’s own as a viable desktop platform. And I’m very happy to report that my videogame, BEEP, is running great in the newest version of Ubuntu.

Past Experiences With Linux

In previous attempts at making linux my primary operating system, I inevitably ran up against a mountain of issues. Namely:

• Getting video drivers downloaded installed and working. (Having to resort to arcane shell commands is far more friction than I care to encounter when doing something as fundamental as making my video card work).
• Setting monitor resolution and enabling multi-monitors. I wish I didn’t even know what xorg.conf was. Editing this thing is about as much fun as chewing a ball of salt.
• Getting sound to work. Ugh.
• Getting wifi card to work. This is a real pain because without Internet, you have to go to another system and download the drivers onto a USB drive. Then upon bringing it back to your linux system you inevitably realize that the OS mysteriously refuses to recognize your USB stick. (FFFUUU!!!)

Apart from just getting the components and peripherals working, there’s the added benefit of learning all the ‘linux’ versions of all the applications you need (email, image editing, chat etc). But admittedly, most of these are actually better than their PC counterparts so learning them isn’t so much of a detriment to linux itself, just a hassle.

Why Do I Hate Linux?

Now, if it sounds like I hate linux, that’s only half true. I love linux for it’s potential, but I hate it for the snobbish, elitism extolled by some of it’s main proponents. I should qualify that. What I mean is, there is this pervasive attitude amongst the elite linux crowd that their OS is infallible. These uber-geeks maintain that any supposed ‘usability issues’ are in fact due to user error and ignorance. More specifically, they are unable to admit that serious flaws in linux’s usability are in fact, design flaws.

I subscribe to a very different philosophy. If I encounter friction in the process of utilizing a designed system, I immediately and without apology blame the designer. People routinely blame themselves for being unable to do something as simple as recording a TV show. I take the opposite route. I blame the VCR manufacturer.

I’ve designed so many systems in the course of my career, I can spot a poorly designed one in an instant.  I experience a creeping sensation that the task at hand could be done easier, faster and with less friction. Bad design infuriates me; whether it’s in a coffee machine or an operating system.

So I Think Linux Is a Bad Design?

NO! Linux is actually quite beautiful. At times, it can be downright elegant. The multi-desktop feature and window management are huge productivity gains. As is the speedy execution courtesy of the rock-solid Linux kernel.

Elegant though the foundation may be, Linux is often crippled by an inability to reduce the friction involved in everyday desktop computing tasks. Things as simple as configuring multiple-monitors, listening to an .mp3 (proprietary codecs) or installing graphics drivers can turn into time-sucking bouts of trial/error problem solving.

Granted, this is a bit of a chicken/egg problem. Without widespread support from hardware and software vendor’s Linux will remain replete with compatibility issues. But in order for vendors to dedicate precious development resources to Linux, they need to be assured of a sufficiently large consumer base on that platform. Which is something that will never exist until Linux is more widely compatible. Ugh.

Sometimes I fantasize about a world where the majority of software development effort was directed at linux instead of Windows starting way back in the 90s. We could have avoided Windows ME, Windows Vista and countless virus and security issues all while enjoying a faster, sleaker operating system. Imagine the cumulative savings our society would enjoy without the added operating costs associated with problems directly related to MS Windows security and performance issues.

Linux is a faster, more stable and secure platform. What it lacks is polish and a serious concerted effort on the part of the world’s commercial software houses to support it (with the exception of Google which reportedly uses Ubuntu in their offices and creates Linux versions of their major software products).

Apart from support, Linux also suffers from a willingness on the part of it’s userbase to look past it’s serious usability issues. I almost lost faith in Linux entirely until I heard about Ubuntu some years ago. Mark Shuttleworth (the benevolent dictator in charge of Ubuntu) is the rare Linux guru who fully admits that Linux is playing catch-up in the areas of compatibility and ease-of-use. Without at least a willingness to admit that there is a problem, Linux will wallow in obscurity for eternity.

I tested the early versions of Ubuntu and gained a hint of what Linux could be. But it always ended up failing me in some spectacular way (usually relating to graphic card compatibility issues). I could see the light, but the tunnel was really, really long.

Well, I’m happy to say that the new version of Ubuntu 10.04 is the first version of Linux I have used that did not require me to resort to command line hacks in the course of installation and setup. This is a historical moment of sorts. From start to finish, I was able to do my work completely and without sacrifice using only the GUI tools and applications.

In fact, upon starting up for the first time, Ubuntu 10.04 was able to:

• setup my monitor resolution perfectly
• get sound working
• connect through HDMI out to my HDTV. (with audio of course)
• setup/connect to wifi internet
• detect my windows network drive so I could stream my collection of movies/music/photos
• configure my second monitor. It magically popped up with correct resolution. I didn’t even have to configure it through a driver utility like you do in Windows.
• installed gcc compiler and Code::Blocks IDE from application installer UI

Needless to say, I was impressed. To be honest, I was expecting to spend a full day wading through online forums to find solutions to all of the above mentioned tasks. But I didn’t have to. IT JUST WORKED.

What About Porting BEEP?

Ok, enough of my opining on Linux. What about BEEP’s port? Well I’m happy to say that it’s fully compiled, linked and ready for distribution (just as soon as the content is complete!). The build process took fully two days of wrangling. There are always issues related to porting software systems between OSs. But mostly it was just a matter of squashing compiler errors (the open source C++ compiler, gcc, seems to be a lot more strict about enforcing the ANSI/ISO C++ standards).

In addition to compilation issues, there was the task of tracking down (and in some cases compiling) the Linux versions of the libraries that my game engine uses. At times it felt like I was going down a rabbit hole. But I emerged victorious! Seeing the game running in it’s full glory in Linux is a great reward.

Fresh off the compiler, it's BEEP in Ubuntu Linux!

Does Anyone Even Game in Linux?

Now after going through all this effort, you might be wondering if anyone is even going to care about a Linux build. To be honest, I have my doubts. But if other games are any indication, you can expect to gain between 5-20% sales by providing a Linux version.

How can this be given that most estimates peg Linux adoption at less than 3% of the total PC user-base? My guess is that those 3% of PC users are:

1. starving for content
2. much more likely to fit the gaming demographic
3. much more likely to want to support commercial software on Linux (Linux usesr tend to be a bit ideological)

So there you have it. My experience with porting BEEP to Linux was completely unlike past experiences. Linux development really has improved dramatically since the days of manual driver installations and hacking text files to set monitor resolutions.

I predicted 2 years ago that Linux would be ‘mainstream’ in 5 years. That was probably an aggressive estimate given the sluggish nature of software adoption. But if the newest version of Ubuntu is any indication, the future of this beloved Open Source OS is bright indeed.

But many of us had invested serious effort in making the pain of MEL scripting more bearable by finding and tuning a nice development environment. Over the past couple years I’ve been experimenting with different editors and IDE’s in an attempt to find a suitable replacement for Mel Studio Pro (my preferred IDE for MEL development).

Since abandoning Mel Studio Pro, I’ve gone through a host of editors including; Nedit, SciTE, Visual Studio, Code::Blocks, jEdit, UltraEdit and emacs. These are all great editors and I’m sure they each have a loyal following. Indeed, some of them are really quite good.

But when it comes to integration with Maya, they all fall flat. There are a few things you need when editing Python code that is meant to run on Maya’s Python interpreter:

1. The ability to execute the code from within the IDE and run it inside Maya.

2. A step-through debugger that pauses/unpauses Maya.

3. Auto-Completion that recognizes the Maya API and MEL commands.

The editors listed above could do some of these things, but none of them can do ALL these things. In my opinion, these are the real value of using an IDE in the first place.  Without these major features, the editor is really just a fancy Notepad with syntax highlighting.

Ok, enough preamble. The editor I have settled on is Wing IDE, and yes it will do ALL of the things listed above (plus a lot more). Most importantly, I was able to get it setup and working with little fuss. The only strike against Wing? It’s not free. But I think you’ll agree the price is fair. And after all, if you do a lot of Python coding for a living, this is a nominal expense. But you won’t have to shell out anything to see if Wing IDE is what you need since you can download a 30 day trial of Wing IDE.

To get auto-complete of Maya functions  working in Wing IDE:

1. Install Wing IDE

2. You have to point Wing IDE to Maya’s own Python interpreter (it will complain that it can’t find Python installed since Maya maintains it’s own Python interpreter). Just go Project > Properties and set ‘Python Executable path to point to : C:\Program Files\Autodesk\Mayaxxxx\bin\mayapy.exe

3. Next, download this Python script. And place it in the Maya\bin directory. Now open the Maya python shell (double-click Mayaxxxx\bin\mayapy.exe) and run the script like this: execfile(“genmayapi.py”)

That’s it! Now try import maya.cmds as mc and type mc. to bring up the auto-complete list.  Woot!

Now for the second trick. You want full debugger with the ability to watch variables and set breakpoints that pause Maya? Wing can do that too. Maya actually has it’s own instructions for doing this. Just follow the steps outlined here.

There you have it! A full, professional grade Python development environment that integrates beautifully with Maya.

A Wee Story

I am using XML as an intermediate file format between my level editor (built on-top of the 3d software package, Maya) and my game engine. Initially, I went with the minidom XML module because that’s what everyone used and it was well documented. It does work well, but I suspected that I could find something faster. And boy did I. ElementTree is an order of magnitude faster than minidom. I managed to shave off almost 10 seconds when exporting my levels. This is a HUGE benefit for me and is the reason I felt compelled to share this information.

There are two objects you need to worry about when using the ElementTree API:

Element – These are XML elements, so they contain the label (tag), a list of attributes and a list of children elements (forming the XML tree hierarchy). This is the object you deal with in 95% of your code.
ElementTree – These are ‘wrappers’ around Element objects that provide facilities to output the Element to an .xml file (along with all it’s children, recursively). You can also read an xml file into an ElementTree and then get access to the Elements within it.

Get on With It

Ok, to get started, import the module. It’s part of Python’s ‘xml’ bundle, you can find it here:

import xml.etree.ElementTree as xml

Now lets create an XML file from scratch and write it to disk:

root = xml.Element('root')

#Create a child element
child = xml.Element('child')
root.append(child)

#This is how you set an attribute on an element
child.attrib['name'] = "Charlie"

#Now lets write it to an .xml file on the hard drive

#Open a file
file = open("c:/test.xml", 'w')

#Create an ElementTree object from the root element
xml.ElementTree(root).write(file)

#Close the file like a good programmer
file.close()

Run the code above and open test.xml. You will see:

That bit of code represents everything you need to write an XML exporter. There are additional functions for parsing existing XML files (recursive searching, insert elements etc).

#Parse XML directly from the file path
tree = xml.parse("c:/testFile.xml")

#Get the root node
rootElement = tree.getroot()

#Get a list of children elements with tag == "Books"
bookList = rootElem.findall("Books")

#Check if any "Books" were found
if bookList != None:
    for book in bookList:
        #Do something with your book!

There’s some more esoteric information in the API docs found here:
http://docs.python.org/library/xml.etree.elementtree.html
And you can get more detailed information here:
http://effbot.org/zone/element.htm

Conclusion

Here’s the lesson: Use ElementTree as your XML parser in Python (assuming you aren’t already). It’s faster, easier and you already have it as part of the Python distribution. No need to ever touch minidom (and it’s wacky API) ever again. Enjoy

Any XML tricks or tips you want to share can go in the comments below.

With the popularization of 3d graphics in the mid-90’s, the platforming game evolved to utilize the extra dimension. But in the process of doing so, the 2d side-scroller was booted out of the spotlight. Since the mid 90’s, 2d platformers have eeked out a living on the margins of  the mainstream. It would be fully 10 years before this genre would experience a nostalgic revival. Why is it coming back? How has it changed? Is it worth reviving?

Out of Necessity

Waaay back in the early years (late 70’s – early 80s), single screen games dominated. They were easy to program and could easily fit into the memory and CPU limitations imposed by the available hardware. Single screen games include all the major stars of the arcade era; Pac-Mac, Donkey Kong, Asteroids, Galaga, Frogger and Pong. Single-screen games definitely have their place, but it’s difficult to gain a sense of exploration and advancement when the player stays in the same area.

Everyone who played Asteroids imagined what it would be like to drive the spaceship beyond the edge of the screen. Side-scrolling really is a natural extension of the single-screen game world. It wasn’t until 1980 that the first side-scrolling game was released; Defender. Now you COULD take the spaceship to the edge of the screen and explore an area that spans many screens. Suddenly, and for the first time, a video-game gained the added dimension of spacial exploration.

Mario

In the wake of Defender, gamers and developers were left thinking of all the different ways that side-scrolling could revolutionize the established gameplay mechanism (and inspire new ones). Defender can be viewed as an extension of Asteroids which spawned the scrolling shooter genre (which would be perfected 10 years later by the Raiden games).  Similarly, Super Mario Bros can be viewed as an extension of Donkey Kong from single-screen to side-scrolling.

Super Mario Bros. exploded onto the scene in 1985 to coincide with the release of Nintendo’s NES console. Finally, the jump and run (ie. platforming) gameplay was married with side-scrolling technology. The result became one of the best selling games of all time and spawned a litany of sequels and knock-offs.

But the game that remains firmly planted in the social consciousness was Super Mario 3. This was really the culmination of decades of innovation in computer science and game design. For the first time, gamers were playing a character that really looked like something. Mario wasn’t a block of pixels, he was a cartoon character with personality and animated movements. But even more important than the visuals, was the insanely tight control mechanics. I would argue that Super Mario Bros 3 perfected ‘twitch’ gameplay. Even after almost 25 years, the platforming genre remains saturated with gameplay mechanics that owe their origins to this game. It sold 18 million copies and it’s 2006 sequel (New Super Mario Bros. DS) has sold over 21 million copies. Both games enjoy a spot in the top ten selling games of all time.

The Gameplay

So what is it about platforming that makes it so fun? Finding the source of ‘fun’ in a videogame is a difficult thing. Most people know when they are having fun, but few people can explain precisely why they are enjoying something. I would like to argue that 2d-side scrolling games (the good ones anyway) possess only a few basic traits which people enjoy.

Most obviously, there is the timed jumping (or ‘platforming’). This is as basic as it gets, you have to get from A to B taking into account constraints C,D,E and F. This is the generic form that all platforming gameplay takes. Common constraints includes things like, limited jump height, moving enemies, death pits, fireballs, moving platforms, tilting platforms, disappearing platforms and on and on. In general terms, these can all be view as constraints that combine to create an environmental puzzle. Overcoming these obstacles and finding the right combination of manoeuvres that satisfy all the constraints is what makes platforming fun. In a nut shell, chaining together actions to satisfy a series of constraints is the reason Mario is fun.

Additionally, platform games tend to exhibit a sense of exploration and progression. That is to say, the player feels like they are making progress as they explore an environment. That may seem trivial, but there are many things that the developer must do to keep this intact. The ‘world map’ gives a sense of Mario’s journey to save the princess. The player can look back at the places they have been and anticipate the levels to come. It seems obvious, but many platform games since Mario have failed in this regard. And before side-scrolling, single-screen games were really at a disadvantage in giving the player a world to explore.

Lastly, good platform gameplay immerses the player in an alternate reality. It’s about escaping to a world that exhibits a peculiar version of the Newtonian physics we are familiar with. Playing in alternate realities teaches us about our own. Super Mario Galaxy asks us to consider a world in which gravity can be reversed with a switch. Games like Braid confront the player with a world where time itself can be manipulated and reversed. Playing with alternate law of physics is what excites me the most about videogames, and no genre does it better than the Platformer.

The Revival

As you can probably tell, I really really like platform games. The last console generation (Gamecube, Xbox, PS2) was a terrible time to be a platformer fan. For reasons that I still don’t fully understand, the genre was largely ignored. Maybe it was furor created by the introduction of 3d games, but more likely it was short sighted studio executives that saw it as a ‘dead’ genre. 21 million sales of New Super Mario Bros. suggests the genre is far from dead.

Regardless, there is certainly a revival in the works right now. While mainstream releases like the new Super Mario Bros and Mario Galaxy games are certainly a welcome addition, the indie community is really leading the revival. Braid, a beautiful independently developed game by Jonothan Blow has more innovation in a single pixel than the vast majority of mainstream games have in their entirety. But it’s primarily a puzzle game with extremely light (and thanks to the reverse time feature), largely inconsequential action platforming. Action platforming fans should check out Knytt Stories to see an example of the finest in minimalist action platforming.

There are many other recent titles I’m failing to mention, but the point is that a revival of the genre is here, it’s a good thing, and it’s been largely driven by independent developers around the world.

BEEP

So how would I classify my own game, BEEP? Well it’s certainly a 2d side-scrolling platformer. But it’s also a shooter. The player aims and fires with the mouse which gives it a first-person shooter feel. I’m calling it, ‘Mario… with a gun’. Gaming enthusiasts might argue that the side-scrolling shooter genre exists and was established by games like Contra, Bionic Commando and Metal Slug (all games that I enjoy).

I would agree, but BEEP is different from those games in one very important way, the mouse. The Contra games used a d-pad for aiming which limits the precision of the shooting mechanic. This control system has a dramatic effect on the feel of the game. Aiming with a d-pad is more about controlled chaos than precision shooting (especially in the Contra games which get ridiculous in the amount of on screen clutter).

Additionally, BEEP includes a gravity gun. You hover the mouse over a dynamic object and click-hold the right mouse button to pick it up. This effectively becomes a virtual hand that the player can use to reach into the game world and move stuff around. The gameplay ramifications of this are profound. I’m still exploring the possibilities this control mechanism enables. So BEEP is the marriage of Mario (running, jumping) and Half-Life (precise shooting, gravity gun). At least, in theory. We’ll see if the audience agrees once it’s released into the wild.

There were many reasons why I chose to make a 2d side-scroller. But chielfly among them was the richness and diversity of gameplay options that the genre possesses. With utmost humility, I must admit that the majority of BEEPs gameplay is inspired by existing games. But by understanding why these classics were fun and what made them fun, I hope to replicate their success, learn from their victories and avoid their pitfalls. In the process, maybe I can push the genre forward a little bit and make something that people want to play; even if they aren’t sure why.

Level design is definitely the most labor intensive aspect of BEEP’s development. Actual construction of level geometry is constantly being interrupted by the need to switch to an art program to design a texture. Or if it isn’t art, then I get distracted by the occasional tweak to a piece of the level editor or engine code. Level design seems to be the place where 90% of the nagging ‘mini-bugs’ are found and dealt with.

But even though it’s challenging and a bit dull at times, level design has huge pay-offs. It’s a blast to come up with devious scenarios and challenges to test a player. Not only that, it’s crucial to the success of the game. It IS the game. As a developer, I have to remind myself that the gamer isn’t playing your fancy lighting system, or your clever level editor, or your super-slick texture manager. The gamer is playing LEVELS and all that other stuff has to serve that singular purpose.

As I’ve discussed in a previous article, I’m using Maya as my level editing environment. I thought I’d share a quick video to show what a level looks like in the editor.

The level editor is built on top of the commercial 3d software package, Maya. A custom built exporter uses a web of message connections between nodes to define all of the various assets that comprise a level.

This data is traversed by a Python script and compiled into an XML file that is loaded by the proprietary Bonk 2d game engine.

The ‘node’ and ‘message connection’ pattern used by Maya maps nicely to the engine’s object and pointer representation. So if a relationship is needed between two level objects (like one is a child of the other) then this is represented as a message connection in Maya, which is stored in XML and ultimately becomes a C++ pointer relationship in the engine.

I’ll leave you with a screen-shot of what the level looks like in the game with all the decorations applied.

(click for full size)I left the debug drawing on in this image. You can see a blue ray coming out of the robot towards the player. This is his ‘eye sight’ which at the moment is being blocked by another enemy. You can also see some red rays coming out of his sides. These are used like whiskers to tell when he’s about to bump into something.

Audio

Before embarking on an expensive endeavor, it’s prudent to establish what aspects of it present the most risk. For BEEP, I knew I could handle the programming, visuals and marketing. But the audio has always been looming like a dark cloud over the entire project. Initially, in my naivete, I presumed I could spend a few months at the end of the project recording my own sound fx and purchasing tracks off the internet.  But it quickly became apparent that this wasn’t going to get me the consistency and quality of sound that I think the game deserves.

So to remedy this, I set off to find someone who could bring some experience to the project. I had some simple criteria. No students (I simply can’t risk it) and no garage-bands. I needed a professional I could count on to understand the game and be able to do original sound AND music. I scoured the internet and talked to a few different people before finding a chap by the name of Francisco Furtado from Portugal. I was impressed by his business acumen, proven experience and enthusiasm for video-game audio. After a bit of back/forth emailing he has agreed to come on board! Big Fat Alien has our first hire! I can’t wait to see what he comes up with.

Beta Testing

Now in addition to audio, the second biggest risk was my target platform, the PC. PC’s  (and Macs) are notoriously riddled with compatibility issues due to the vast array of hardware on the market. I’ve managed some of this risk by using middleware that abstracts the driver interfaces for graphics, audio and input so I don’t have to get into the nitty gritty (and boring as hell) stuff.

But it’s not enough to do your best and hope your game runs on all machines. You have to TEST. So I’ve begun sending out alpha tests to individuals who can run the game on their machine, email me their specs and let me know how it all went down. This data is crucial to the development of a stable piece of software. (If you want in on the next beta test, please send me a note kiaranritchie@gmail.com , I could always use more).

UI

The best user interface is the one you don’t notice. At it’s most basic, BEEP requires SOME method to allow players to perform basic high-level commands like, load a level, restart a level, pause etc…

I find 90% of videogame UI’s to be aesthetically disgusting and functionally retarded. The problem is usually a case of too many dials, knobs or tabs compounded by an inconsistency of controls and distracting visual arrangement. Basic ergonomics, it seems, continues to elude even the most seasoned video-game studios.

With that in mind, I set off to create something that would avoid all these pitfalls. It had to be simple, to the point and retain a sense of fun and visual elegance (nobody wants to play something that looks like a spreadsheet). I have only a half-dozen menu’s in the whole game and they all use the same visual arrangement.

When the user enters a menu, I apply a soft Gaussian-blur filter to the background. This is to draw the user’s attention to the menu. The mouse changes from the targeting reticule used in the game to a normal arrow pointer (so there is no question that you have to click on something now). All the buttons are stacked in a single column with most likely candidates at the top going in descending order. The button text is written in a clear, bold sans-serif font that changes color on hover. It’s all so painfully obvious a stoned monkey could use it.

It’s nothing fancy, and that’s the whole point. Check out the video to see what I’m talking about:

World Map

BEEP is a platform game, with a linear progression across levels of increasing difficulty. This is a formula I didn’t feel the need to divert from. It works and people understand it.

But part of this design is the need for a world map that frames the player’s progression and provides a mechanism to chose which level to play. I initially designed a world-map that works much like Super Mario. You have a small representative avatar basically sliding around a 2d-map between nodes that represent the different levels.

There’s a lot to like about this design. It’s simple to use and get’s the job done. But in the end, I decided to try something different.

I opted to replace the sliding-between-nodes map with  a mini-game involving a spaceship that the player pulls with the mouse.  The player simply directs the spaceship towards a drop zone in orbit around a planet.

From these zones, you can deploy a BEEP-Bot (the player character) to a specific level. It’s not quite as simple as Mario’s world map, but the slight loss in simplicity is acceptable given the benefit that this method communicates to the player exactly what he’s doing; flying around a solar system sending little robots down to the surface of planets. It killed two birds with one stone; picking levels, and telling the story. As a bonus, it’s actually kind of fun to drive the spaceship around smacking into asteroids and avoiding the sun.

Check out the video to see what I mean:

Losing It Mentally

This is an article about risks. The last risk I have to contend with is the possibility of losing my motivation. Writing this blog is cathartic. My huge network of friends and family provide a lot of support too. But at the end of the day, it’s just me in front of a computer GSD (Getting Shit Done).

I’m still pretty passionate about the project. The game is looking good which helps a lot.  I keep waiting for the day when I wake up and hate my game (I fully expected to be there by now). So far that hasn’t happened which is either a sign that I’ve lost all ability to judge my own work, or maybe, just maybe, it’s actually a fun game.

One thing I didn’t expect from this endeavor was to learn how to thrive on stress. I found out my wife is pregnant a few weeks after quitting my job (Cool? Yes.  Stressful? Yup). I’m into this game for a significant portion of our life savings. I haven’t got a single level completely finished yet.  I’m living in my in-laws basement and haven’t seen a sunny day in about 3 months now (that’s no exaggeration, winters high-up in the Okanogan Valley are very cloudy). Extraneous expenditures have been cut; no trips to the ski-hills, no hotel weekends and certainly no vacations. No paycheck.  No restaurants nearby. And the neighbor dogs keep attacking ours.

But despite all that, I’m having a great time. Working on this game is a joy for me. Getting to know my wife’s family better has been awesome (they are all reasonable, fun people which makes all the difference). And the thought of having a baby on the way is just a little more fire under my ass. Ain’t no thing but a chicken wing.

Commercial Software:

• Autodesk Maya – digital content creation
• Beepa Fraps – recording OpenGL viewport
• Microsoft Windows XP/Vista/7 – yeah, I need all of em

Open-Source Software:

• Audacity - for audio editing / recording
• Firefox – internet browsing / operating system
• Open Office – word processing / spreadsheets
• Ubuntu Linux – for compiling/programming
• gcc – my C++ compiler
• SciTE - text editing in windows
• Code::Blocks – programming IDE
• VLC Player – multimedia playback
• Flyspray – project management / bug tracking
• Gimp – 2d image editing
• InkScape – 2d vector art (all of BEEP’s art is done in InkScape)
• SpeedCrunch – a handy general calculator program

Online Software:

• Gmail – email
• Facebook – marketing
• Twitter – marketing
• Wordpress – this blog
• Dropbox – online backup storage
• Vimeo – online video storage
• Google Analytics – awesome web statistics
• Google Search – research, research, research

Hopefully you found something you can use. I’m a bit obsessive about finding the right tool for the job so you can be assured these are all descent-to-excellent applications.

Interesting how short the list of commercial applications is! But Maya costs enough to feed a small country so you can’t accuse me of being anti-capitalism! (And no, Blender is not a viable free alternative to Maya. It’s just not.)

Am I using something dumb? Missing something obvious? Let me know in the comments below…

According to Wikipedia, a finite state machine is:

a model of behavior composed of a finite number of states, transitions between those states, and actions.

State machines are literally everywhere in almost every kind of software. Videogames take them to a whole new level with additional models like Heirarchical Finite State Machines and Decision Trees.

But often times, you just want a plain old vanilla state machine with the ability to:

1. Perform actions within the current state.
2. Transition to any other state from the current state.
3. Perform exit and enter actions during a transition.

That’s about as simple as a FSM gets. What follows is my attempt at creating an extensible and simple FSM that can literally be used anywhere you need it and on any platform (Win/MacOS/Linux).

It works like this: there are two objects, finite state machines (FSM) and states (FSMState). A state machine contains a collection of states within it (I’m using std::vector to store the states which are first wrapped in an std::tr1:shared_ptr so you don’t have to worry about garbage collection).

So the first step in setting this up is to sub-class FSMState to create new state type for each state in your machine. An enemy AI, for example, might have IdleState, ChaseState, AttackState and DeadState. Each state has an Update() function that performs actions when the FSM is in that state. It also has a OnENTER() and OnEXIT() functions that can be overidden to perform anything you like when the state is first entered, or when it exits.

When FSM::Update() is called, the current state in the machine has it’s Update() function called which will perform the actions for that state and possibly trigger a transition. If a transition is triggered, the FSM will automatically call the DoEXIT() and DOENTER() functions for the old and new states respectively.

Getting Started:

To setup the FSM:

1. At the top of your C++ source: #include <FSM.h>
2. Create a new state machine: FSM *myFSM = new FSM();
3. Create a bunch of FSMState sub-classes (your states).
4. Add each states to your FSM like this: myFSM::AddState();

Once the FSM is setup, just call myFSM::Update() to keep the machine running!

NOTE: One trick here, I’m using the Boost shared pointer implimention to store the states. This is NOT a part of the C++ standard, but seems to be ubiquitous in it’s adoption and usage in the industry. In order to use it, you will have to download and include these libraries (not a difficult task). Hopefully this inclusion doesn’t disqualify this code as being ’simple’.

FSM.H

//FSM.h
#ifndef FSM_H
#define FSM_H

#include <iostream>
#include <string>
#include <vector>
#include <memory>

class FSM;

//An individual state (must belong to a FSM)
//This is an abstract class and must be sub-classed
class FSMState
{
public:
  FSMState(){};
  FSMState(FSM *fsm){};
  virtual ~FSMState(){};
  virtual void Update(const float& dt) = 0;
  virtual void DoENTER(){};
  virtual void DoEXIT(){};

  std::string stateName;  //used to switch between states
  FSM *fsm;
};

//A vector of shared pointers housing all the states in the machine
typedef std::vector< std::tr1::shared_ptr<FSMState> > StateBank;

//---------------------------------------
//A Simple Finite State Machine
class FSM
{
public:
  FSM();
  ~FSM();
  void Update(const float& dt);

  void TransitionTo(std::string stateName);
  void DelayTransitionTo(std::string stateName);
  void AddState(FSMState *newState, bool makeCurrent);
  std::string GetState();

public:
  FSMState *currentState;
  std::string delayState;

   //Bank to house list of states
  StateBank stateBank;
  std::vector< std::tr1::shared_ptr<FSMState> >::iterator iter;
};

#endif

FSM.cpp

//FSM.cpp
#include "FSM.h"

//Constructor
FSM::FSM()
{
  currentState = NULL;
  delayState = "NONE";
}

//Destructor
FSM::~FSM()
{
  stateBank.clear();
}

//Update each tick
void FSM::Update(const float& dt)
{
  //Make sure a current state is loaded
  if (currentState == NULL) return;

  //Check if there are any delayed transition requests
  if (delayState != "NONE")
  {
    TransitionTo(delayState);
    delayState = "NONE";
  }

  //Update the current state, may trigger a transition.
  currentState->Update(dt);
}

//Called to transition to another state
//@param stateName the name of the state to transition to
void FSM::TransitionTo(std::string stateName)
{
  //Find the named state
  FSMState *goToState = NULL;
  for(iter= stateBank.begin(); iter!= stateBank.end(); iter++)
    if ( (*iter)->stateName == stateName )
      goToState = iter->get();

  //Error, trying to transition to a non-existant state
  if (goToState == NULL)
  {
    //Print an error here, or assert if you want
    return;
  }

  currentState->DoEXIT();
  goToState->DoENTER();
  currentState = goToState;
}

//Transition to another state (delayed until beginning of next update)
//@param stateName the name of the state to transition to
void FSM::DelayTransitionTo(std::string stateName)
{
  delayState = stateName;
}

//Add a state to the bank, optionally make it the current state
//@param newState the new state to add to the state machine
//@param makeCurrent is this new state the current state?
void FSM::AddState(FSMState *newState, bool makeCurrent)
{
  //Add this state to the FSM
  std::tr1::shared_ptr<FSMState> newStatePtr(newState);
  stateBank.push_back(newStatePtr);
  //Make this the current state?
  if (makeCurrent) currentState = newState;
}

//What is the name of the current state?
std::string FSM::GetState()
{
  return currentState->stateName;
}

What you  see in the video is definitely an ‘alpha’ build. There are lots of missing features, (notice the complete lack of sound effects) but I think for the first time you can get a taste of the type of game we’re going for.

This is a quick play-through of a world we call  “Rolling Hills”. It’s a bouncy, safe-looking environment that acts as an introduction to the character and controls. Once established, the player will be gradually forced into increasingly sinister environments.

As always, feedback is welcome!

BEEP Game Alpha Preview from Kiaran Ritchie on Vimeo.