Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

Entries in this blog


Mechanics 1: Randomness in Strategy

A real-time strategy game is, by definition, a game where players are forced to make strategic and tactical decisions in real time. As the game industry grows, the real-time strategy genre has narrowed its focus to a very specific type of game that does little to force players to consider an over-arching strategy as comprised by numerous tactics. Instead of allowing a player's large- and small-scale decisions to adapt and change as events in a given skirmish unfold, RTSs just make players think of resource usage (I have X, I need Y, and I get Z/minute) and basic army composition. Everything else in the span of a game flows from these two mechanics into what is, typically, one large battle near the end of a game. Relic's Company of Heroes changes this design and, as a result, makes its real-time strategy gameplay into a more dynamic and far less predictable experience that forces a player to make harder decisions more frequently.

It's a commonly-held tenet in real-time strategy games that when an enemy unit is right-clicked upon that death befalls it after it takes a certain amount of damage from units that deal a specific amount of damage every few seconds. Blizzard's Starcraft is practically built around a very definitive combat model that follows a rock-paper-scissors methodology with very consistent unit performance results. The micromanagement that occurs within battles in Starcraft has nothing to do with centering an army around a well-covered/fortified position or ensuring that when your Dragoon attacks that his bullets will hit the right part of the enemy siege tank; instead, cover is just determining if a Protoss melee unit is in range of a bunker filled Space Marines and any hit a Dragoon lands on a Space Tank will do the same amount of damage whether it hits the armor-heavy front or the weakly-covered rear.

The design team at Relic took a far different approach to the combat in Company of Heroes than any of Blizzard's efforts. Every part of the game map has a cover value attached to it that, when right-clicked upon, will serve as a hint to a squad of units as to how they should interact with their environment (ie, crouching behind a wall of sandbags or ducking under the lip of a crater). Under this design, two squads of riflemen with the exact same stats can face off and reach a dramatically different outcome depending on their cover situation. As an example, Squad A may be crouching behind two layers of sandbags (heavy cover) while Squad B attempts to take their position from an unfortified open road (no cover or, worse, negative cover). Since the only difference in this sort of encounter is each squad's probability of landing a successful shot (modified by their cover) on an enemy it is, theoretically, possible for each squad to kill each other at the same time. In practice, it may take Squad B three-to-four times as long to eliminate Squad A was it would for Squad A to wipe out Squad B.

The design becomes more complicated when tanks and troops wielding bazookas, panzerfausts, and panzerschrecks join the fray inhabited by the rifle squads above. Unlike rifle bullets, large projectiles in Company of Heroes are a very prescient danger that visibly travel across the screen and violently collide with in-game entities and structures. If a rocket launcher is fired and hits tangentially to a tank's front or side armor it will take minimal damage (or, in some cases, deflect off and hit a nearby structure). If that same rocket hits the lightly-armored rear, though, the take can sustain heavy damage along with a busted engine or armaments. And if that same rocket, or tank shell, hits the layer of sandbags that Squad A was hiding behind in the above example then a player can say goodbye to half of the squad along with the sandbags that were covering them.

While designing the game, Relic must have known the endless amount of abuse that these rockets could wreck upon map structure and players alike because they added a very heavy degree of variation in how a rocket could be launched or tank could fire. The developers of Company of Heroes completely violated the unspoken tenet of real-time strategy and, as such, when a player chooses to attack a target using his Tiger tank there is a chance that a rocket may completely miss a target and hit another enemy, fly harmlessly into the distance, or deflect off of a stray tank trap into a player-controlled building. A player can position his Tiger in such a way as to make a direct attack far more likely but there is, in essence, never a guaranteed strike from a rocket or tank.

The change from a fairly predictable combat design to a very visceral, dynamic battle engine is one that Relic handled to great effect but does such a degree of randomness in combat scenarios do anything to cheapen the "strategy" involved in the game? A fervent Starcraft or Command & Conquer player would be quick to point out that the lack of consistency from game to game would prevent a game like Company of Heroes from ever being considered for competitive play at a pro gamer level. That is a definite possibility, of course, but more realistically what Company of Heroes does is to provide a far more strategic gameplay experience as a result of the surprises that occur in the middle of the game. The game design provides the mechanisms by which a player with a less grandiose army can, by utilizing both cover and more intelligent rocket infantry positions, overcome a larger set of forces. And when such an upset can occur in the middle of a game that encourages tactics across numerous encounters it offers the chance for another reversal of fortunes later on. And that is the kind of strategy that can adapt and change over the course of a game which allows randomness in its design.





I assumed that it would be in poor form to have every single object in need of collision detection on a frame-by-frame basis to have collision tests performed against every object in the scene aside from itself I figured that now would be the time to add some form of spatial partitioning to my XNA engine/library/framework (Rawr).

With that in mind I looked around for some articles on writing an octree component and stumbled upon a really rad demo by Fabio Policarpo. I then adapted that to my codebase, edited the code as I, in my infinite ignorance, saw fit to do, and then added some rudimentary rendering functionality to the octree to provide what I assume will be a much-needed graphical visualization (in the future).

Anyway, it looks like a squishy death array of lasers.

While I'm at it, I present Cubegasm progress in the form of a failed rim lighting experiment:

As it turns out, six-sided, twelve-polygon entities don't look so hot when lit. I also present bullets:

And incredibly uninteresting class diagrams (only parental relationships; no containment ones):

For the record, working on Asplode! was so much easier. Anyone who says that 2D is harder than 3D is a dirty, blasphemous liar. No one says that, though. Because they are smarter than me. Not that I said that either. I think.




Mechanics 0: Thinking About Games

There are, as of my last counting, approximately a gazillion journalistic locales which offer game reviews on the internet or in print. There are not, to my knowledge, any columns which analyze a game mechanic within the context in which it appears along with detailing what is actually fun about the mechanic, and how it could be improved or exploited in the future. This particular edition of Mechanics will do none of that.

Majoring in English in college meant two things: I read a lot and I talked about what I read a lot. There is nothing more self-indulgent and pompous than a bunch of people sitting around a classroom talking about books in the setting of higher education. College students and, more to the point, English majors come up with some of the most absurd talking points based on their interpretations of a given text that it all becomes laughable at some points. I'm talking discussion matter along the lines of absurdity if I was to say that Clifford the Big Red Dog's existence merely served as a metaphor for the presence of communist Russia in the global sociopolitical scene and all of the people he comes in contact with in Norman Bridwell's line of children books are all analogous to various world political figures throughout the 1950s and 1960s. Of course such a theory is absolutely ridiculous, but when intellectuals are asked to find a deeper meaning in a classical text there are instances of such crackpot theories.

There are, however, very legitimate techniques from literary criticism (and new criticism, more specifically) that can be brought over to the gaming industry in a very loose sense. Something like intentional fallacy can be interpreted as the experience a player of a video game takes from his time with a given title that is competely separated from any intended experience on the behalf of the game developer. The concept of a close reading is a far more applicable one as far as this column is concerned: the analysis of a very specific aspect of a game that can be used as a means to enhance a gamer's or game designer's understanding of a game as a whole.

This all sounds pompous on paper and may actually be more pompous in practice but the next edition of this column will be a test in analyzing a game mechanic from a game that is popular now, popular eight years ago, or never popular. I won't be going heavy-handed down the aisle with any more literary criticism stuff in the future (unless, strangely, that kind of thing is desired) so much as I'll be talking about how a game like Braid uses time manipulation to make gamers alter their perception of what initially appeared like a very simplistic, beautiful 2D world. Or, maybe, how the cover mechanics that first-person shooter gamers have been subconsciously applying for decades works in Company of Heroes and how that will alter the future of the real-time strategy genre. More importantly, though, why are these two example designs fun? Is it because Braid makes the people who play it feel smarter? Is it because the cover mechanic offers more for an already-overwhelmed RTS player to manage?

The real goal of this column, though, is to make game developers and gamers try to think more critically about the games they play beyond the "Well, it's a seven-point-five out of ten" or "Damn, did you see that guy's leg fly past me?" reactions. Also, I'll be holding myself to a word count (!). Pinky swear.




XNA Game Studio

Let's talk about games and, more to the point, the making of games. I'm going to start a weekly column (here!) sometime next week entitled "Mechanics" where I'll do my gamer/designer thing by choosing a game that I've been playing recently and analyzing a certain mechanic or set of mechanics that, I think, are remarkable in some fashion. But that's next week.

Microsoft did this really rad thing when they released the XNA Game Studio a couple years ago as a means of giving hobby game developers a means of creating games with a toolkit/API specifically designed for hobbyists that were interested in creating games. This isn't the first time the company has done something like this, as DirectX fills a similar sort of need, but with XNA Microsoft decided to step up their game. So to speak. XNA is best described as the marriage of the higher-level aspects of DirectX, Microsoft's own C# (a managed language), and the benefits of both the PC platform and the Xbox 360. The end result is a vastly more approachable environment for game development without a lot of the limitations of setups like Blitz Basic and pygame without overloading the less programmaticly inclined wannabe-game developers that may get scared off by the concept of working with C/C++ and DirectX or OpenGL.

With the original release of XNA almost two years old that is all old news; XNA 3.0 is currently in beta and will launch with an Xbox 360 XNA game browser capable of displaying and delivering XNA games made by the hobbyist/independent game developer community to the Xbox 360 owning masses in a Youtube-like fashion. That's the idea, anyway. When I submitted my first XNA game I apparently crashed the console of the person who was reviewing my submission. I, apparently, failed to package the game correctly or something. Either way, my first game, which I'll talk more about in a moment, was far from being up to snuff for any sort of widespread public release so the peer reviewer was probably just doing me a favor. The point is that XNA allows game developers to deploy games to the Xbox 360 with an only an absurdly trivial process required to setup the PC/Xbox 360 XNA game compatability. As far as building a copy of the source code for deployment to the Xbox 360? Well, once the XNA Game Studio executable has been installed and setup the only action required by a user is to right-click a project and select "Create Copy of Project for Xbox 360 [or Zune]." The first time I was able to see my game on my 360 it was exciting, to say the least -- though, to say the honest answer, the first time I saw my game on my 360 I realized that I didn't setup a way to deal with the interface without access to a mouse. Nor did I map a button for escaping the program. These realizations are all part of the experience.

That game I made was the first full game I've ever made. I called it Asplode! which, along with my current game Cubegasm, make for some very awkward conversations of the "Uh. What was the name?" and "I didn't catch that" variety, but that's neither here nor there. Coming from a C/C++ background with absolutely no thought paid to the concept of actually learning C# before utilizing it for a full game yielded some very awkward optimizations when describing my project to new people. Despite the many faults that Asplode! had it was a lot of fun for me to work on and, more to the point, it was the kind of learning project I needed to get my codebase the kickstart it needed for an actual 3D game project.

The lack of familiarity with C# is one of the reasons I'm writing this: with the release of XNA 3.0 due in the next few months, there is one very important thing that any XNA game developer needs to understand: memory management is necessary even within the confines of a managed language. The primary difference between working in a language like C/C++ and C# is that, in C/C++, memory is managed very carefully by the programmers and the task is, more or less, given to a developer whether he/she likes it or not. C#, however, cozies up to new programmers and holds their hands while all sorts of terrible code is written that may not rear its ugly head until the worst possible moment (end of the project). C# has an automatic garbage collector that, as the name implies, cleans up loose objects when they go out of scope/use. On the PC, the garbage collector is generational and can perform different types of collections ranging from gen0 (fastest; performed on simple object types with no finalizers) to gen2 (a full collection that actually halts the execution of a program). This is important to keep in mind for XNA game development for the PC platform but, on the Xbox 360, the garbage collector issues become more pronounced as the 360 GC isn't generational so when it fires it actually has to pause all of the currently running threads while it does its thing.

This brings me to the impetus for writing this little introduction to a two-year-old system. For Cubegasm, my current action/RTS, I need vastly more complicated methods of handling rendering, updating, and then collision detection (along with a basics physics simulation layer). Now, I'm no good at physics nor am I a prodigy when it comes to the kind of calculus that is saved for a third- or fourth-semester college class but, due to the infancy of XNA as a community there isn't an abundance of "middleware" that exist for C/C++ applications. When I was interested in integrating a physics solution into my game I heard good things about Bullet and, subsequently, BulletX but when I actually tried it in my project I discovered that it fired off the garbage collector every two seconds or so (down from the two times immediately after initialization that I had my game firing it at). So, as an aspiring game developer that wants to write his/her own program from scratch here's what I'm going to recommend: think carefully about your game design. Ambitious is great, I encourage it, but no one ever got anywhere by being overly ambitious about a game project that, eventually, disheartened everyone involved with it to the point that it gets cancelled. And, if your target platform is the Xbox 360, then remember that your game isn't going to be running on the latest greatest PC hardware but, rather, the hardware that is within every Xbox 360. What runs great on the PC is almost certainly going to run much slower on the Xbox 360 due to less powerful hardware, memory restrictions, developer assumptions about the system, and so on.

Now for a list of communities/blogs that will almost certainly prove invaluable: The XNA Creator site.
Shawn Hargreave's blog.
Eli Tayrien's blog.
Michael Klucher's blog.
Nazeeh ElDirghami's blog.
Stephen Styrchak's blog.
XNAInfo blog. In the end, remember: if you use XNA then you, despite being the kind of developer that has no publisher backing, money source, or the kind of time/manpower that full studios have, have the ability to develop a game for a goddamn console. Just think about how cool that is.

For the interested, along with the release of Asplode! I packaged up the project source code because I thought that it may prove useful or interesting to someone. It's not incredibly well-organized or commented but I'm still using some of it for Cubegasm so it can't be all bad.




Spore Impressions

After ending my very first Spore gaming session a few hours after I startedmany hours after I started I sat back and thought about what I just played. Spore isn't an easy game to classify so much as it is five different games to classify all wrapped in an incredibly polished, coherent content creation sandbox. At numerous moments in my session that took me from the very beginning of a new species up through the beginning of the fifth and final Space Stage I sat back and realized that I'm the only gamer in the world who will have taken a blue race that resembles land-sharks called the Asplodians through each stage of the game but, when I was done, I won't be the only gamer who has had the divine pleasure of seeing my little blue carnivores in a game world due to Maxis' endlessly intelligent and well-assembled online distribution of player-created content. If anyone wants to play with my beautiful little blue babies, add "mittense" to your Spore buddy list.

First, to anyone who has yet to play, I'd recommend doing what I did and getting as many friends' spore buddy names as possible before starting and then, optionally, disabling content from anyone outside your list. It's far more enjoyable for me to see a creature in the wild, click it, and see the name of a friend or coworker and silently judge that person based on their creation than it is for me to see a giant walking pair of tits from El337nubPWN3r. And there were a great many times where I was faced with skyscaper-tall "epic" instances of my friends' creations that picked up my baby blue dinosaur-shark hybrid, gnawed on him a bit, and then threw him into the ground and killed him -- such an instance has probably tainted my friendship with that person irrevocably.

The first stage, where you're a tiny little wormthing with chompers swimming about in a primordial ooze, is a surprisingly enjoyable fifteen-to-twenty minute game of lion-and-cat-and-mouse where the lions and mice get bigger with your player-controlled origin of an eventual species. It is during this period that a player can get accustomed to a simplified version of the Creature Creator that will power the stage following this introduction to the game. Going into Spore I assumed this stage would be the game's weak point but that's not even close to true. The cell phase is a rightfully short-lived blast and I'm looking forward to doing it again when I create my next species.

The creature-driven phase that follows this is best described as a mix of the Spore Creature Creator (can I use this retail subset of the game to describe this?) and World of Warcraft. The player takes his newly land-bound creature from its non-aquatic immaturity to its near-civilized phase throughout this hour-long battle for supremacy as the player bands with the rest of his species to eliminate the other new nests that populate the world. This stage is, hypothetically, about making new friends and enemies in a world and defining a species' eating habits in a learn-by-eating method of sustenance through plants (herbivore), other species (carnivore), or a mix of both (omnivore). Killing or befriending other species will increase your DNA bar (experience bar) and each major experience block gives your creature a larger brain with the final block setting off the light bulb in a creature's head that he can use sticks to roast marshmallows.

The third stage is a tribal stage which tasks, emphasis on the word task, the player with guiding anywhere from six to a dozen of his units towards tribal victory in a real-time strategy-lite game. The idea behind this phase is alright, what with all of the inter-tribal negotiations and/or warfare that yield an increased familiarity with tools as a means to slice people, gather food, and impress other species with but, much like the forthcoming fourth stage of the game, too little of tasks that the player has to deal with in this phase can be completed with very little thought or effort from the player. The only meaningful choice in this segment to be made is whether a player wants his species to progress to the next stage by killing all of the fellow tribes, impressing them with their culture and music, or, uh, a third option? The customization options given to the player in this phase are as hollow as the gameplay mechanics as the only things a player can do are to equip nine variations of "clothing" per each of the five clothing types (helmet/chest piece/shoulders/accessories/one other) to increase the tribe's proficiency in combat, gathering, and culture.

The fourth stage is the civilization phase that gives players access to city customization (city hall, factory, entertainment, houses) and various vehicles (land, air, and sea) to wage the same sorts of war as in the third stage on a bigger scale. This civilization stage is made far less tedious in that it not only makes players balance numerous cities, compared to the third stage's one-tribe-only management, but it also provides a wealth of, admittedly shallow, content creation segments for each of the vehicles and buildings. There are also super-abilities of types that depend on the species a player has created over the preceding stages (warfare, culture, and that pesky third thing I can't remember since I killed everything I came in contact with). I used a nuke at the end of the stage and won which, really, is the best way to win. The biggest disappointment in this section is the really shoddy implementation of the vehicle creation compared to every other aspect of the game; a player can deck out a vehicle with weapons and thrusters and feet and all that jazz but, when it comes to actually utilizing it, the unit just moves and attacks with a generic animation. I can't even express my disappointment that my Asplodius Puppius walker land vehicle didn't use his head-mounted missiles to blow things up. I almost cried. Then I realized I had a landshark in the cockpit (or so I imagined) and that made it better.

I was told by all of my non-US friends, since we were one of the last countries to get access to the game, that the Space Stage is where a majority of the game time will be spent and now that I've reached it I can see why. The player gets access to an interstellar spaceship and is given a variety of missions, quests, and a very, very large map to explore in what has been described to me as a sort of 4X (explore, expand, exploit, and exterminate) game. I've only gotten about an hour in to this stage but, thus far, I've gotten missions to meet new alien life form, establish trade routes, and terraform planets. What I didn't realize was, when terraforming, I can't just throw the species in my cargo hold to the ground of the planet or they die. So, uh, yeah. Now I'm going back to my home planet and "borrowing" some species to populate this alien world.

At this point, I can safely say that my expectations for the game were met and exceeded on almost every level. For every fault the game has, like the stupid vehicle creation limitations and the yawn-casuing tribal stage, there are a dozen other game mechanics that aren't only fun but contain their own metagames for a player to discover. And every aspect of the game is archived and categorized in one of the most important game mechanics I've ever seen: The Sporepedia (below). Now, back to my interstellar landsharks.




Cubegasm: Designing an Action/RTS

What I'm about to say should come as no surprise to anyone who knows me, has talked to me, or reads my articles: my attention-span is lacking and I like being stimulated or challenged as often as possible. Take my obscene love for the Geometry Wars games; Geometry Wars: Retro Evolved 2 (since that's what I'm playing the most now) is like playing a constant adrenaline rush that is a millisecond-by-millisecond test of a person's hand-eye coordination and always manages to make players feel like they're executing Jackie Chan-like maneuvers through the tiniest, most impossible of situations. Getting a good score in Geometry Wars is something that has kept myself and a person from Shacknews playing the game's three-minute-long Deadline mode in a round-robin fashion since the game's release in order to see which of us could get the highest score that the other simply does not have the skill to get -- for the record, at this point in time it's me with a score of 29.9M which ranks me, Xbox Live Tag: skmittens, as 241st in the world (my friend is somewhere around 400). Not only is Geometry Wars: Retro Evolved 2 a superb shoot-em-up but the developer, Bizarre Creations, maximized the idea of the High Score metagame that the GW2 formula brought with it through efficient use of the Xbox Live leaderboards which display the top five scores of the player and the people on his friends list in the game mode selection screen. It's an absolutely genius design mechanic.

My absolute favorite game genre, though, is real-time strategy. I love the entire process of managing an economy, building up a base and an army, and sending out scouting and strike teams to wreck havoc on enemies. And, while playing Madden NFL 2009 every day for a couple of weeks, I found myself thinking more about the different plays that I had in my Detroit Lions playbook, how I was subconsciously figuring out ways to maximize the yardage I acquired on the following play and, in doing so, get the most of any play by taking advantage of what an opponent would think I would be doing given an offensive line-up. After a few games in this mindset I realized that, in a lot of ways, console football games really are a form of short real-time strategy segments with player/route bookends. It was strange how this realization made me not only enjoy the game more (and I already enjoy football and football video games a great deal) but also become a much better player online in the Shacknews Madden league

These two games -- yes, Geometry Wars: Retro Evolved 2 and Madden NFL 2008 -- got me wondering what kinds of possibilities were open to the RTS genre for more action-oriented strategy games that treated game maps as more of strategic set pieces for players to execute a specific strategy, see how it plays out, and then figure out ways to improve upon it to result in the most efficient execution of a certain "play." Out of these thoughts was born Cubegasm.

The Basic Idea is this: a player is given five structures and these are placed at one end of a map. The rest of the map is then populated with a bunch of enemies, towers, walls, and strongholds. The only thing the player needs to focus on is clearing a given goal for a map in the shortest time possible while maximizing his/her score through efficient use of his units, quickly dispatching enemy units and structures, and ensuring the survival of the player's five structures. Each of the five structures will spawn a certain type of unit; the spawning rate will be adjustable by the player in the sense that if, say, Structure A has its spawning rate jacked up then Structures B, C, D, and E will also suffer decreased spawning rates to compensate. The player can balance the spawning rate of his units to fit whatever strategy he plans on employing for a given map. I'm not sure about this but, ideally, I'd like there to be no hard unit cap placed on the player; instead, I will place a score "handicap" on the player when he starts using more than the map's maximum suggested unit amount.

The five unit types will be consistent from map-to-map; these will be the toolkit of a player's strategy. Through intelligent use of spawning rates, a player can customize his army to deal with any situation effectively. And, since this is something that bugs me a great deal about most strategy games outside of Supreme Commander, all of the attacks, both ranged and melee, will depend on actual collision detection. If a shell is fired from a ranged unit then the only way it will do damage to anything is if it actually collides with an enemy unit. The ranged unit will have code to handle predictive targeting of any target a player chooses (or automates) to reliably hit a target but, if the ranged unit is maximizing its range and the target is not stationary, it's very possible for the shell to miss. The last thing I want is to just throw a bunch of random numbers into a mathemetical equation to determine if a unit hits or misses its target. The following units make up the crack squad of cubes in Cubegasm: Melee Cube: This cube will have a high hit threshold and moderate/high damage output, but its attack range will be limited to a physical proximity to its target and the unit's inability to attack flying units.
Flying Cube: This is low-health flying unit that is capable of dealing high damage bombing runs and very low air-to-air damage output.
Ranged Cube: This unit is a medium-health unit capable of attacking units in a short-to-mid range capacity with a low damage output. It is the only unit capable of attacking flying units with any real potency.
Artillery Cube: The artillery in Cubegasm is a glass cannon in the truest sense. It will have a very low health capacity but its maximum range will be the length of most of Cubegasm's maps and its damage output will be absurd with a relatively decent splash damage radius. The mere concept of creating, coding, and animating the artillery for the game is about half of the excitement of making the game for me.
Heal Cube: A healing cube will have moderate health but no attack whatsoever. Its sole goal in life is to undo the damage caused to any player unit or structure and it will execute that purpose with determined cube ferocity. If a structure is destroyed at some point in a given game then, if the player still has healing cubes handy, the structure can be restored to full health and used again to spawn units. It would be a relatively timely process, probably in the range of a full minute or two (which, given the timespan of most maps, would take a player completely out of "time attack" range), but it would allow a determined player to make a comeback if things get grim. And, for an overall discussion of the game, I think that will do it for now. I'm working on the particle engine this week and, if things go accordingly, I should be able to start on implementing the structure logic and at least one of the five units for testing. My goal is to get a prototype level up and running by the end of October but that is, most likely, a pie-in-the-sky time estimate. If the prototype gameplay is entertaining enough for me and some of my friends then I'll work on a map editor and go for a complete game with the concept. I've never really posted about a game design before so, uh, yeah. Feedback would be neat.




Cubegasm + XNA = 3

Cubegasm seems to be my personal Duke Nukem Forever in terms of the number of development platforms it has made a cute little nest in. The project, which I was originally calling Bipolar (since it was about a gigantic manic-depressive, self-abusing, blob that was a weapon of mass destruction if its happiness levels got too low), started as an XNA project using Torque X; though, I was very unhappy with the state that the 3D aspects of Torque X were in. After that I moved on to trying a number of different engines as I had no interest in writing all of the graphical routines from scratch -- these engines included Power Render, Nebula, OGRE, and Torque Game Engine Advanced. Of these engines I chose to use OGRE with Havok as my physics solution as the game design was to make heavy use of physics puzzles. I made a decent amount of progress (with a full development gallery to serve as evidence). After my latest development journal entry, though, I took a look at what little I had to show for the time I spent with OGRE and figured: nahhh.

So I went back to the drawing board. I started with the basics of the game that I wanted to make and the constraints that I am placing upon myself for this particular project; in this case I want to make an action/real-time strategy which exists in a world populated solely by cubes (and boxes). And, unlike Asplode!, I wanted to make a fully-3D game; I think the gameplay could easily work on a 2D plane and, for the most part, it will work out that way in practice but, visually, I wanted to work in 3D and develop a toolset that I could use in either a 2D or 3D game going forward. Asplode! was my first full completed game -- even though I skimped on the feature set and presentation of it as finishing it coincided with the release of my first commercial game -- and now I want to make a full completed 3D game. Once I had my new design for Cubegasm all set and ready to begin work on I decided to abandon all of the work done with Ogre/Havok and go back to using XNA and, as intimidating as the thought was, just work from the very basic and mundane codebase that I established with Asplode! and go from there.

Looking at the barren, untouched, and innocent Cubegasm codebase I decided that my first course of action should be to establish a camera. I had absolutely no desire to write any camera code as it's something I've struggled with in the past and, although I've always come out of the skirmish victorious, I was never fully satisfied. So I did what any white-blooded American would do and went to the XNA Community Site and found camera tutorial samples, scavenged the corpses of code that were placed in front of me by the Internet and came away with a surprisingly decent camera. I'd give details about the mish-mash of techniques I used to create the 3D viewer but I don't want to bore myself to sleep quite yet. Here is a picture of the camera:

The camera posed very nicely for the picture, as you can tell. I suppose, more to the point, the scene posed very nicely for the camera. Whatever. That textured plane was absolutely horrifying, though, so I went about writing code for a procedurally generated grid which has perty polygons:

Since Cubegasm's namesake is, in fact, a cube then it should follow that my game will have a great deal of, well, cubes. Since I don't want to limit myself to rigidly-similar model dimensions, though, I decided that cubes are good friends with boxes and it would be a crime to not let boxes strut their six-sided stuff. Either way there are going to be a great deal of boxes and cubes that populate any given scene in Cubegasm so I wrote a set of routines for rendering large volumes of cubes and boxes at once; I call this creation a Box Batch. I group a number of box batches into a Material Box Batch which groups all boxes of the same material together and renders them at once. It's not very fancy but neither are cubes or boxes; they're simple primitives with primitive needs. One of their needs, for example, happens to be efficient rendering. I deliver, unto my cubes and boxes, that:

Be kind to the boxes and cubes. They weren't ready to be shown to the world yet but I told them that the world would be kind to them in their aesthetic infancy; I promise that they will, in a matters of weeks, look positively stylized and beam with chic digital fashion that only a certain type of graphical style can bestow upon their limited-detail meshes. Anyway, after the box batch was done I went about adding the various types of game XML structures (map, object, and fort structure) to the XNA content pipeline and that's not the quickest of tasks. So that's where I am right now.

So, remember, Cubegasm! It's an action/real-time strategy game where an army of brave cube warriors save their villages from roving box fortresses and evil box minions from imminent destruction! This game is shipping sometime before 2009. I hope. Or else I'll probably cry a little bit. I leave you with an action shot of Cubegasm development.




Cubegasm The New Design

This isn't a long entry, I just wanted to update this and indicate that I'm now back to work on Cubegasm. I mentally redesigned the game into an RTS and, since that occurred, I have a completely renewed interest in working on the game. Here are the three types of XML files I have created thus far:

Map XML:
"1.0" encoding="utf-8" ?>
"Level1" DisplayName="Cubegasm: Level One">
"2000.0" depth="2000.0"/>
"AttackTower_Fire1" SpecialName="DoogieHowserMD">
"10.0" y="0.0" z="10.0"/>
"0.0" y="0.0" z="0.0"/>

Fort (Block-by-block "model") XML:
"1.0" encoding="utf-8" ?>
"Weapon" Type="0" x="0.0" y="15.0" z="0.0"/>

"0" Width="6.0" Height="1.0" Depth="6.0"/>
"0.0" y="1.0" z="0.0"/>

"0" Width="4.5" Height="1.0" Depth="5.5"/>
"1.0" y="2.0" z="0.0"/>

"0" Width="5.0" Height="1.0" Depth="5.25"/>
"0.0" y="3.0" z="1.0"/>

"0" Width="5.0" Height="1.0" Depth="5.0"/>
"0.0" y="4.0" z="0.0"/>

"0" Width="4.5" Height="1.0" Depth="4.5"/>
"0.0" y="5.0" z="0.0"/>

"0" Width="4.0" Height="1.0" Depth="4.0"/>
"0.0" y="6.0" z="0.0"/>

"0" Width="3.75" Height="1.0" Depth="4.0"/>
"0.0" y="7.0" z="0.0"/>

"0" Width="3.75" Height="1.0" Depth="3.5"/>
"1.0" y="8.0" z="0.0"/>

"0" Width="3.25" Height="1.0" Depth="3.25"/>
"0.5" y="9.0" z="0.0"/>

"0" Width="3.0" Height="1.0" Depth="2.75"/>
"0.25" y="10.0" z="0.25"/>

"0" Width="2.7" Height="1.0" Depth="2.6"/>
"0.0" y="11.0" z="0.0"/>

"0" Width="2.0" Height="1.0" Depth="2.5"/>
"0.0" y="12.0" z="1.0"/>

"0" Width="2.0" Height="1.0" Depth="2.0"/>
"0.0" y="13.0" z="0.25"/>

"0" Width="2.0" Height="1.0" Depth="2.0"/>
"0.0" y="14.0" z="0.5"/>

Entity/Unit XML:
"1.0" encoding="utf-8" ?>
"AttackTower_Fire1" DisplayName="Attack Tower">
"25.0" Type="0"/>

All of this goes to create this little rickety attack tower which has an Eye of Sauron-like glow at the top that will launch firecubes at the oncoming crack squad of cube units that are assaulting the enemy fortress. I'll detail the types of units a player will control in a future entry.

Also, as a final note, I believe that this Friday will mark my final day of writing the GameDev.net Daily every week day. There may be plans in motion to make it a more communal sort of daily column so that the burden of writing everything doesn't fall solely on me but, for now, as I approach my eighty-ninth straight Daily it's becoming time for me to take a break.





Even if the GameDev.net dailies didn't give me enough writing to do on a daily basis and I didn't feel an unstoppable urge to play a bit of Battlefield: Bad Company with some fellow developers and Shackers on a nightly basis I still probably wouldn't have a whole lot to write in the way of a Cubegasm development journal.

Over the course of the last couple of weeks I decided that I was definitely a fan of OGRE as a rendering engine and generally useful program framework so, for a few days, all I did was refactor all of my application code, trim a number of unnecessary bits here and there, and generally get a bit more comfortable with the code base. Once that was done I set about getting the game to work as a Release build; as another developer told me in the comments to my past development journal OGRE performs an absurd amount of validation checking when it's running its Debug build. Setting up the Release configuration with Visual Studio took a bit of time (as I'm pretty anal about project settings) but, once I got it working, I saw a framerate increase of, and this is not an exaggeration, about one-hundred times what the Debug build was offering. It was encouraging, to say the least, as I was a bit concerned about the speeds I was seeing in the Debug configuration; once I saw the Release performance, though, I started thinking that OGRE and I could be good friends for more than a single project.

Now that I have working Debug and Release configurations and a vastly cleaner codebase to work within I'm working on the .FORT XML file which will define entire cube forts; forts will have normal blocks, score multiplier blocks, explosive blocks, random effect blocks, and so on and all of this can be specified in the sample XML file that I prepared (and can be seen below). At this point I have all of the XML data being read in and it's just a matter of getting all of the data added to the game world.

"1.0" encoding="utf-8" ?>

"0" Width="2.0" Height="2.0" Depth="2.0"/>
"-6.0" y="0.0" z="-6.0"/>

"0" Width="2.0" Height="2.0" Depth="2.0"/>
"6.0" y="0.0" z="-6.0"/>

"0" Width="2.0" Height="2.0" Depth="2.0"/>
"-6.0" y="0.0" z="6.0"/>

"0" Width="2.0" Height="2.0" Depth="2.0"/>
"6.0" y="0.0" z="6.0"/>

I'm still not entirely sure what kind of game Cubegasm is actually going to be at this point either. Originally I was planning for a player-versus-AI fort combat type of game where each player tried to destroy the other player's fort but the more I get into this project the more I'm contemplating a puzzle/score-whore gameplay hybrid where a player attempts to get the highest score for each "fort puzzle" in the quickest timespan. This particular design would allow me to focus a great deal on the individual designs of the forts and attempt to come up with some really interesting structures which I would give certain "puzzle items" that must either be preserved (kept undamaged through a puzzle), forced to the ground, or destroyed by the player's cube-cannon outright.

That's about it for this entry, though. I just recently got my motivation to work on the game back after a bit of time enjoying the huge number of fantastic games which have come out in the last couple months. I'm in the planning stages for my post-Cubegasm project as well; this one is called Ragdoll Tactics. The mere concept of the game makes me immensely excited but, as per my own rule, I'm focusing solely on Cubegasm until it reaches a state of doneness.

And if anyone else is planning on going to Lollapalooza at the end of the month be sure to note it! Iron & Wine, Rage Against the Machine, Flogging Molly, Nine Inch Nails, John Butler Trio, Brand New, and a bunch of other great bands should make for a fantastic Chicago weekend.




Battlefield: Bad Company

I used one of these:

To take down one of these:

In a multiplayer game this afternoon. It was pretty amazing. I can't say this is the greatest game ever but it's certainly one of DICE's finest works.

I'm going to go play more now. And try and convince my accomplice to join me in unfixing some vehicles.




Cubegasm's First Dev Journal Entry

In lieu of actually doing any development tonight I, instead, chose to write a gaming article (still no Metal Gear Story; I'm still thinking about that) and then a particularly-lengthy GameDev.net Daily. Now, since I've given up hope of getting work done tonight and have accepted the idea that Battlefield: Bad Company will dominate my nights for the next few days, I'll write about what I'm actually working on for the moment.

I've never worked on a project that had any sort of physics simulation occurring within it before; when I found out that Havok released their SDK that could be used by hobbyists and by any commercial product that retailed for less than $10, though, I retreated from my previous stay at Hotel XNA and back into C/C++ Direct3D9 Land. I didn't want to spend months writing a framework and a rendering engine, though, since I'm currently in the kind of mood where I want to put out a game every two-three months -- a timespan which is variable based on game release dates, occasional social interests and obligations, and work schedules. It is a direct result of this mindset which led me to using OGRE. I spent a few days configuring my project, the engine (and all of the modules for it which I planned on using), and Havok in Visual Studio and then got about implementing a basic Havok simulation and rendering aesthetic worked out.

While doing these tests I had envisioned a bright, solid-colored color palette with a very minimalistic lighting scheme for the scene all with a slight HDR/Bloom glow attached. I had the Havok world and the cube objects all set up and working at the time the above screenshots were taken but, in movement, something felt wrong about the way they were interacting with the environment. I looked over all of the environment values that I had set and things looked alright. Then I realized that, when a cube-like entity hit a ground surface with a high restitution value from eighty meters above the surface that the chances of it rotating are, well, almost a certainty. And I wasn't taking an entity's orientation quaternion into account for the OGRE cube graphic whatsoever. So, yeah, fail. The right-most image in the following trio shows that OGRE is having some difficulties maintaining high rendering speeds with all of the cube objects which, really, seems not so good. I'm either adding the entities/nodes to the scene in an unoptimized fashion or the debug rendering runtimes are extraordinarily slow. This is something I'm still playing with at the time of writing.

I got back to this codebase about a week and a half after the previous set of images was taken (Metal Gear Solid 4 needed some love and attention) and when I started up my project build I realized I didn't really like the look things were taking. The aesthetic didn't really match the one I had envisioned for my game so, this past weekend, I went about remedying that (with the most current image being the far right one):

And, now, I'm just cleaning up the codebase as it exists right now and thinking about what, specifically, I'm going to do for the game. My current idea right now is a sort of Fort Wars single-player game against the AI; each player has a structured composed entirely of cubes and each one is attempting to blow up the other person's fort first to reveal a large target-like item in the center that, when exposed, must be hit a few times before it explodes and, then, ending the match. My idea is to make differing types of cubes that have a variety of effects once they are hit: some will give positive benefits to the player (increased damage radius, multiple launched projectiles per shot, etc.), some will give negative benefits, and some will simply be explosive that can take out a number of surrounding boxes at once. Whether this what I'll actually do for the game is, at this point, completely up in the air. I'm going to code some initial mechanics and play around and see which seems like the most fun for me.

That is, of course, once I devote some time to Battlefield: Bad Company.





I know Grid isn't the greatest arcade racing game ever but, goddamn, I love it so much. It has the perfect blend of a career mode where I can make money, buy cars, hire teammates and then merges that with a with a more arcade-like set of racing mechanics. The game has a great sense of speed and an absurdly good damage model that makes events like the Demolition Derby -- an event I haven't played since Destruction Derby for the Playstation -- an absolute blast to play. One of the game's bullet points is an instant replay system which allows players a number of attempts to go back in time in the game (a la Prince of Persia: Sands of Time) and undo whatever mistake was made the first try; this is a mechanic that, at first, I was annoyed by due to the unnecessary menu-work that was required to use the feature but, after some time with the game, it's a fantastic addition to avoid the video game racing gamer's urge to restart a rice a few dozen times to perfect a given event.

Story time:

I got my first team driver yesterday. His name was Seth Brown. He didn't even finish the first of our two races in an event. I want to not only fire him, but tie him to a tree in the middle of the forest and make him pay me back for the event winnings he took. The fact that I couldn't is clearly evidence of lazy development but, anyway, I fired him and then replaced him with a much better teammate and then I got an achievement for it.

Tonight that new teammate and I fucking annihilated the Europe rookie cup and took Team Kitten to the top in every race. At one point I was in second and then I got too aggressive on the final turn and flipped over, did a complete 360 in the air, and managed to make it over the railing onto the other side of the turn, beat out the first place guy, and zoomed to a first-place finish. Then I went back to finish the last (sixth) race of the America Rookie cup, finished that, and then beat some jerk that challenged me in head-to-head and got a million dollars.

Then I drove a Lamborghini for another team and failed to finish 24 Heures Du Mans (a twenty-four minute race) since I got impatient and overly-aggressive and, with no flashbacks left, ran head first into a wall which was surprisingly well-built.




Metal Gear Gameplay

Over the course of the last week I was able to play the final chapter in a franchise which I first played as a rental on my NES way back when I was a munchkin; Metal Gear was a thoroughly confusing game for the four-year-old me. I very much doubt that I made it much past the first few areas as I was not a patient child. I may or may not have played Metal Gear 2. I did, however, play the hell out of Metal Gear Solid for myPlaystation back in 1998. I played it through about four or five times, got Snake's tuxedo on New Year's Eve 1998, and have very fond memories of Psycho Mantis and Meryl and the boss fight with Revolver Ocelot. I would be hard-pressed to think of a franchise which, to this day, I remain so positively nostalgic about aside from Metal Gear Solid (and Final Fantasy VII and Resident Evil). So, now that I've completed my first play-through of Metal Gear Solid 4: Guns of the Patriots, I want to write about the two halves of this game: thegameplay and the story.

When the first Metal Gear Solid came out the game was absolutely revolutionary. It merged action, stealth, and cinematic storytelling like no game before it had successfully done. Everything had fullvoiceovers , the graphics were phenomenal, and the violence was realistically gruesome. The series stagnated after this first iteration with the release of Metal Gear Solid 2 riding on the first game's coat-tails and, what's worse, forcing the player to play as someone other than Solid Snake for 75% of the game and containing unnecessarily lengthycutscenes that felt longer than necessary (especially its heavy-handed ending). Metal Gear Solid 3 improved on the Metal Gear Solid formula by leaps and bounds without changing any specific aspect too radically. Much like Resident Evil, the Metal Gear Solidgameplay was still utilizing fixed camera angles and by the time the third iteration of the franchise rolled around gamers began to tire of it -- though Metal Gear Solid was so remarkably well-done that it escaped a large amount of the potential criticisms which could have otherwise befallen it.

Loading up Guns of the Patriots was a fantastic surprise; gone was the top-down camera angle -- ditched in favor of an over-the-shoulder camera -- and the inability to fire weapons from first-person and still move around. Gone, too, was theHUD's radar that showed enemy positions and their line-of-sight. In the first ten minutes of Metal Gear Solid 4 a franchise veteran is suddenly faced with an abundance of viable play styles as nonlethal measures, stealth, and murderous rampages are all interchangeable. The nonlethal and stealth approaches both become powerfully tempting the moment that a key character is introduced that is capable of being used as a weapon launderer at any point in the time. Players no longer will face a dearth of ammunition or weaponry as dozens upon dozens of weapons can be purchased and customized with limitless ammunition for each being a triangle button and some in-game currency away. And, oh, these guns have gravity. Each possesses truly booming sound effects and carry with them a feel of destruction like no Metal Gear game in the past.

The implications of making the gunplay of Metal Gear Solid absolutely fantastic are that the entire flow of the game becomes radically different. Players have a deadly arsenal that puts the greatest weapons in Metal Gear Solid 1, 2, and 3 all to shame and this actually makes an entirely offensive strategy completely plausible. Finishing the game with a large number of kills andheadshots yields different end-game items and badges than, say, a game where no one was killed or a game where a single alert was not set off. From my first personal play through I wanted to be stealthy but once I accidentally killed a private military contractor and heard a group of rebels behind me shout phrases of thanks (one threw me some rations as payment) I realized that I could, instead, kill a bunch ofPMCs and aid the rebels in their fight. This, to me, was a far more enjoyable and worthwhile endeavor than sneaking around both groups of combatants. I also earned a lot more currency to upgrade my M4 into a grenade-launching, silenced, long-range killing machine.

There are other subtle additions to Snake's arsenal this time around as well. Snake's camouflage will automatically change the match the environment when he goes prone or presses up against a vertical surface and remains stationary for a few seconds -- a much improved mechanism from the menu-heavy method of performing the same task in Metal Gear Solid 3. The "threat bubble" that pops up around snake when he remains stationary while crouched or prone is also a superb way of highlighting the danger in Snake's surroundings by showing "blips" in the translucent circle that hovers and follows Snake around. And the agme is full of streamlined additions to the tried-and-true gameplay of the series and just serves as further evidence of the ridiculous level of polish present in Snake's final chapter.

For the first time since the original Metal Gear Solid I finished the entire game and still wanted more. The gameplay didn't feel like a means to advance the story or to just make my way to the next plot point; the story provided the impetus to search my environment, kill the PMCs, and make it to the objective that I actually enjoyed reaching. The basic mechanics all function so responsively and the levels are designed to promote both stealth and violence that alternating between the two feels completely natural.

What's more telling than this is that I started up a new game on the hardest difficulty tonight because I wanted to jump back into the game world and play more. Maybe this time I'll actually play through the game without setting off any alerts or attempt for a non-lethal means of progression.

I really, really doubt that will last.




A Digitally Distributed World

As more and more developers and publishers realize the benefits of distributing their products online, more types of digital distribution applications have been created to benefit the cause. At this point in time gamers have their choice of applications like Impulse (a rebranded and revamped Stardock Central), Steam, Gametap, and EA Downloader (which is now simply the EA Store) and then digital distribution websites like Direct2Drive, Greenhouse, and GamersGate.

Among gamers, though, the most oft-used and oft-mentioned means of acquiring new games is Valve's Steam. First released in September of 2003 as little more than a means for Valve to distribute and update their own titles, the application was widely criticized for an extremely high memory footprint and its sluggish performance. Now, though, the service has been continually updated and refined into an industry-recognized method of acquiring and updating Valve's titles along with a huge assortment of third-party games. The most recent major upgrade that the platform received came in the form of user stats, achievements, a community system (complete with friends lists, groups, and event calendars), an in-game overlay which gave users access to all of Steam's features in any game launched from the Steam game list, and a revamped store. Up until the release of Steamworks most of these services were only properly utilized in Valve's own products but, now, developers partnered with Valve can implement the same Steam-specific features in their games as well. Steam Cloud has also been talked about which would give Steam users a sort of virtual storage space for game save files and preferences.

One of the other digital distribution applications that I install whenever I format a computer has always been Stardock Central. Before I ever even thought about working at the company I was a fan of Stardock's games and a couple of the applications that the company produces. Back when the actual game catalog was slim-pickins all I ever did was launch the program, download a game or an update, let the thing install, and then I shut the program down again until I felt like checking for another update a few weeks later -- all of this was around the launch of Galactic Civilizations back in 2003. It wasn't a very pretty program by any means (though it was a far cry from Stardock's very first digital distribution app, Component Manager, back in 1999), but it didn't really have to be.

Earlier this week Stardock launched Impulse which is more than just a pretty face on top of years of knowledge gained from the development of Stardock Central; the best write-up on the program available was published by Brad Wardell on the day of its release. As a game developer, though, I think of Impulse as being an incredibly open and community-accessible distribution platform unlike any other in the industry. We're developing a set of tools called "Impulse Reactor" which we're planning on giving to third-parties so that they can easily access community features and -- since I'm a gamer and a game developer -- game statistics, matchmaking, achievements, friends lists, and all of the other things that users of Xbox Live have been using and relying on for years.

I play a pretty ridiculous amount of games; specifically, I play a pretty ridiculous number of shooters and strategy games. Valve's multiplayer shooters are the best I've played since the days of Quake 3: Rocket Arena. Last year I played in a giant Shacknews Team Fortress 2 tournament (no, really) and, before that, I put a pretty crazy amount of time into Counter-Strike: Source and, for both games, Steam has been absolutely invaluable. I've taken part in tournament games that our team leader threw into the event calendar and had a little message box pop-up to notify me when and where I should go for a match and, after a game, our entire team joined a group chat room to talk about the match and what we needed to do better for the next game, and so on.

But why aren't there any applications which have this kind of integration for real-time strategy games? The amount of time I've sunk into Warcraft 3: The Frozen Throne, Company of Heroes, Supreme Commander, and Sins of a Solar Empire is, quite honestly, embarassing. This same fact is true of Civilization 4 and its expansion packs. Of all of the digital distribution applications that exist for the PC none of them have the kind of Xbox Live statistics, matchmaking, and general game integration for the genres of games I enjoy the most. In conversations that we've had around the office this is the kind of gap that we want Impulse to fill (and, with Impulse Reactor, give other developers the tools to bring the same features to even more oft-forgotten games and genres).

The only thing that comes from overzealous application zealotry and exclusivity is a lack of competition that brings about new features, more content, and more innovations.




The Daily GameDev.net

So, yeah, I realize I absolutely fail at updating my own site; luckily, though, I'm excellent at updating other peoples' sites. Like GameDev.net where I can be found writing news entries that have been described as distinctly me (which works out well).

Anyway, here are links to the last nine as of the night of this posting. June 3rd 2008 -- Konami and Crytek Woes.
June 2nd 2008 -- Phil Harrison, Ben Mattes, Gabe Newell, and Free Havok.
May 30th 2008 -- Hideo Kojima's thought on games and movies and quality of life in the games industry.
May 29th 2008 -- True 3D gaming and the "nearly catastrophic" Playstation 3.
May 28th 2008 -- The end of disconnected single-player games and in-game advertising failures.
May 27th 2008 -- Age of Conan, Brett Ratner and games, and Capcom and movies.
May 26th 2008 -- ESA Failures and the last generation of consoles.
May 23th 2008 -- Gamestop makes lots of moneyhats and Microsoft on delisting Xbox Live Arcade games.
May 22th 2008 -- Niko Bellic voice actor complains about royalties and World of Warcraft bots.




Age of Conan

I posted this in the lounge but I figured I'd mirror it here since these screenshots wouldn't fit on my site's main page. Anyway, this is Age of Conan and it's surprisingly fun.

A mammoth and his groupie ganked me :(

The greatest archer guards ever in the history of ever

Mufasa told me this would all be mine one day

Typical virgin sacrifice

nevicata and I admire the tree

Look! I'm Altair!


Strom sucks

This is the kind of resistance all games need

Johnny Cash would be proud

M means short hookers with big boobs




Grand Theft Auto 4

878,598 dollars earned (of which $376,945 was spent), 860 killed by one of my 161 cars stolen or ventilated by a number of my 16,367 bullets fired, 94 missions completed, and 28 hours and 34 minutes later I have completed Grand Theft Auto 4, a game sitting at a solid 98% overall score on Metacritic three weeks after its release. It's a game that cost $100 million to make and a game which grossed $500 million in its first week. The question that no one is asking at this point in time since it's been answered by eight media outlets already is: does Grand Theft Auto 4 live up to the incredibly high expectations? Absolutely.

Grand Theft Auto 4 starts with a sweeping introductory sequence designed to introduce the protagonist, Niko Bellic, as the fresh-of-the-boat Eastern European that he is. Once disembarking from the ship that carried him to Liberty City, USA, players are introduced to Roman Bellic, Niko's cousin. At this point, the two characters which fuel the single-player storyline are introduced and the game's pace begins at the snail level. Through the next ninety-three missions the epic storyline will unfold as missions progressively get more difficult, wider in scope, and the plot elements become more and more deadly. Rockstar is so confident in their design that it has the first five hours or so of missions serve as a running tutorial where the body count remains in the single-digits unless the player feels the need to cleanse the sidewalks of the first of the game's four boroughs. This very slow, meaningful pace is the game's greatest asset: the first time a player is thrust into a situation where numerous people have to be killed is about six hours and feels like the major turn of events that it should feel like.

At its heart, Grand Theft Auto 4 is still Grand Theft Auto. It does very little to deviate from the franchise's traditional game flow: mission begin marker, cutscene, mission execution, cutscene, [...], mission end. Within the confines of the game, this formula works better than most games could ever hope for. The game succeeds because of this fact; every aspect of the experience is fine-tuned to perfection and is comfortable within the tapestry of mechanics that exist around it. The driving feels realistic (a first for the series), the gunplay is visceral and feels surprisingly natural once the unique control scheme is understood, and the gunplay while driving is a joy to engage in. A single bank robbery mission in Grand Theft Auto 4 is executed to a level of perfection that entire games based around the concept (Kane and Lynch) can't reach. At no point throughout the nearly thirty hours of gameplay did I ever frown at the idea of a firefight or a high-speed escape from a four-star wanted level.

It is a surprise to me that the biggest complaints I have with Grand Theft Auto 4 are related to the cinematic aspect of the game. The epic feel comes natural to the game as a result of the developers' patience with their storytelling so why, then, does the game start to fall flat in its final act? Every few hours spent with the game I feel as if I've reached the climax of the game and there was no way that a mission could be topped or a cutscene could enthrall me more and then, a few missions later, I'm overcome by the same feelings. But, as a result, at around the 85% completion mark (of the story which entails a total of 63-64% of the in-game "completion" marker) as the game's various plot lines started to end and the sources of missions became fewer and fewer, Rockstar seemed to choose the least interesting plots available to them. Early in the game the player is introduced to a member of a once-infamous Irish family that, as one character points out mid-mission, used to "own" Liberty City. Niko comes in contact with every member of this family and each of these characters had a very deep persona with a wealth of available back story to develop on. Instead, the writers chose to go down the path infested with the scum that composed Liberty City's Italian mafia. As I took each of the missions given to me by members of the mafia it seemed like I started dealing with very unlikeable two-dimensional characters instead of the vast number of the incredibly well-written people that made up the first three-quarters of the game.

While GTA4 puts a far greater emphasis on character interactions and the maintenance of relationships, I still can't help but feel that the Niko I'm playing as I make my way through the game as a player is a vastly different one from the Niko I see portrayed in GTA4's numerous cutscenes. These amazingly well-produced, directed, written, and voiced movies that serve as bookends for the missions given throughout the game are a joy to watch but I still feel that when it comes time to get in a car and execute the orders given to me during the CG movies that I'm disconnected from the meat of the story. The dates (casual and romantic) which make up a significant portion of GTA4's sidequests did a remarkable job of lessening this feeling of disconnect, but it remains one of my primary problems with Grand Theft Auto as a series.

And since I don't care to elaborate on these much since they've been harped on endlessly elsewhere, here are my only two real gameplay complaints: no checkpoints for the especially long missions and far too many artificial chase missions where I was not allowed to harm the targets of the chase until a certain scripted event happened.

It's a shame that Grand Theft Auto 4 may be the last major single-player Grand Theft Auto game ever made by Rockstar North because the switch back to a very gritty, realistic setting with a scaled back map size and feature set made Grand Theft Auto 4 one of the greatest video games ever created and I'd love to see what the fruit of their future labors would produce. Just, please, don't make an MMO. Please. I'm begging.




The Political Machine 2008

I've been working every day (and what long days they are) for the last couple weeks on The Political Machine 2008 as we make our final surge to the game's gold date and figured I might as well plug it here since I haven't had time to write about anything else lately. My role on the game is primarily as a gameplay programmer (which has been awesome). Anyway, pictures:




Asplode v1.2 Release

For this update, my role in Asplode! was absolutely minimal. While I'm in the middle of a mild crunch for The Political Machine 2008 and then away at Rochester, New York for a Paramore concert, Josh was working asininely hard on version 1.2 of Asplode!. As started, my role in this update was purely peripheral as, in my spare time, I've been working on the start for Bipolar and taking some of Josh's code for his game and turning it into a more generic library that both of us can use in our current and future projects (the library is HardCat Library, obviously). Anyway, major changes: Fixed a bug where the player's time alive, score multipliers, etc. weren't getting reset for successive game sessions.
Fixed a bug/leak related to game audio.
Complete rewrite of the particle engine's rendering (GPU-driven now).
Refactored the enemy code.
Now entirely functional on the Xbox 360.
Added an option for full screen.
High Scores!
Asplode! Installer
Asplode! Source

[Edit]: For some inexplicable reason, the XNA redistributable may still fail to install using the installer, so you may want to manually install it: XNA redistributable.




An Asplosion! of a Re-Release

On Sunday, I linked to the source/executable for my top-down, arena space shooter Asplode! and one of the things I wasn't really proud of was how terrible the performance was for the game. Well, one of my friends took the burden of fixing it up a bit and made an installer. He then passed all of this new fangled technology onto me and, in return, I edited a couple more of the source files, added him to the game's credits, and made a new, updated installer for the game. So here, ladies and gentlemen, is a far more proper release of the game.

This installer will execute the DirectX Web Setup, install the .NET 2.0 Framework if it isn't already, and the XNA redistributable, but it does not contain the source for the game. Like any XNA game, this will require Windows XP or Vista, and, at the very least, a graphics card capable of Pixel Shader 2.0.

Asplode! v1.1

[Edit]: I failed part of the installer, so the XNA redistributable will also need to be installed.




An Asplosion! of a Release

Yeah, so, I'm releasing Asplode! now and such. And, along with the game, comes all of the source to the game.

I originally wasn't planning on releasing the source but as development winded down and I started to play the game for longer sessions I soon realized that the game became virtually unplayable on my machine after about seven-eight minutes. I thought this may have been a result of poorly-managed graphical assets so I took a couple days to optimize them (and, as a result, the VectorModel and VectorParticleSystem bits of the code are an absolute mess to comprehend). After I finished doing that I jumped back into the game and, while it ran better for a while, the horrific mid-to-end game performance was still very much a factor. I went through and tweaked and optimized bits of code in other places that seemed like they would cause issues and, still, the performance problems persisted. At that point I decided that, since I got the game to a playable state and I didn't want to devote a whole lot of time to what is, essentially, a Geometry Wars clone, that I would just throw a main menu screen on the thing, an end-game screen, and release the source code and call it a day.

So that's what I'm doing. Here's the game; tremendous performance issues and all.

The Game: Asplode! plays out pretty much like you'd expect; on the 360 controller the left joystick handles movement and the right joystick aims/fires bullets. There is a score multiplier which is slowly increased with every kill made up to and the multiplier reaches a maximum of nine; every time a player dies, the multiplier is reset. There are also three possible weapon upgrades. (which persist after death) which are awarded based on the number of asplosion combos -- any death with a red pentabomb involved. A player has only three lives; I thought about implementing a way for a player to earn more lives but, since I have no life, the least I could do is minimize the amount of life a player can have. So there's three. That's it.

The Source: Uh. Yeah. Just try not to learn anything aside from what never to replicate. Ever.

The Requirements: One of the issues with an XNA title is that there are a few necessary items to install to get one running. So, I'm sorry about that. If it wasn't such a beautiful creation, I wouldn't use it. XNA Redistributable (Included), .NET 2.0 Framework, and I believe a run of the DirectX Web Setup and/or Visual Studio SP1 Redists if the first two don't get the job done.

And now off to start the game which isn't a blatant clone.




Chronicles of Cloud (and Bipolar)

I've been playing a very time-intensive game of musical chairs with various three-dee engines over the course of the last two-and-a-half weeks in an attempt to find the one that would be best suited to my particular development style and the kind of game I want to create. And I can safely say that, tonight, I have reached the ultimate solution. That's right, after toying around with things like TorqueX, Torque Game Engine Advanced, OGRE, Irrlicht, Nebula3, and, finally, PowerRender. The latter two of the list appeared to have the most potential, with PowerRender being the closest thing to what I was looking for, but the most recent iteration of the engine is still under heavy development and, what was the most troublesome, seems to be getting very infrequent updates. So, after all of the wasted time, I decided that I was going to dig out my old C++/D3D9/D3D10 framework and just rip out the D3D9 parts for use in a new framework which I could use in the future.

I got exactly an hour-and-a-half of work done on that last night before I realized that it felt way too much like the kind of engine work I do at my job every weekday. So now, and for realsies, I'm back with XNA. I'll be releasing Asplode! this weekend in its terribly-performing state (and open source) and, hopefully, everything I learned in the development of that will help me create a far more useful toolset this time around as far as memory management is concerned. The most important lesson I have with me that I learned from Asplode! is that the most important thing about memory within a managed environment isn't necessarily the allocation of memory so much as it is the deleting of it. Apparently the garbage collector is a wicked beast that must be appeased in order to maintain stable gameplay performance. I don't know. I'm still getting the hang of the intricacies of C#. When I was working on Asplode! -- and this will be readily apparent in the source if people peruse it -- I didn't know anything about C#. I simply coded as if I would code a game using C++ and, when code didn't compile, I read up on why the error occurred and what I needed to do/learn in order to fix it. Hopefully, this time around, I'm a bit more well-prepared. It also helps that Drilian and I are teaming up for some of the more game-independent stuff.

As a random note, I beat Final Fantasy 7: Crisis Core earlier this week. While I have the same issues with it that I do most RPGs (that the combat becomes asininely annoying by the end of the game), the game did the Final Fantasy 7 universe -- and FF7 is the only JRPG I've ever enjoyed (and loved) -- absolute justice. The story was incredible and provided a lot of great depth on Zack, the inner workings of SOLDIER, and the root for Cloud's identity disorder. And seeing Sephiroth function in more "normal" times and take actual solace in communication with friends/peers was cool. I'm just waiting for my copy of Advent Children to arrive so I can re-watch that. Now it's back to Wipeout Pulse, AoE3: The Asian Dynasties, and more Rock Band. And GT5: Prologue. Grand Theft Auto 4 can come out anytime now as well.

Anyway, yeah, that's about it. I hope everybody has been The Daily GameDev.net news pieces I've been posting every weekday morning. They're almost asininely fun to write up but they do tend to take the place of dev journal updates at times, so if this thing has become a bit more stagnant than usual then that's probably the reason.





I hate so many things about game engines. I spend all day coding graphics/engine stuff so, when it comes to my hobby projects, I would like as much of my work to be as gameplay-focused as possible. Yet it seems that the kind of game engines that would spring to mind first are the most annoying in a number of ways. GarageGames' engines, for instance, are either too immature/buggy/undocumented (TorqueX) or so filled with features and reliant on scripting that it's primarily useless for someone like me who wants as many components/features as possible to be handled from within code. Though Torque Game Engine Advanced, too, suffers from a lack of documentation except for what it has generated from XML comments within the source code.

Anyway, yeah, anger.

I'm looking at some other alternatives for my blob game now. It's very unexciting. And my cat is experimenting with varying orientations of his ears. It's alternating between cute and aerodynamic.





My mother and sister were in town this weekend and we went to Ikea. And my Mom brought down a box I had shipped to the house from the Valve Store. The images below are best served with a reference to what my place looked like in January.

It's starting to actually feel like an apartment instead of a glorified dorm room. I like it. Kitty likes it too.



Sign in to follow this  
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!