GameDevBlog

Notes On Sports

Robert Yang's article in The Escapist on using outdoors games to teach game design is pretty cool.

It reminded me of something I've thought for a while but never shared:  as game simulations become more realistic, designing videogames becomes more like designing sports than designing, say, board or card games.  FPS's have more in common with Capture The Flag than with chess.

Which, for me, is a problem, because I don't like sports.  This is surely partly because I suck at them - always one of the small kids I could never hold my own in any competitive team sport.  (But hey, I'm not a total geek, I used to be an ok surfer.)

But the fact that multiplayer FPS's only engage me for a day or two before I go on to play something else - I wonder if there's something more fundamental there, some fundamental trait of sports and FPS's which drives me away.  I can hold my own in FPS's.  (Sometimes.)  In that arena size doesn't matter.

And I wonder if that fundamental trait is:  slop.  This isn't supposed to be a "sports are bad" post, I'm just rambling about my personal tastes, so maybe the word 'slop' sounds too pejorative.  My point being in these highly complex systems like NFL football and counter-strike it's really hard to get a handle on what's going on, they're unpredictable, anything can happen (there, that's not so pejorative) whereas in board and card games the systems are usually so simple that you can predict the future, sometimes determine the exact right play, know you've got "the nuts".  Board and card games are inherently more...tractable...than sports.  

Not a good or a bad thing.  Just a thing.  Some people prefer it one way, some the other.

But I would say - if you're designing an FPS, sports-design may be more important than boardgame-design.  Whereas if you're designing a turn-based strategy game or RPG, vice-versa.

It occurs to me now that Schizoid is more of a sport than a game, too, by this criteria.  Maybe.  It's a grey area.  The behavior of the enemies is completely predictable, making it fairly tractable.  Still, you could play live-action Schizoid tag:  you have your red-shirts and blue-shirts (or shirts and skins probably easier to come by) and one of each is "it".  Maybe the ones who are "it" wear crowns or something.  When red "it" tags a blue guy they're out.  When blue "it" tags a red guy they're out.  If a blue guy tags blue "it" or red tags red "it" then they get to be "it".  I wonder how it would play out...I'll have to try it some day.

Adventures In XML

I feel like I'm the last developer in the world who is dipping his toes into XML.  So what I have to say about it is probably useless to the rest of you, but here are my latest experiences anyway.

So how's this for not falling prey to speculative generality or premature abstraction:  I don't like to make tools until a clear need is demonstrated, when you can tell that a content creator is going to be a bottleneck and they need workflow improvements.  On Schizoid and through much of our current project code was always the bottleneck. (Actually, just recently it may have become art.  Time to make some art tools.)

To that end, on Schizoid and through much of this project we've had content creators do their creation directly in the code base, editing .h files (well, with Schizoid, C# files) and data structure declarations, piles of curly braces and all.

That all changed recently because Richard's machine had trouble installing Visual Studio, so I thought it was time to do the right thing and put our data in text files.  Not to mention, we're eventually going to have to, for Downloadable Content purposes. It's been many years since I've written code to read data from a text file.  My MO has always been to use fscanf.  

So, time to catch up with the new millennium.  Do I really want XML, for starters.  There was a whole XML - JSON thing going around a while back - my friend Bryan McNett was a big JSON advocate, and he did really cool stuff in the Spidey 3 codebase where you could tag data structures in your h files and a text processor would create the JSON importing code for you.  He's written articles about it but I can't seem to find them.

In the end, I decided to try XML rather than JSON, because there seemed to be more support (XML handily won the Googlefight), but the deciding factor was being able to easily load XML files into Excel.  Having all of our unit data in one big table that's nicely formatted (the alternating dark blue and light blue rows soothe my soul) won me over.  And McNett's .h file markups may have been cool, but we don't have enough different data structures to make the effort of adding another step to our build process worth it.  (Not to mention there's no reason you couldn't theoretically do the same thing with xml.)

The next question becomes - which XML library do I use with C++?  With C# it's built in, yo.  Again I mostly relied on Google - when in doubt, do what's popular.  The second hit was TinyXML, which seemed great.  Free license and small.  Hooking it up and getting started was fairly painless.  I usually felt like it took 2-3 lines of code to do what should take 1,  but some small wrappers and I was ok.

It took me about a day and a half to learn pidgin xml, hook up the library, and get our data converted.  I tried creating a schema to assist in the XML importing to Excel and threw up my hands - it seems to do a fine job on its own, anyway.  We are schemaless.  A schema, I know, would help with data validation.  We do some in code, but not enough, yet.

That's one of the big things I miss about the old way - typing our data straight into the code - is that the compiler validates our data for us, and does a great job.  

One thing I didn't like about the old way was simply formatting the file - you end up with a lot of comma separation and it's easy to lose track of:  is this float here his hitpoints or his armor?  Etc.  The new files are much easier to read and maintain.

What about XML vs. rolling our own format?  This also feels like a win.  Not a huge win--here I am writing a lot of XML glue code instead of a parser--but a material one.

And so, I've finally caught up with the new millenium.