Warning: Game Design Philosphy Screed Imminent!

I'm getting close to finishing my Quake mod (the alpha version, anyway), and I'm really excited about returning to formal C++ game development. I've been spending a lot of time thinking about what my first new game is going to be, and about what statements I want to make about game design in general through my games. Well, since I'm not here to talk about what my next game is going to be that means I must be about to unload some heavy game design philosophy crap on you. I apologize in advance.

To understand what I have to say about the state of game design, first I have to walk you through a hypothetical game experiment.

Let's say that you have a game. It is a 2D Metroidvania sidescroller: You attack baddies along the way, do some platforming, and when you reach the right hand side of the screen you go on to the next level. Next, let's say that at the very beginning of each level there is a switch on the wall that you have to hit by pressing the 'up' button. There is no obstacle to the switch, and it is in the same spot in every level just two steps forward from where you spawn, but you can't beat a level without first having activated the switch. Thus, at the start of every level the first thing you have to do is ALWAYS to take two steps forward and press 'up' to flick the switch.

Ah hah! I hear you all cry out that this is bad game design! And it is! Why? Well, the switch doesn't add anything to the game, it is just something you do at the start of every single level. You could cut it right out of the game without losing anything. The lesson here is clear: Any time a game has you doing something robotically just for the sake of doing it, it is bad game design. It is essentially putting a non-game obstacle in your way that you have to get past in order to actually play the game portion of the game.

Now let's take a look at a popular playing guide to the critically and commercially uber-successful Blizzard game Starcraft 2 (this is from a Terran build order):

(1)Start out with 9 SCVs, then build a (2)Supply Depot. (3)Make two more SCVs and (4) another Supply Depot when the resources become available. After the second Supply Depot is done, have the (5)SCV start building a Barracks. (6)Build the Barracks in such a way that it helps block the entrance ramp into your base. Once another (7) SCV gets built, have them build another (8) Supply Depot to further block your ramp. After your 14th SCV (9) you should start work on your (10)Refinery and save to upgrade your base to an Orbital Command Center (11).

*(Thanks to http://www.articlesbase.com/computer-games-articles/starcraft-2-terran-build-order-the-best-terran-build-orders-to-dominate-your-enemies-with-ease-3071016.html for the build order example)*


As you can see, without even counting every single SCV build you have at least 11 different things to do. You do these things at the very start of every single level you play, without variation, and that is only in the first third or so of the guide! In terms of our hypothetical sidescroller, that is 11 different switches you have to turn on before you can start playing the game. So why is it so obviously bad in our nonexistant sidescroller situation, but totally accepted when Blizzard does it in their AAA rts?

Partly because of shitty game reviewers who are too blinded by hype trains to even begin to think objectively about the games they are critiquing, sure, but I think there is more to it. I think that something that happens far too often in modern game design is a misunderstanding of what makes a game genre.

16 years ago Warcraft: Orcs & Humans came out and defined the rts genre. Sure, it was mostly a ripoff of Dune, but Warcraft really refined the core mechanics of Dune and made a hugely successful game out of them. From then on if any game designer thought rts, he was really thinking Warcraft. Nearly every rts after Warcraft took Warcraft as a base and went from there.

The base was something like "Base building > Peasant resource management > Army Building", and a new game would come and do something like "Base building > Peasant resource management > Army Building > Hero units", or "Base building > Peasant resource management > Army Building > Rock Paper Scissors combat system". Everybody just takes it for granted that rts means "Base building > Peasant resource management > Army Building". But I demonstrated earlier that this design structure breeds build orders, which is awful game design.

Furthermore, this design de-emphasizes the combat, because there is an inherent focus on the rapid continual building of your base/pumping out of units. You almost never watch a fight in these games because you are too busy jamming the hotkeys on your keyboard to keep base expansion and unit production going. Instead you just grab a mess of your units and lob them at your enemy's general direction. This is a staple of the rts genre because of Warcraft, but why?

Think about it: The reason the rts genre seemed appealing to us in the first place was because we wanted to be generals leading big armies to crushing, violent victories on our screen. We don't play because we want to facilitate a bunch of peasants and organize the most efficient building plans while our troops do something cool and fun off screen.

Now, I don't want to make an rts game, that isn't my point. The genre is largely dead to me now, and it doesn't excite any passion or imagination in me at all. I just bring up that example because what I want to do is to really examine genres in my games. I want to boil genres down to their TRUE essential attributes and then build from there. Only when a genre is deconstructed to its primal ingredients can the genre then be moved forward in a meaningful way.

That is why I want to take a sort of minimalist approach to my games. I want to take the games back to the late 1980's, the golden age of PC gaming, and then go from there.

DISCLAIMER: This doesn't mean that every single one of my games is going to be a minimalist and completely original idea. As a matter of fact, my next SDL game is likely going to be extremely conventional. Besides, boiling games down to their essentials is tough work! Still, this is what I want to do, and it definitely will be a theme of mine going into the future when I get more comfortable taking on somewhat ambitious projects.

Here is a *link* to the article that really got me fired up enough to write this today. Once again it is Ultima that gets me feeling motivated about game design.

Stay on target...

Content is locked in and ready to move.

Time for some testing, where I can tweak the code (especially the AI stuff) to where it does everything I want it to. I also have to figure out and finalize entity placement in the level, which will also be sorted out during the test runs.

This shouldn't be heavy lifting, but you know how that goes. At any rate, a release shouldn't be very far off now. A week or two tops. I'll do a little advertising on the QuakeDB group before I release so that somebody - anybody - gives a shit and plays it a bit. Screenshots will come pouring in very soon, I promise.

Checking in.

I'm looking to be 100% on all content by the end of the weekend. From there it is just a matter of testing and finalizing. The home stretch is finally here. Screens soon.

I'm still looking for a way to ditch Blender 3D, and really the entire Quake .mdl format. The thing about Quake .mdl models is that they don't use any bone information, they purely save vertex coordinates from frame to frame. This is... Unfortunate. It inherently means wonky animation, and eliminates the possibility for decent hitbox support and sockets on the model (for muzzle flashes, storing weapons, and other cool shit like that).

Worse, getting your .mdl animations into the game is a painstaking process. As I said, the .mdl saves vertex coordinate information, which means to get it in game I have to write a script to tell the game what animation is going on frame by effing frame. For example, when I want to code my death animation I have to look at the model itself and find out what frame the death animation I want starts at, say 46. From there I tell the game that frame 46 is death animation A's frame 1. Then I tell it that frame 47 is death animation A's frame 2. This goes on until the animation is finished. What. A. Nightmare. It gets really confusing when you are 120 frames in and have to remember that you are really on frame 13 of shoot animation c. And of course Blender is kicking you in the ass the whole time.

I miss the good old days of Half-Life's .mdl format modeling. Half-Life .mdls were a compilation of vertex info, texture info, and bone info. This made animating and getting a model in game an absolute dream. Any animations you did were self contained pieces of information, meaning you didn't have to get down and dirty and worry about frame numbers. You just made an animation called "shoot", and told the game to do "shoot" at the appropriate time and voila. And the tool of choice was Milkshape 3D. Ahh, Milkshape, how I loved you and miss you. Unlike Blender, Milkshape is incredibly easy to use, never crashes, and has beautiful pipelines to all of the major low poly model formats that used to be relevant at the time.

I think a good analogy for what Blender is to Milkshape is to think about what GIMP is to Paint.Net. GIMP tries to do all of the things that the big expensive retail product Photoshop does while Paint.Net just tries to keep the usability of Paint while adding some professional type features. GIMP ends up being an unintuitive, barely functional mess while trying to do all those fancy things. Meanwhile, Paint.Net does everything a shitty programmer-artist like me needs, and it does it painlessly and easily. In the same way, Blender 3D tries to do everything that Maya, 3D Studio Max, and Softimage XSI do, but does it all shitty while maintaining an obtuse user interface. Milkshape 3D just tries to be a super usable low poly modeling program for games like Quake and Half-Life, and it absolutely succeeds.

So, since Blender 3D has been making me weep so much in the last couple months, I've recently really been trying to find a solution in a new model format, preferably Half-Life's .mdls. So far the best I've been able to come up with it the Darkplaces engine's .DPM format. It uses .smds to separate vertex and bone information, like Half-Life, but is specific to Darkplaces. The only real problem is that few people use it, and even fewer know exactly how to use it. Still, I'm going to experiment with it in the future and see if it is a possible solution for me.

At any rate, for the time being I am going to grit my teeth and fight through the unbearable darkness that is Blender 3D to push out the last model or two I need. I'm too close to being ready now. Perhaps in the future I'll use the .DPM model format which will enable me to bring back my toon shading, as well as generally make my life much easier on the 3D modeling side of things.

quickie update...

I'm in the process of touching up/redoing a lot of the modeling bits. For the time being I'm going to drop the fake toon shading. In the vertex grouping process Blender was being a real bastard about all the flipped faces, so I have decided to sacrifice the shading for more control over my animations. Oh well, such is life when you have to work with shitty open source tools. The toon shading will have to be something that I'll hard code in on the engine side at a later date, in an update.

Speaking of Blender, it continues to be a gigantic thorn in my side. I can't for the life of me find a decent way of rigging a model. Weight painting is SUCH a pain in the ass and is so damn inaccurate. I always end up painting vertices that I didn't intend, or missing some that I did intend. Why can't I just go vertex by vertex and assign them to the bones that I want? I was doing that in Milkshape 3D ten years ago for gosh sakes. But as far as I can tell, my only options for rigging in Blender are weight painting and the easy but wildly inaccurate enveloping. Aarrgh. I'll try googling around/forum diving to help me not hate weight painting.

In the mean time, here is a revised list of things that are going to be in the first release:

• One semi-long level.
• A pistol, smg, and screwdriver for weapons.
• One baddy type with custom AI that can climb/jump around the environment.
• A respawning baddy system that keeps the action flowing.

All of that will absolutely be in at release, and most of it is working already. As i said earlier, I am still finalizing some of the models for the weapons, but the coding for them is done already. The map is mostly done, but I may add on to it/change it around once I start really testing this thing.

Things that I'd love to have in the release but may or may not make it in time (they may still make it, but generally I'm not finished with them):

• Buddy AI.
• Two other baddy types; a shotty badguy and a pistol baddy.

Obviously, the Buddy AI was a big part of the game that I wanted from the beginning, and to probably not have it ready for the demo is pretty painful. The thing is though, this whole project has taken a lot longer than I ever wanted it, which is my own fault through a deadly combination of trying to do too much, having real life badness crop up in the middle of the summer and halt all development, and sheer laziness on my part. I am at the point now where I really need to just get this thing out of the door in one form or another. Rest assured, this is still my baby and with just a little bit of positive attention toward the demo from the community I will continue development and absolutely get those features in.

Things to think about for a future release:

• More levels, obviously.
• A shotty weapon for the player.
• A stamina system for the running and jumping.
• Reloading for the weapons.
• Scripted sequences.

Later days.