Times, trials, and turbulence.
The Object Model (and Happy Code)
EDIT: Okay, these smilies are utterly destroying the margins/formatting. I’ll either have to go cold-turkey on smilies, or find a fix somewhere.
Okay, this is neat. Maybe not from the perspective of your average gamer, but I think that fellow developers respect a good chunk of decent code design. I know I do.
Prior to recently (read: all work preceeding (and including) Membrane Massacre), writing good code just wasn’t something that I bothered with. To me, finishing the game quickly was more important. Or rather, it used to be. As a result — I’m sure you all know — this resulted in tons of ugly hacks here and there, redundant code, and a handful of virtually untraceable bugs. I’m sure I’ve done a pretty good job of hiding this shameful facts in my games thus far, but this item keeps on coming back to haunt me whenever I attempt to take on a large project such as Skirmish: bad code drags me down. For small to medium games I can generally get away with it; even Membrane Massacre, a 5-month-long excursion, managed to reach completion with fairly hackish code. I don’t think I would be able to add much more to it at this point, but I’m starting to dislike the idea of “just barely surviving game completion”. What is one to do?
Writing a long-term online game is an extremely challenging process. In previous attempts I’ve never gotten to the “full-blown” stage with the public masses in running amok, but I can tell how challenging it must be from my experience making only to the very beginnings of beta testing: it’s rough. Luckily nearly all of the work at the beginning is self-centric, that is, as a developer AND producer, I only need to worry about my game, its design, and its code. That means there’s no hackers out ruining the game for players, or DoS attacks, or annoying emails about wanting to get unbanned, or any of the innumerable people-based chores that always crop up. With code and design being the forefront, it’s important that I don’t make any big mistakes. Or even small ones. A hack here and there for the duration of five months certainly adds up, and results in the whole game falling in on itself. I’ve had this happen on my two prior attempts at an online game, and statistically, I’m technically getting better. 😉 My last attempt at Skirmish (dubbed “Old Skirmish”) was a five-month-long whirlwind adventure that taught me heaps upon heaps about writing an online game. It taught me that planning things out from the beginning — or at least before you try and implement it — is an absolutely pinnacle step along the way. Like they say, “measure twice, cut once”.
So this time I’m taking the longer way around. I’ve been careful with the code that I’ve written so far, and have closely thought through my data structures and object-orientation before I leaped in to write code, and am quite pleased with how ‘cleanly’ things are progressing. It certainly takes much longer to get anything functional to show, but it pays off in stability and room for future expansion.
Sliding in to the beef of this entry, I’d like to talk a little about one particular item: the Skirmish Object Model. The general idea is that there is a base ‘Object’ class from which everything else that exists ‘physically’ within the game world (sans the literal map tiles) derives from. The benefit? Redundant code is severely reduced, rewrites and refactors aren’t needed (much?), the networking code becomes greatly simplified, and more flexibility overall with how objects in the world work. Everything in the game world branches off from the Object in a fairly simple manner:
- Stealth & Detectors
Now, you’d probably like to know what it is that you’re looking at. What is an Object, again? “An Object is any entity within the game that has a graphical representation and follows the rules/laws of the physical game world”. In a sense, pretty much everything is an Object. To touch on some of the object types:
A Prop is any object that serves no intended purpose other than decoration. This is pretty much all of the ‘map objects’, such as crates, chairs, desks, couches, potted plants, and so forth. Each prop has its own set of physical traits (weight, friction, etc) and health. The result of this is that (more or less) all props can be picked up by the player (to be simply moved, or thrown at someone/something), and all props can be destroyed. It certainly won’t be Half-Life 2 sort of physics, but this will go a long way in creating a dynamic environment.
A Bullet is the physical object created by a Firearm when the player uses it. Like all other Objects, Bullets follow the same set of physical rules as everything else. However, they tend to dish out considerable damage to anything they strike, be it a Player, a Prop, or anything else.
An Item is any Object that can be taken from the ground and placed into a Player’s inventory, or vice versa. Most of the classes deriving from the Item are self-explanatory, so I’ll leave them at that.
Due to the nature of these relationship, it would be (in theory) possible for a Player to pick up a live, activated thrown grenade from the ground and place it in his inventory. This would not be advisable, but it’s neat possibilities like this are made possible with the Object Model. In addition, fun games like ‘Chair Wars’ could be hosted by players just for kicks. Things like this are what have made games like Halo so much fun online even for people who don’t play seriously: you can screw around with the objects and physics with other people. 🙂 I’m exciting about utilizing this particular ‘extra’.
I didn’t cover a lot of the innards of the Object Model that I have planned, but hopefully this whets your appetite. I’m really excited to start throwing potted plants at testers. I hope you’re all equally excited to catch them with your heads. 🙂