SpawnCamp

My musings, which will invariably revolve around games and their connections to everything, everywhere, in all ways, at all times. No matter how improbable the connection, no matter how tenuous the stretch, no matter how tedious the pontificating - I'll be there, with the word "GAME!" frothing from my lips. Consider yourself warned.

Wednesday, November 29, 2006

New Game Ratings

Currently, if I look at video games on a shelf at the store, they have a rating. Everyone, Teen, Mature, Adults only. This rating indicates strong language, violence, and sex.

Which is fine as far as it goes, and I can see parents being interested in this.

I'm ready for another game rating, though, one relevant to me. I want to be able to tell, at a moment's glance, if a particular game has any in game advertisements or product placements.

Ugh.

Thursday, November 02, 2006

Selective Spelling

I seem to be straying from game design to programmer talk these days. Fortunately, as I have nearly no audience, I can do this with little pain+suffer.

So, my thought for today. I would really like a programming development environment in which lists of common abbreviations could be kept around for spelling autocorrection purposes. There are few things more irritating than trying to remember who's code you're in so that you can alternate between dst, dest, and destination as needed. Surely this is something that my trusty servant, the computer, could be doing for me.

Irk.

Thursday, October 26, 2006

Mismatch Making

Some facts:

* Game making is still largely done in C++
* Most other types of development (particularly lucrative business development) have long abandoned C++ for more recent languages, especially Java
* Tools are built where money is spilt... or something.

I've been struck, in my recent work on C#, by how pleasant it is to work with tools that are on the receiving end of a great deal of active development. A lot of why I'm finding it so pleasant to work with the language (and, for that matter, a lot of why I'm not reacting that way to Flash development), is entirely because of the tools, not the language proper.

This is problematic for game development.

Saturday, October 21, 2006

Override

I've been learning both Flash and c# recently (instead of, say, writing blogs, or responding to e-mails).

Flash, I have somewhat mixed feelings about. I love being able to make a file, put it on the intertrons, and know that 1) it will be tiny and 2) people can download it and run it safely. On the other hand, wow is it slow, and wow do I not enjoy Actionscript, and wow is it feature poor compared to most things I've worked with as a gamedeveloper. It's nice to know, of course, that these things will only improve. Cleary there are a number of roadmaps existing for Adobe to follow to bring Flash down the path that game engines have already gone (though probably always favoring increased compactness and smaller knowledge requirements than commercial game making tends to require). At any rate, it's been fun to learn, but I'm hitting my head on the ceilings of what it can do pretty quickly.

C#, on the other hand, is just pure pleasure for me. I really like it. It probably doesn't hurt that I can write it in an IDE I'm completely familiar with, while at the same time freeing me from 1001 things about C++ that I'm simply fed up with. It's also nice to have good, standard libraries for a host of technologies that I don't want to write. I know DirectX okay, but it's been interesting exploring the managed extensions to it.

So on I trudge...

Thursday, September 14, 2006

LOAD "LONGPLAY VIDEO",8,1

http://www.abyss-online.de/c64longplays/

I've been a fan of tool assisted speed runs (which are videos of games being played through as quickly as possible) for quite a while now. Particularly for someone interested in thinking about and talking about the ways that games work, it's much easier to watch a good video of a game being played than playing it yourself, for a variety of reasons, particularly if you've already played the game previously.

Unfortunately, the games that get played and filmed tend to come very specifically from a handful of sources - Nintendo, Super Nintendo, Genesis, and occasionally Nintendo 64, Playstation 2, and more recent devices. This leaves out vast swathes of interesting gaming that can be very difficult to get a hold of to play, such as older PC games, Amiga games, and older home pc games (for systems such as the C64, Apple 2, Sinclair Spectrum, Atari ST, and so on).

Finding the above link gives me hope. It's great to see old games I haven't played since I was 9, it's great to see them played so well, and it's great to have access to interesting titles that would be lost in obscurity otherwise.

Tuesday, August 15, 2006

Walking on Water for the Masses

"You should read my blog," he said, slyly. "It'll be all about neat-o keen game stuff, and you'll like it for sure! It's super good!"

And for a time, lo, it was so, or mostly so. But then, slowly, over time, the game posts spasmed and dried to a trickle, and then slowly, those posts were replaced by the intermittent hum of quick apologies and posts that were promises to post later. Oh, posts about future posts! Like most such meta situations, it was mildly amusing to summarize from the outside looking in, but only tedious in practice.

Oh yes.


***

Today I must talk about expectations.

Making good games is all about wrestling with player expectations. I guess that's true about all media, really.

One tragedy about working with large publishers and producers, especially ones who don't know anything at all about games because they've made their names selling crackers prior to wandering over to the game industry (of course), is that expectations function so differently in media than they do in fields making more generic products.

When I buy crackers, I'm not looking for surprises. I'm looking for tastiness, crispness, and a nice edible shelf for Cheez Whiz. Give me this, and you have a cracker success story. I expect this in subsequent boxes of crackers, too. No surprises.

And this holds for all sorts of other things, of course. Computers should do what I buy them for. Same with cars. Cell phones, beds, nail clippers, harvested organs... I know what I want when I'm getting these things. I want my expectations to be met completely.

This is true for some games, too. When I buy a chess game, I will be, well, vexed, if I discover there are three knights on the board and a new piece entitled "The Groupie" which can be attached to any other piece in play and always occupies the last square the piece in question has vacated. Maybe these are fun rule changes - but chess they ain't. I expect the same things with Go and Monopoly and Football and Poker.

I think that for products that fall into these categories, focus groups, at least to an extent, can make good sense. It's hard to know what people want to buy, so just ask them, right? They're the ones out in the field, eating those crackers day in and day out, fiddling with those cell phones in darkened movie theaters, driving those pimped out rides while talking on those cell phones, requires those harvested organs after the natural consequences of the mighty cell phone / car combination, so they're the ones who know what they want. Surely.

For many kinds of games, though, I don't think this is the route to creating things that make an impression on players. Meeting peoples' expectations is a good way to please them. It's not way to make them sit up and take notice.

Rather, setting up player expectations to comfortable, pleasant levels, and then exceeding those expectations - that! That is the recipe for adoration.

Or so I claim.

An example.

Castlevania 3, on the Nintendo, was a very solid, well designed platform game. And, like most such platform games, there were a lot of graphics and fiddly bits in the backgrounds that looked cool but really had no impact on the gameplay. They were just there to keep you visually interested as you marched through the obstacle course. One of these background objects was a waterfall, the onrushing water of which slowed you down as you marched forward. Another aspect of the game was that there were a handful of characters you could find and join as you traveled through the game. One of these was a wizard, who had a handful of spells at her disposal. Further, one of these spells shot out five short ranged balls that could freeze enemies solid.

At one point, while playing the level with the waterfall, I used this freezing spell to attack an enemy, and, completely without warning or any sort of preface, the entire waterfall and river froze for several seconds, allowing my character to walk on top of the water and thus move through the level more quickly.

This elevated Castlevania 3 for me tremendously.

It's not just the freezing of the water that did it for me. I've certainly played other games that have let players do similar things. It was the unexpectedness of it, and the wonderful extraneousness of it, and the sheer secretness of it. The game implied that it was going to be a good platform game, and then it transcended those expectations.

If you had asked me, prior to playing, what I wanted in Castlevania 3, I would have said, "Castlevania 1, but with more levels, and more monsters, and more bosses, and more music, and more graphics, and more settings". Yep! Of _course_ that's what I would have wanted. Those are very obvious things to want. And if fact Castlevania 3 did deliver those things. But it also delivered things I didn't know that I wanted, things that weren't simply "more" but were fundamentally different in kind. And that is how the game left a mark.

Expectations are difficult to wrestle with. They've very sensitive to audiences, and where audiences are coming from. But I rarely get the sense, when I play new, non-DS games, that designers are trying to understand my expectations and then explode them. And for me, as a gamer, that's a shame.

Wednesday, July 19, 2006

Words Make Muddle

Warning! This is programming related.

First, some links as preface:

www.del.icio.us
www.flickr.com

and then, for some idea,

http://www.rashmisinha.com/archives/05_09/tagging-cognitive.html
http://www.shirky.com/writings/ontology_overrated.html
http://www.c2.com/cgi/wiki?LifeIsaBigMessyGraph

I assume there is significantly more discussion about tagging and such issues elsewhere.

The general thrust of these articles, at least in a sense, is that giant sprawling hierarchies are, for the most part, bad matches for ideas and information in real-life. Most important things don't fit comfortably into hierarchies or cleanly defined, precise nomenclature.

My general question right now is, how do the ideas found in tagging overlap with the issues we face in programming? Programming is, above all else, exactingly precise, often painfully so. Much of the pain in reading new code and attempting to extend it is understanding what precise words other programmers have redefined for their particular model. Searching, too, plays a profound role in navigating code, but once again, we're often stuck in the Guess the Synonym / Guess the Abbreviation / Guess the Word Order world that can make programming feel like playing Space Quest with its constant "appease the parser" mini-game.

In a certain sense, concepts like namespaces start pushing in the direction of eliminating specific names and adding more context sensitivity to terms, but it's still monolithic and hierarchical.

For instance, in C, you can do any one of the following things:

sin( float x )
sine( float x )
math_sine( float x)
circlefunctions_sine( float x )
trigfunctions_sine( float x )
lookuptables_sine ( float x)
curproject_math_sine_lookuptables( float x )

and so on. Technically, you could embed all possible permutations of disambiguating information into macro defines so that a new user could use any of these labels to call the sine function - but in practice, the resulting combinatorial explosion is likely to make this a non-starter.

In C++, there's a bit more flexbility. Declare curproject::math::sin( float x ), and

sin( float x )
and math::sin( float x )
and curproject::math::sin( float x )

are all viable ways to reference the function.

BUT

This still requires inventing a hierarchy, and it still requires users to learn your arbitrary hierarchy as they use the code base. Is the sine function better served by being in the circle namespace, or the math namespace, or the lookup table namespace? Which should be top level? All of these, ultimately, seem like highly arbitrary choices, and they seem to add to the cognitive burden of a code base without, ultimately, adding much of benefit. At least, that's how it seems to me.

Could this be solved by something like tagging?

Could "float Sine [math, trig, circle, lookup, radians]( float x )" be a viable way of naming and describing a function in a programming language? Certainly for finding new functions, there are times when I'm interested in all math functions, there are times when I'm interested only in trig functions using lookup tables, there are times when I'm interested in all possible circle related functions, and so on.

Another interesting idea about an approach such as this is that it could provide an opportunity for users of a function, rather than just the writers, to provide annotations that make sense to them as well. If the information I need about the sine function is that it is a hardware intrinsic, then I could add that keyword after the fact. Intrinsics::sine could very well be how I'd like to disambiguate the function in my code.

The obvious down side to an approach like this is that increased context sensitivity makes new code harder to read. It might be very difficult to tell that Circle::sine and LookupTables::Trig::sine are the same function. I doubt that in practice this is likely to be any worse that what existing namespaces, especially class based ones, do for reading function or variable names - and more generally, the problems of reading context sensitive code seem like issues that tools should be solving, rather than code itself.

It might make problems in practice, but I still find myself highly drawn to, and highly curious about, this approach.