GameDevBlog

My Old Games Live

You think of videogames as being on the shelves for a few weeks and then disappearing forever, but it's actually not too hard to find and play my best games.

The latest Xbox 360 update made it possible to play Spider-Man 2 on the 360.  Don't bother with the missions, just swing around. 

You can play Die By The Sword on GameTap - although they disabled the limb-severing - which, hey, was half the fun.  But it's still got the unique, never-imitated swordfighting and there's a lot of cool stuff (much of which came from Mark Nau) in the levels.

And you can violate the copyright on Magic Candle 2 at Home of the Underdogs.  Steal this record.

This pleases me.

Stupid C# Tricks - readonly reflection - Continued

Whew!  Lot of answers!  The most promising ones seem to be the ones relating to binding - binding is stuff I just plain don't understand.  The possibility that it's making some kind of copy of the type seems like it might be on the money.

Just to clarify: 

I'm not using const - I'm using readonly.  According to Richter, const gets compiled into your code, as you'd expect.  But readonly is a regular ol' variable that is protected by the compiler and runtime. 

It's not a property; it really is a field.

The field is static, so SetField should not take the owner (there isn't one anyway), it should take null.  This is from MSDN.

I can't use different build-time dependent values because in the unit tests I test it with different caps in the same run. 

Stupid C# Tricks

We're cracking down on static variables in Schizoid so we can feel more comfortable that there aren't lurking thead safety issues in there.  Some of these statics are effectively constants, but we made them non-constant to ease unit testing.  For example, we might set a unit cap at 1 in a test, create two units, and make sure the cap is being respected.

Unfortunately, now there's no way to make sure that an Evil Programmer doesn't violate the effective const-ness of this variable...and possibly endanger our thread safety.

(In case you're about to say "Why not make it private and add Get/Set accessors", shame on you for parrotting rote "good style" guidelines that don't actually do anything to protect you.  One could then use the Set and violate our thread safety that way.)  In a better world, C# would have friends.  We could make the test fixture a friend of the class with the static variable and walk away happy. 

You can have friend DLL's - I could just see myself breaking my project down into dozens of small DLL's just to get the kind of granularity of friendliness that I want.  A lot of DLL's seems to hurt our build time, however.

I came across a possible answer in *CLR via C#* today - "Note that reflection can be used to modify a readonly field," Richter says.

That's good enough, I thought.  I'll make my consts readonly, use reflection to modify them in the test program, and assume that no programmer will be So Evil that they do the same thing in the core code.  Too much work!  The forces of Evil, after all, are lazy.

Unfortunately, it didn't work.  Maybe a C# guru in the audience can tell me why.

Here's the code. Enemy is the class which has the static readonly field maxEnemies.

            Type enemyType = typeof(Enemy); 
            FieldInfo maxEnemiesField = enemyType.GetField("maxEnemies");
            maxEnemiesField.SetValue(null, newMax);
            Assert.AreEqual(newMax, Enemy.maxEnemies);

When I step through this code in the debugger, Enemy.maxEnemies appears to correctly change to newMax after executing line 3.  But then the assertion on line 4 fires, telling me that it's still 100.

WTF?  The debugger sees one thing, the code another?

No doubt this is a subtle intracacy of the CLR that somebody out there understands?  Googling turned up a lot of noise for me, unfortunately.

BTW - this is all just academic.  We don't have any Evil Programmers, really.  We don't normally waste a lot of time to protect ourselves from bugs that nobody on the team is actually going to write.  But now I'm curious, damn it.

Notes on Puzzle Quest

I'm totally addicted to Puzzle Quest.  I have a lot of trouble resisting the urge to pick up the DS and play another session.  I ask myself why that is.  "I could be playing God of War II right now," I say to myself.  "It's really just Bejewelled.  Why am I playing Bejewelled?" I ask myself.  "The production values aren't even as high as Bejewelled," I say.  "They traded scope for quality."  And yet I keep playing.

I don't like Bejewelled.  It doesn't engage me anywhere near the level of say, a Tetris or Minesweeper.  The beauty of Puzzle Quest is it adds a layer on top of Bejewelled that makes it interesting, illustrating Sid Meier's whole thing of small mechanics layered on top of small mechanics.  Because those jewels you collect become mana which then power spells that give you special abilities and/or do direct damage to your opponent, and because your opponent is taking turns on the same Match 3 board that you are, it suddenly becomes interesting.  Then, add to that the macro game, where you're deciding what spells and items to bring into a session, and the leveling up and economy of an RPG...it works!

Add to that the short session length - it's actually deceptive - a single session can take fifteen minutes or more if you're being careful - but I trick myself into thinking I can do another combat in just five minutes.  And then another.  And another.

Manager In A Strange Land: Parkinsonian Scheduling

Wow - lot of comments on the last post, maybe partly because of its Socratic nature?  Think I'll try to keep that going.

Almost two decades ago, I temped at a mevatron factory.  One day, one of the managers and I were having beers on our lunch break, and he said, "I just tell 'em I need it in a week when I really need it in two!  They never have it done in a week, but it's always done when I need it!"   He was really pleased with himself.

Years later, a producer friend of mine wrote a short paper on how to manage videogame development - he said basically the same thing.  Since games are always late, tell your team it needs to be done before it really needs to be done.

I can't find the article right now, so I won't name names, but I read a quote from the CEO of a not-terribly-succesful-lately-publicly-traded game company, which said the same thing.  Tell the team to get it done before you need it.  They'll slip but they'll get it done on time.  "Sounds crazy but it works," he said, or something like that.

(I later met a programmer from that same company - he crunched his ass off to meet a tight deadline and then, he claimed, the product sat in the warehouse until they were ready to release it.  Sounded like he was just a little bitter; he quit working for them.)

There's a name for this management technique:  Parkinsonian Scheduling.  After Northcote Parkinson, author of *Parkinson's Law.*  *Parkinson's Law*, by the way, is a pretty good read, and there's some very quotable stuff in there.  Most people incorrectly think that Parkinson's Law is "work expands to fill the space allotted for it".  That's not actually true - that's a postulate that Parkinson accepts as a given, which he then uses to go on to prove his actual Law - which is that hierarchy in an organization will indefinitely expand.

So calling it Parkinsonian Scheduling may be something of a misnomer.  But there it is.

I have to admit, Parkinsonian Scheduling does seem to work.  Just yesterday the clock in our hotel room was wrong, and instead of being half an hour late to a mother's day brunch we were half an hour early.  When under the gun like that, you really find out what your priorities are, you work overtime if you have to, and then if you slip anyway, you feel relieved when you find out there was that extra hidden buffer in the schedule.  The only time you lose is when people, like my acquaintance whose game sat in the warehouse, actually hit your unreasonable date and then feel betrayed.  And by then they've already served their purpose.  (In this unpredictable game development world, you never know if there's even going to be a second project, so I'm usually an advocate of always taking the short-term-gain for the long-term-loss.)  Even acclaimed management books like *Critical Chain* endorse it.

On the other hand, IT'S JUST PLAIN LYING.

So now we come to the Socratic portion.  What do you think?

A)  The means justify the ends.  Parkinsonian Scheduling works.  And people lie.  I'm telling my crew the game's due tomorrow.

B)  Parkinsonian Scheduling is short-sighted.  I want to retain my talent.   And I wouldn't want to work for that kind of manager.  And with software development, if you push people to hit a date they skimp on quality - they may hit your date but it will be a really buggy product.

C)  I don't care if it works or not, lying is wrong.

D)  Other?

Slings And Arrows

Got into an argument yesterday with a friend who thought Grand Theft Auto should be banned.  Unfortunately, his argument had some compelling points that I don't really have a good answer for.  And he's something of a gamer himself;  he played a fair amount of GTA before actually passing judgment. 

The argument goes something like this: 

Anti-gamer:  "Suppose we had a perfectly realistic murder simulator, that people enjoyed using.  Nobody actually gets killed, but the simulation is perfect - holodeck-like.  Would it be okay to ban that?"

Gamer:  "No - just because you enjoy killing someone in simulation doesn't mean you enjoy killing them in real life!"

Anti-gamer:  "So you're saying as long as nobody gets hurt it's okay."

Gamer:  "Yep."

Anti-gamer:  "Did you know there was a case in the UK recently where people were making fake child porn?  No actual underage models are used;  nobody's getting hurt.  Is that okay?"

Gamer:  "...  I guess not ..."

Anti-gamer:  "That's what the UK decided.  So why is it not okay to have fake child porn but okay to have fake murder?"

Gamer:  "Because the people who read fake child porn are creeps?"

Anti-gamer:  "Why?  They would never actually have sex with a child in real life.  They only do it in simulation."

So now I feel trapped.  Where do I go from here?

Maybe I can say, "Okay, enjoying simulated murder is wrong.  Grand Theft Auto is okay because the simulation is so poor nobody would confuse it for the real thing.  And besides, Grand Theft Auto is a really brilliant game; it's not just about gratuitous violence."  But that opens us up to the slippery slope - I'm drawing the line on one side of GTA but now you have to ask - "What about God of War?  What about Manhunt?  What about the future when the violence is going to be even more realistic?"  And if we're drawing lines, nothing stops my friend from drawing the line on the other side of GTA.

Or maybe I can say, "All right, people can have their fake child porn.  I don't want to hang out with those people, I hope I never meet those people, but I'm not going to take away their right to enjoy something revolting that doesn't actually hurt anybody."  But...that's just icky.

Or maybe I can say, "Sex is just different from violence.  If you enjoy fake child porn, you clearly want the real thing.  But you can enjoy fake murder all you want with no interest in the real stuff."  Which seems like a typical American "sex is worse than violence" attitude - am I saying a simulation of murdering children would be less offensive than a simulation of having sex with them?

I need an answer but I don't really have one.