Gauntlets of Recursion (+3)

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:

  • Object
    • Prop
    • Bullet
    • Player
    • Item
      • Firearm
      • Tool
        • Grenade
        • Mine
        • Melee
        • Medical
      • Utility
        • Armour
        • Stealth & Detectors
        • (Other)

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. πŸ™‚

10 responses to “The Object Model (and Happy Code)

  1. David a.k.a "Trapper Zoid" July 17, 2007 at 8:12 pm

    I know the feeling of being embarrassed about poor code; it’s a key reason why I’m hesitant to release the source of Pierre and the Fish. I don’t want any beginners to start emulating anything in that mish-mash in the mistaken belief it’s an example of good code.

    The main danger I’ve found in code planning is there’s a tendency to over-plan everything you do. I can get very critical of code and dream up all sorts of extensions and failure conditions, which can drag the design stage on for far too long.

    For my current game I’m going to attempt a mix of the two approaches; allowing myself to make throwaway prototype code with the expectation that I’ll rework it into something more elegant later.

  2. MrValdez July 17, 2007 at 8:49 pm

    Instead of using the object model, may I suggest the component model?

  3. Dan July 18, 2007 at 5:12 am

    Well, you must be doing something right, as most amateur game programmers (such as myself!) are working on some project or other but only a tiny, tiny splinter manage to actually finish something πŸ˜€ So well done on that front!

  4. Stephen July 18, 2007 at 7:52 am

    @David: I never said I was embarrassed by my code — just that I’m not overly fond of its hackish nature. There might have been a point in time when if someone wanted to see the source for one of my games I would sort of look down at the ground and shuffle my feet, saying, “Uh, maybe I’ll send it later when I clean things up a bit” and of course never send it. However, I’m comfortable with my code now, even the ugly stuff. I worked like a horse on it, so I should show some pride in it. πŸ™‚

    I’m in agreement with your note on overplanning. Design is good, but too much design is bad; you’ll end up being paralyzed by the enormity of the design structure you’ve created. The above model has already been scaled down from the original over-the-top model, and I think will serve quite well for my purposes without being too difficult to implement. Fingers crossed!

    @MrValdez: Thanks for the comment! I read through the article and was found the idea of a Component Model very intruiging. I really like the idea, but I can tell that implementation is a real drag, at least initially. Given the simplicity of my class heirarchy I don’t think that it warrants a change as big as this, although I did opt for a ‘component blob’ approach in Membrane Massacre, my last project, and it worked pretty well. Now that I have a name to the method though, I’ll be sure to consider such a model for future projects. And that’s quite the shiny Sword of Coding (+7) you have over there on your journal — perhaps mighter than my Gauntlets! πŸ™‚

    @Dan: Thanks for the comment, and the words of praise. Finishing games is very tough business, but the more you do it the better you tend to get at it. You run an interesting journal of your own too, and I recall reading through your articles on the a while back — keep ’em coming!

  5. Selkrank July 19, 2007 at 7:12 am

    In short: sounds good! Now make that reality. πŸ˜‰

  6. The Visible Man July 19, 2007 at 2:12 pm

    “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.”

    I’ve never worked with WordPress, so I don’t know how much they let you alter your CSS, but if you can, adding this line at the end will fix it:

    .wp-smiley {border: 0px !important;padding: 0px !important;}

    You’re idea sounds like it will work out great! Both programming and gameplay wise! No potted plant will be safe! It will also make creating maps more interesting, allowing materials for barricade building and makeshift weapons at key places πŸ™‚

  7. Stephen July 19, 2007 at 5:07 pm

    @Selkrank: Thanks for the comment! I’ll see what I can do. πŸ™‚

    @TVM: I have access to the stylesheet for this theme, but the line you gave me doesn’t seem to affect anything. I don’t see any smilie definitions in there, so I’m likely looking at the wrong place.

    I’m really excited to see what kinds of maps you’ll come up with. I really enjoyed ‘Arctic Outpost’, and am curious what kinds of fiendish bases you’d be able to whip up for, say, a CTF map. πŸ™‚

  8. The Visible Man July 19, 2007 at 7:00 pm

    Hmmm, that’s odd. All my tests showed it working fine.
    What file are you adding it to? It should be “”

    What it should do is remove the border and extra spacing around the smilies in your posts, allowing it flow without breaking it apart.

    Can you add it and then leave it for a bit? Then I can look at the style sheet again and see why it’s not working.

    I’m looking forward to making some new maps! I can’t wait to see what I can come up with and how they play!

  9. The Visible Man July 19, 2007 at 8:33 pm

    Ok, sorry about posting so much, but I can’t edit my comments.

    Try this instead:
    .entrybody .wp-smiley {border: 0px; padding: 0px;}

    I don’t know if WordPress doesn’t allow the !important tag or what, but it was being removed. Normally I wouldn’t use it anyway, but the way they defined the borders their definitions were overwriting my attempt to overwrite them. The above works without it.

  10. Stephen July 21, 2007 at 4:47 am

    Thanks TVM, that did the trick! No more image padding to drag me down; clear skies ahead! πŸ™‚

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: