Wednesday, February 22, 2006

Some Game Philosophy Part I - Differences Between Applications

Before we get started, I'm going to discuss some thoughts on game and applications programming. First, the most important rule:

- "Resist the temptation to code."

Those were one of the first words of my Software Design professor. It's only natural, especially with game programming, to want to jump right in and start coding graphical engines, data structures (or databases), and so on. The problem is that you'll just wind up getting entangled in your own code.

On to game programming, sometimes I heard people saying that game programming is much different than business application programming. On the contrary, I think they're very much similar, save for a few differences. It would be like saying gorrilas and chimpanzees are two different classes of animals, when in fact, they're much closer, save for a few differences. Here's several points I'll make about different features:

Graphics - Maybe back in the day when 2D was king, there really weren't many 2D business applications being used, unless you want to consider paint programs. Even those don't have flashy special effects. These days, 3D is king (for better or for worse), and even engineering (movie special effects as well) programs utilize this.

Event System - RPGs are notorious for having many events to progress the storyline. But, what are events? They're merely a category of tasks to perform. Take a look at a SQL Server database. It has "Jobs" and "Tasks". While not called "Events", whenever something happens, such as the time is 12:00am, a job, or event will trigger and perform certain actions. A game can even have an event that says, "When the timer hits 0, run these series of actions".

Data Structure - While on the surface, they can be completely different, there are methods behind the madness. A game may have units that are built, and a user table may have user names that are created. There structures may look quite different in the names of their fields, but the data behind (strings, integers, booleans, etc.) will be similar. Granted, it may have more than one datatype than another, but the idea is there.

Customizable Features - Some might think that "add-ons" and "mods" are stuff of games and scenario creation. However, there is a 3rd party utility where I work that has just this feature. It's a Case Management Tool (Not to be confused with Content Management System) that allows programmers to add enhancements to existing sections of the code without messing up the origanal code. Many scenarios in games work the same way - they have an extra directory for that purpose. The same is done with the application I work with in my job.

User Interface - This is probably the least focused, most underappreciated aspect of all of Software Design. Atleast, I never seem to hear it being talked about until after the software is made. Usually this is in the form of complaints about the controls being too cryptic, too many options, or whatever else the user can come up with. Most users just want to click an option - be it in a game or a business application, and have it do something. In a game, it might be firing a laser, or opening a door, whereas in a real-life application, it could be deleting an item from a database (there's nothing stopping you from putting your own grahpical and laser sound effect there!), or printing a report.

Now for areas where the two might differ:

Artificial Intelligence - I'm no expert in AI, but to sum it up this way... A commercial application's AI (provided it actually has one) tries to help you, whereas game's AI tries to hurt you. The goals are completely different. Granted, some game AI code might help you in some way, such as automation. In a way, automation is similar across the board in that it reduces redundant tasks.

Program Flow - From a game standpoint, the object is to collect items, kill the bad guys, and beat the game. Along the way, items and stats are gained, lost and changed. Likewise, a real-life application also adds, deleted and changes data, but the goal isn't always the same. This is probably the only similarity here. Unlike a game, the user doesn't want to be challenged everytime they have to add a new customer, or print out the bill to the client.

When you really dig down into it, any program, whether it's a real-life application, or a game, are very, very similar. The lines really blur when you get into things like military simulations. In fact, there's just a company that does both - BreakAway Games. They make both military simulations and computer games. Or, take a running/dancing game that uses some sort of foot pad. Remember the NES Power Pad? It's good exercise, too. Imagine if there was a similar game, but it also measured your heartrate. Would it be a game? Or a medical application (albeit a simple one)?

Presentation... Presentation... Presentation...

It's really all in how the program, and data is presented to the user. What it all boils down to is that they both read, write, edit and delete data to achieve a goal. Take the medical application example. A patient could run on a treadmill with a heart monitor. Now, they could stare at a screen showing them lines going up or down, or they could look at a screen showing a moving field. In one setting, this could be considered a game where you're racing against the clock - in fact, that could very well be what the person is doing if they're training for a race. So, how do we tell if this is a game or real-life application? Again, it's all in the presentation.


At 8:01 PM, Blogger Kevin (aka Padma) said...

Some nice points, Jen. ;-)

Actually, I think Games and other applications are even closer than you presented.

At 11:44 AM, Blogger WildWeazel said...

You mean Civ isn't a business application? :(

Good stuff there, please keep going!


Post a Comment

<< Home