| Monday, September 29, 2008 |
  Mechanics 0: Thinking About Games | 
Posted - 9/29/2008 9:47:28 PM | 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.
| |
| Wednesday, September 24, 2008 |
| XNA Game Studio | 
Posted - 9/24/2008 10:17:39 PM | 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: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.
| |
| Sunday, September 7, 2008 |
| Spore Impressions | 
Posted - 9/7/2008 8:33:05 PM | 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.
  
| |
| Thursday, September 4, 2008 |
| Cubegasm: Designing an Action/RTS | |
Posted - 9/4/2008 8:24:38 PM | 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.
| |
The entries in this journal have all been posted, along with many more, at mittens' personal site at www.polycat.net.
|
| S | M | T | W | T | F | S | | 1 | 2 | 3 | | 5 | 6 | | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | | 25 | 26 | 27 | 28 | | 30 | | | | |
OPTIONS
Track this Journal
ARCHIVES
August, 2009
July, 2009
June, 2009
May, 2009
April, 2009
March, 2009
February, 2009
January, 2009
December, 2008
November, 2008
October, 2008
September, 2008
August, 2008
July, 2008
June, 2008
May, 2008
April, 2008
March, 2008
February, 2008
January, 2008
December, 2007
November, 2007
September, 2007
August, 2007
July, 2007
December, 2006
July, 2006
June, 2006
May, 2006
April, 2006
March, 2006
February, 2006
January, 2006
November, 2005
September, 2005
August, 2005
July, 2005
|
