No Covariance in Projections? No Problem!

I figured out a way around the fact that until XNA 4.0 gets updated for Xbox development, you can't use a Projection<Y> where it calls for a Projection<X> even if Y inherits from or implements X.

Just for completeness' sake, an example projection would be having a generic class that takes a type parameter.  Specifically, I was working on a CollisionEffect<T> class, where T is any class that implements an interface named ICollideable, indicating that the class' objects can take part in collisions.  In this case, CollisionEffect<T> is a projection from T -> CollisionEffect<T>.  A CollisionEffect<Player> is an effect that can be applied to a Player during a collision.  Since I wanted objects to be able to hold effects intended for different kinds of collideable objects, I figured that having ICollideable also provide an IEnumerable<CollisionEffect<ICollideable>> would do the trick.

Well, because C# 3 doesn't allow covariance in projections, I couldn't store a CollisionEffect<Player> as a CollisionEffect<ICollideable>.

The solution?  An ICollisionEffect interface that provided non-generic versions of the information in a CollisionEffect, i.e. versions using the base Object class.  By having CollisionEffect explicitly implement ICollisionEffect, a Player can have a List where the elements can be any allowable CollisionEffect<T>.  During a collision, a collideable object will call the other ICollideable's GetEffects<T> method, which retrieves from the List<ICollisioneffect> any CollisionEffect<T> objects where the type parameter matches.

Once I can actually have projection covariance in C# for Xbox programming then I'll get rid of ICollisionEffect since it would become completely extraneous, but for now it's a useful trick that lets me have almost exactly what I wanted.

Scala Candy

There are a lot of good things about XNA Game Studio and C#.  But damn do I miss Scala traits right now.  In fact, I'm missing quite a few of the functional constructs I don't have in C# 3.  I wish Microsoft would stop dicking around with phones and get Xbox support for XNA 4.0 already.

Collection Nuances

Yesterday I added a screen component class to our XNA libraries that's analogous to XNA's own game component class.  The difference is obvious: screen components only exist and should be updated, drawn etc. when the screen is active instead of the game loop.

Arguably you could just use the Enabled and Visible properties in DrawableGameComponent.  However, I think the clear separation makes the code easier to understand and it automates the calling of critical methods like Draw and Update within a single screen's loop.

The issue that arises is concerned with screen components that are dynamically added during the game runtime.  Due to the fact that some screen components are created by other screen components during updates, when to actually add those newly-created objects to a screen's collection of components is slightly tricky.  It comes down, I think, to a single consideration - do you want newly-created screen components to be updated during the same update loop in which they are created?  My initial answer was no, partly because I was using iterators to traverse the component collection and the iterators would naturally get invalidated if I tried to modify the collection during the traversal.  So instead I hid the raw collection and made AddComponent and RemoveComponent that would modify temporary lists.  At the start of the next Screen.Update call, before the components themselves were updated, the lists of objects to add and remove would be combined with the main collection, and iterator-based traversal could continue as normal.

I wonder though if it would be better to traverse the collection using raw indexing and let new components be updated immediately.  It would simplify the code, certainly, though the additional complexity currently in place is pretty minimal.

Rehashing Final Fantasy

Ok, this is hilarious: Hironobu Sakaguchi: The Last Story Not a Final Fantasy Rehash

Quite frankly, until Square comes out with a Final Fantasy that measures up to the first 10, I'm all for Sakaguchi "rehashing" the series.  Lost Odyssey was a better game than either FF12 or FF13.  I'll have a post up later today about my experience with 13 thus far.

Recently Played (starring Mass Effect 2)

I've played so many games recently...I'm going to pare them down to games where I feel like I can give a decent exposition on interesting game-play and design elements.

Mass Effect 2 (Xbox 360)

Wow, where to begin.  I loved the first Mass Effect (yes, even the Mako), and Bioware really out-did themselves with the sequel.  Dragon Age: Origins appears to be getting all of the acclaim, but for my money Mass Effect 2 is the better game.  It has comparable character and dialogue quality, better graphics, and in my opinion a much more enjoyable combat system.

  No, it's not on the order of a true FPS like Half-Life 2 or Modern Warfare.  Nor is it a mind-blowingly awesome RPG combat system.  Despite its hybrid-ness (oh the horror), I find that the things it does include are well-done, and they are a huge improvement over the first episode.  I actually went back and played the first Mass Effect in order to make a new paragon character to play in 2, and the difference in combat was literally on the order of light-years.

  Bioware didn't waste a lot of time and effort throwing in the kitchen sink where combat is concerned; it's pretty much the epitome of a sequel.  But Bioware has historically known when to not fuck around too much with new features, and Mass Effect 2 definitely benefits from that knack.  The aiming is pleasingly tight (oh shit, it's getting sexual) and accurate (wait, what?).  The ammos are neat and useful, if not terribly imaginative.  And the biotic and tech powers are easy enough to use without making fights too trivial.

  The story aspect of the game is classic Bioware, so I don't have too much to say about it beyond the fact that it would have been nice if it was just a tad more inventive than the "go to four different planets and then blow up the bad guy" core that is at the heart of most Bioware games.  I still think Jade Empire benefited from being more streamlined in that regard.  By simply having a linear progression from one area to the next, the world felt a little more cohesive than the disparate systems of Mass Effect.

  My primary dislike in Mass Effect 2 has to be the planet scanning mini-game.  And when I say dislike, I mean that I perceive it as an abomination, leeching enjoyment from the rest of the game like a starved lamprey.  Seriously, after all the work that obviously went into the rest of the game, this goddamn half-baked resource gathering...THING, is the best they could throw in?  Because that's what it feels like - it feels last-minute, rushed, not completely thought through.  If it wasn't those things, then shame on Bioware.  The game is long enough without having a trivial, time-wasting resource gathering mini-game.  Now I am not necessarily a detractor of trivial, time-wasting resource gathering mini-games: you don't want to know how many hours I put in as a bartender in Fable 2.  However, being a bartender in Fable 2 was three things: extremely simple, addictive, and quick.

  The scanning mini-game in ME2 gets 1 out of 3; it IS extremely simple.  You hold down a button and move around the scanning reticle until you get good, good, good, good vibrations.  That's where the positive things end.  Scanning is extremely slow, even if you get the speed upgrade.  And yes, I know that you can speed it up by not holding down the scanning button all the time and just jittering all over the surface of the world tapping instead.  First of all, that doesn't say scanning to me, and secondly, it introduces more irritation by allowing an unforgivable act for OCD gamers like me - potentially missing out on some resource nodes.

  No, the ideal case would have been to make scanning quick enough that you can scan a planet in (preferably) under a minute and be sure that you found everything there was to be found.  Alternatively, something in between 2's horribly slow scanner and 1's single-button scan could have solved the speed problem too.  I personally would have suggested having visual cues on the planet surfaces as to where mineral deposits might be located, allowing the player to gain expertise in resource discovery and speed up the process naturally throughout the game as the player learns how to spot those clues.  Letting the player feel like he is becoming more veteran as he progresses is a reward in itself, and quite frankly, it's present in practically all the other aspects of Mass Effect 2 anyway.

There's no doubt in my mind that Mass Effect 2 is among the top 10 RPGs I've ever played - possibly the top 5 - and coming from me that's no paper trophy.  The vast majority of the games I have played over my career as a gamer have been RPGs, and I've developed a pretty good sense of  what makes an instant classic.  Mass Effect 2 fits into that category, and with the added brilliance of making story choices and characters last between games, I cannot wait to see what the third installment of the story will hold.  If it weren't for that damned resource scanning game, I'd be hard pressed to find anything wrong with this title at all.

Unpause

It seems like it's been a while, hasn't it?  Between the holidays, the new job search, game programming for GeeQ...I'm really bad at posting regularly as it is, but with all those other things added into the mix, the recipe becomes a disaster as far as schedule goes.

Still, I do really want to get into the habit of recording my thoughts on certain topics, so herein begins the effort to reestablish something in this space.