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.

Tuesday, February 14, 2006

Pitchers and Catchers...

Time for a little break in the action, and talk about one of my hobbies - watching baseball! At 12:00pm EST tomorrow, Spring Training camps open throughout Arizona and Florida. It's funny - it usually always snows here in Baltimore right around when Spring Training Camp opens. Personally, this is what I look forward to all winter when there's nothing but (American) Football, Hockey, and Basketball. I'm also going to be watching the World Baseball Classic, too. It should be a fun March coming up. March Madness for baseball, perhaps?

Wednesday, February 01, 2006

Making a Computer Game (Part I) - Introduction :: Or - What I wished I knew about 20 years ago.

Introduction

I've always wanted to jot down how to make a game, and of course, create one. In fact, I first wanted to make a game in ernest way back when I was about 12 years old when I first wanted to make a game. What inspired me? The game "Dragon Warrior IV" by Enix. I started off by making a chart of monsters, weapons, and items that would be in the game, and even a fully hardcoded experience point system for about 12 characters. (Thankfully, it was summertime, in case you're wondering) Granted, I was stuck with an IBM 286 PC with GWBASIC, an interpreter -- hardly worthy enough to create a game. My first true attempts were several years earlier on the TRS-80 between the ages of 6-8. (I was 5 when I got a TRS-80.) Now there's something! My generation is going to be saying, "When I was your age, I made my own games on the computer!". Anyway, the origanal WordStar, then WordPerfect document is long since gone. It wasn't really until highschool that I got a Turbo Pascal compilier when they offered the course at school. It was then when I first made a RPG, or rather, an add on to an online RPG for a B.B.S. software (yep, back in the DOS days). Now that I look at it, that code was terribly hard-coded. I've tried programming graphics code (using code in assembler that I found as the base of it), but graphics (coding and drawing) were never my strong points. Back in the day, I thought programming a game meant phsyically hard-coding every possible action the user will make, and every single pixel (via code!) on the screen. This was before the Internet was widely available (late 80s to mid 90s), so I had to learn by trial and error, not to mention constantly progressing from one compilier to the next (Pascal, Turbo Pascal, C, Borland C++, Visual C++/Basic...). I did have my greatest successes in Turbo Pascal. Unfortunately, its' code isn't very Pentium-friendly these days. I think my biggest problem when was that I wanted to do too much at once, and was always befuddled by the graphics. At other times, I would theorize code too much, and just not get anything done. College did help quite a bit, especially Systems Analysis and Design classes. Right now, I'm a Programmer/Analyst working for the State of Maryland using Visual Studio .NET (C#, Visual Basic), and old VBA code. Yes, I can hear some of the masses groaning at the sound of VBA.

About RPGs

For years, the one genre of games that I really liked were RPGs, more specifically, crpgs (Console RPGs - or rather, Japanese style RPGs). So, what's the difference? Well, there's 3 major types of RPGs:

1 - American-style RPG. These are of D&D fame, with quests, character classes (human, elf, orc, etc.), and a skill system (strength, willpower, agility and so on). These were mostly "find treasure, fight a bad guy, and perform another quest". My knowledge of this class of genre is actually a bit limited, as I haven't played too many of these kinds of games.

2 - Console RPG. Conversly, the Japanese style RPGs, especially of NES and SNES fame, focused on character development in terms of a storyline revolving around the characters the player controls. This still has features of a classic RPG in that there's monster battles, exploring caves, and a skills system. The major difference is that, except for some modern CRPGs, the skill system was automatic. I really enjoyed these games because of the storyline, side quests (for example, Final Fantasy 6 when several groups of characters can be controlled. At times, it added a little strategy into the mix.), and the puzzles that the game would give while exploring the map. The major downside is that, atleast in the early days, these games tended to be very linear. The player's party would be forced to say, fight an enemy in a cave before being allowed to explore elsewhere. (Note - The "Fight the enemy in a cave" routine has been used a lot as a "first quest" in RPGs. Some games, like Dragon Quest 8, make some humor out of this beaten quest.)

3 - MMORPGs. These are inherently American-style RPGs. There are classes, and many quests that can be performed. Players can go at it alone, or team up with other players to achieve a goal. Personally, I find these take up too much time, not to mention the monthly fee that keeps piling up even if you don't play.

So, in my next series of journal entries, I'm going to go over how to start a game from scratch. I'm going to do something that I wished I had done way back - start small... and ignore all of the pretty graphics!