Rick Hoskinson's Blog : XNA Game Studio

Shader Series: Which Direction?

RickHos — Wed, 20 Aug 2008 00:15:00 GMT

I’ve started work again on the Shader Series of XNA Creators Club samples. I left off with Shader Series 4: Materials and Lights. I’m working on the documentation for my next sample now, in which I show multiple pass (additive) opaque lighting. It’s another atomic technique in the arsenal of what every graphics programmer should know, and the visual results are an excellent payoff for a small amount of work.

As an aside, this isn’t really my day job anymore. Though I can contribute to the XNA Creators Club in a professional capacity, my function at Microsoft now operates primarily on the online space. Writing samples is a way for me to keep my managed development skills sharp.

The main problem I have with the sample is that it doesn’t really introduce anything new into shader programming – it’s just a way to take advantage of what a shader developer would already know from previous samples.

As I move into progressively more advanced shader techniques, it becomes harder to construct the lessons as serial teachings. I think I can do it a couple more times, but then the topics will begin to resemble the articles in GPU gems: a set of tools, not an end-to-end story.

I’ve focused on lighting opaque geometry as a vehicle for teaching HLSL. I still have a couple tricks up my sleeve here. I would love to do a full-on Bilinear Reflectance Distribution Function (BRDF) sample. I could show off a variety of BRDFs that are effective replacements to Phong reflectance. I might also be tempted into implementing the BTDF I implemented for River’s End to simulate light transfer through porous or fibrous material. I’d really like to put that in whitepaper form first though, so it likely won’t make the cut.

My primary goal with the shader series is to get people to a place where they feel comfortable cracking open GPU Gems or Shader X and implementing the techniques therein. My secondary goal is to pick some of those excellent techniques and apply them in the context of the hobbyist developer. Modern GPUs are ridiculously powerful, but the level of 3D art assets typically available to an independant developer undercuts that potential by a huge amount. You can still make great looking games, but this requires a creative approach to the application of rendering techniques and asset usage. I like to say that I "throw math at" my game until it starts to look good.

After that though, I can go a lot of places. Here are some of the ideas I’ve been throwing around.

· Static mesh ambient occlusion generation and implementation. This is a science fair project, but if I could nail it, the benefits would be dramatic. Imagine being able to just drop in a content processor and automatically add an ambient occlusion map (or vertex data) with near zero dev cost. Of course, your build times would take a heck of a beating.

· Spherical harmonic lighting. This advanced lighting mechanism makes for some incredible lighting environments. However, there is some CPU cost when certain scene parameters are changed. I’m not convinced this is a good fit for hobbyist XNA Game Studio games yet. It doesn’t have the “drop-in” appeal of some of the other techniques.

Subject Change

I considered doing an E/N post about where I’ve been for the last five months, but thought better of it. Also, my apologies to folks posting comments – I get so much spam from this blog I pretty much can’t keep up.

With the recent announcement that game creators will be selling their titles via XNA Community Games, it puts me in an awkward position talking about game design practices. I’ve been vetting my model on a title that I plan to provide through the service, but talking about it here might be a conflict of interest. My choices are to not talk about my real-world findings at all, or to move to a different blog system. I’m not excited about either prospect.

Domain Model for Game Design Part 2

RickHos — Fri, 14 Mar 2008 21:29:00 GMT

Yesterday I listed the domains for the design model; today I'll list what they're used for. In later updates I'll post more specifics on these uses, but for now, I’d just like to scope things. This list is not final, and there are probably additions as I discover things with the case studies.

What the domain model does:

· Identify weak and strong interactions between domains for a particular game. These interaction values act as a risk assessment metric and general iteration focus.

· Identify a set of standard interchangeable standard domains for games. This will help speed up the design process by creating standard placeholders that are easily understood.

· Identify low-level constraints on domains due to fiscal, time, and resource constraints.

· Identify logical divisions of human resources, design efforts, and specification. Combined with the interactions and constraints, interaction between members of large teams can be safely and efficiently structured.

· It is a descriptive terms in a design document, to clarify concepts while they are still on paper, or being discussed at meetings.

· They are useful as categories for comparing two or more games. This, in turn, can be used to evaluate the familiarity or differentiation offered by a title in development.

· They can be used for structuring pitch sheets or short specs. They provide a way to instantly describe the efficacy/feasibility of a design by matching with criteria from known other games.

· They are a framework for designers who have basic game concepts, but need to flesh it out to discover any flaws early in the process.

What it doesn’t do:

· Is not appropriate for structuring large design docs at this time. More research needs to go into this subject. The reason is, a design doc will tend to discuss the flow of a game, and lay out the individual elements as they come up. This is very useful when designing a game, as it simplifies the design process by utilizing a chronology (timeline) or hierarchy (flowcharts).

· Does not provide rules, mechanics, dials, or other “automatic” mechanisms to tune games in progress.

Domain Model for Game Design Part 1

RickHos — Thu, 13 Mar 2008 20:47:00 GMT

I’m treating the Domain Model for Game Design like an unproven scientific theory. The Academy of Arts and Sciences states that a theory must have two properties:

1. It must be an explanation of a feature supported by experimentation

2. It must be able to make predictions

In this case, my “experiments” are the case studies I’m putting together and the new game I am developing. To support my model, these case studies should result in prescriptive insight into how these games could be improved, what features would be popular, and what features could be cut. Of course, most of these things could be determined intuitively once a game is released. The critical reaction to full game becomes the control case for the case study. The “experimental results” are the issues rapidly identified by domain interactions, which are identifiable during development.

I was originally going to introduce the domain model by talking about the benefits, but I’m not really trying to justify the model yet. It’s too raw – I’d rather be generating discussion and criticism than trying to defend an indefensible position.

Instead I’m going to present the 9 (or 8, depending on how you see it) domains that I’ve identified. In this post, I won’t be going into the justifications for them – there’s plenty of time for that. Instead, I’ll present the summarized domains within their two categories.

Originally, there were 5 domains. At this time the domain model encompasses 9 discrete domains. Each one has been scoped to make it’s interactions with other domains as useful as possible. The glue between the domains (which I call weak and strong interactions) are were the predictive qualities of the model come into play.

Domains are divided into two categories – Direct domains and Sympathetic domains. The Direct domains are easiest to explain – these are the elements of the game over which a developer has direct control. The Sympathetic domains are those which anticipate or attempt to understand a player’s experiences with the game.

The Domains

Direct Domains

1. Response

a. This domain covers the display of game state, UI, and instantaneous reactions to player inputs.

2. Presentation

a. This domain includes aesthetic elements such as artwork, narrative, audio, and stylistic elements.

3. Achievement

a. This domain deals with win states, scores, progression, and all kinds of rewards that reinforce the rest of the game.

4. Simulation

a. This domain describes the game’s interactions with its own internal state. It covers AI, game world simulation, and other updates that are not directly tied to player inputs.

5. External

a. This domain covers everything that lives outside of the game. This could include packaging, manuals, web portals, advertising, distribution, and hype.

Mixed Domains

6. Physical

a. This domain covers the control surfaces, displays, peripherals, and general ergonomics of gameplay. This domain is considered mixed, as it is the actual interface between the developer’s game and the player’s body.

Sympathetic Domains

7. Skill

a. This domain deals with the rapidly changing skills that a player develops while playing a game. This domain influences how a player learns and hones short term (<30 sec) reactions to in-game situations at a reactive or instinctual level.

8. Management

a. This domain covers the expectation of player strategy. It includes conscious player contributions such as resource management, approach, and goal setting.

9. Immersion

a. This domain deals with a player’s emotional connection and concentration while playing a game. It is the domain used to manipulate the player into internalizing mechanics presented in other domains.

That’s still a somewhat raw list, and I expect it to change as I run more case studies. These domains do not imply any sort of hierarchy. There’s no strict structure that indicates that any given domain is deferential to another domain. That is purely something that would be scoped by a particular game.

In my next post, I’ll talk about the interaction model for the domains and start to explore the prescriptive properties of understanding weak and strong interactions. I’ll follow with some uses for the domain model, and then I’ll get to the meat of this topic: the case studies.

Back on the Blog

RickHos — Wed, 12 Mar 2008 03:11:00 GMT

River’s End is mostly complete. It’s not much of a game, but it is a very relaxing experience. It just needs some polish, a few new graphics systems, and a little more content and it’ll be ready to go. However, I don’t know yet how or if I can distribute it, so understandably, my enthusiasm for the project has waned somewhat.

To avoid the issue for my next project, my focus will be on game design. And I’d like to be inclusive though my blog or through the XNA.com forums on how I reach my design decisions – both technical and creative.

River’s End was a superb way for me to familiarize myself with the shortcomings of a tech-driven design. As I began to ramp up to my next project, I was very near the same mistake, but I was fortunate enough to have colleagues and friends who could comment on early problems and identify another possible false start.

So I began to study the subject of general game design. Like any good research topic, trying to assimilate the greater body of game studies is truly epic amounts of work. One of the major problems is a seeming lack of clear goals, or at least, shared goals on the part of the leading academics. Game Theory seems to me a strictly academic pursuit, but it contains nuggets of wisdom that transcend its specific focus. Game Studies appear to focus on the impact or rationalization of games.

On the other side of the Game Design coin is the practitioner’s approach. This is the domain of designers like Noah Falstein and Marc LeBlanc. There are the contributors to books like Game Design Perspectives and Game Design Anthology. Some of these are unyielding rules about what makes a game enjoyable. One extreme example of these approaches is the 400 Project. Others are general guidelines to encourage new thinking about game design.

There’s more too – far more. There are almost as many ways of talking about game design as there are game designers.

I’ve thought critically about aspects of the problem, and like so many sideliners before me, I have come up with my own addition to this theoretical stew, which I will call a Formal Game Design Model for lack of a more discrete term. My fundamental goal is to make something that makes my games more fun. I refined the difficult tasks to three goals for a design model. My goals for a model are to:

Refine game designs by identifying, isolating, and surfacing all specific aspects of a game’s end-to-end experience.

Evaluate game designs by understanding the interplay of game systems and their impact on the overall experience.

Inspire new features or game elements to establish goals earlier in the process.

The model I developed is called “A Domain Model for Game Design” or Domain Model for short. I have identified 8 domains that are common to all computer and video games, and even many board and card games. Each domain is describes an aspect of a game that ultimately influences a player’s enjoyment of the game. The essential quality though is that the model’s static component is the domains themselves. The dynamic part is the interactions between domains, which, I’m finding are highly regular.

There are lots of ways to use the model, but let me give a quick example. The Domain Model includes a domain called “Response” which deals with the display of information to the player that informs their choices. The Response domain interacts strongly with the “Presentation” domain, which covers aesthetics and art design for a game. Here we can begin to identify areas that are contentious in the design of your game. Following this example, you might identify aspects of the in-game artwork that makes the UI in the response domain untenable.

This probably sounds like common sense, and much of it is. The formalism may seem unnecessary and that it may stifle creativity. However, I don’t see the model as a template or specification mechanism for game design. I see it as a tool for doing the three things I identified above.

Now, those of you who have read up on this subject may have already seen a striking similarity between this model and the MDA approach by Hunicke, LeBlanc, and Zubek. I developed the groundwork and the core principles of my model before ever reading about MDA, and I was both surprised and pleased that my system mirrored so many of ideas presented in that paper. Of particular interest are the interactions between Mechanics, Dynamics, and Aesthetics as the essential part of the iterative processes described by the system. However, my focus is on more discrete “parts” of a game, and an idea of strong and weak interactions between domains. Domain Model’s goals are similar, but I’ve chosen a slightly different attack vector.

I can’t presume to have the authoritative background any of the authors of MDA have, and as such, I would never say that it’s right for everyone. I plan to offer it “as-is”, another tool for a designer’s toolkit, and nothing more. I’ll be vetting this model with my next game project, and I plan to provide case studies that show how several different games can be evaluated with the model. I’m a technology worker, not a professional designer with decades of experience, so everything I write must be approached as such.

In the coming months I plan to talk more about the model as I refine the concepts. I’d like to present it as a paper initially. This is largely something I’m working on for my own hobby game projects, but in the off chance that anybody may find this useful, I’d like it to be generally available. Perhaps someone out there struggling with a game that just isn’t fun might find ways to improve their title using the little bit of structure I’ll provide in the Domain Model.

GameFest 2007: Mission Complete

RickHos — Thu, 16 Aug 2007 01:53:00 GMT

I’m back from GameFest 2007 and I can start to take back parts of my life. The last 3 months have possibly been the busiest and most stressful of my entire life. The rewards have been incredible though, and I’m still glowing about the fantastic reception to the XNA Game Studio track.

For those of you unfamiliar with the GameFest conference, the details can be found at http://www.xnagamefest.com/ . True to the XNA branding of all Microsoft gaming development, XNA GameFest is primarily an event for seasoned industry professionals that want to get the most out of Microsoft platforms. I like to think of it as a “Game Programming Gems for Microsoft Platforms”.

I volunteered to be the XNA Game Studio content coordinator for GameFest 2007. As a result I’ve managed to add about 50% more responsibilities to my usual engineering support workload. Couple that with the unprecedented lineup of holiday Windows and Xbox 360 titles, and I haven’t had a lot of “outside time” this summer. I managed to get Shader Series 4 our the door as well, which is an exciting landmark in a series of whitepapers and samples I've wanted to do since last summer. Back then the CGP team was working hard to get http://creators.xna.com off the ground and there were no Game Studio samples at all. The XNA CGP team has come a long way, and they have produced a marvelous community developer portal.

I have probably 50 man-hours of post-GameFest responsibilities, but these will be distributed over the next few weeks. I should be getting back to a normal schedule just in time for the Seattle Rainy Season. And that means I’ll be back to working on my leasure game projects.

River’s End has been stalled all summer for the above reasons. During that time I’ve also managed to shift my support responsibilities so that I’m now a primary source for Xbox 360 GPU support. I’ve learned an incredible amount in a very short time, and I have nothing but new ideas for how to convert River’s End from a pretty game into a jaw dropping graphics showcase.

Not that I’ve forgotten the gameplay. I’ve been jotting notes about level ideas and new gameplay mechanics all summer. I’ve also taken inspiration from the incredible work done by the top Dream-Build-Play entries which we displayed at GameFest. These games are stunning, and many times they’ve been completed entirely by one talented developer. They’ve given me the confidence to persue very aggressive design goals for my hobby game projects.

I’ve also got some great ideas for more developer education content. Things that have come to mind recently have been about project management and scaling for teams. The upcoming Game Studio 2.0 features should enable some really interesting project management techniques that will make working with artists, managing content builds, and dealing with multiple platform targets into a highly streamlined experience. It’ll take some research though, so I’m going to factor in these techniques into my leisure-time work on River’s End.

Be sure to check out the games at http://www.dreambuildplay.com/main/default.aspx . They’re all awesome in their own way. I probably shouldn’t say this, but my fave was Shuggy. I love 2D gameplay concepts and Shuggy helped convince me that we’ve still only scratched the surface of what great gameplay can be had on a 2D plane.

Lamp Lighting

RickHos — Wed, 04 Apr 2007 23:07:00 GMT

In this update on River's End (previously Rox 3D), I'll be talking about the process by which I arrived at a lighting model for the paper lanterns that feature prominently in my new game.

Early on, I decided I wanted to blur the line between realism and style for this title. Obviously, any game featuring ghosts and river spirits doesn't really necessitate rigid adherence to the laws of physical light, but for the lamps I wanted something both neat-looking and recognizable. I began my research by looking at about 200-300 pictures of Toro Nagashi festivals, and hanging Chochin (paper lanterns). This process took about 2 or 3 hours to find enough subject matter, at which point I brought out the graph paper and started to sketch down notes.

The key elements were:

There is a view-dependant "hotspot" of light where the actual candle or light bulb sits in the lamp. It diffuses across the surface and creates a specular-like highlight.
The “hostspot” falls off quickly relative to the distance between the candle and the paper surface. This means that in a cube with a centered candle, the hotspot effect would be weakest at the corners.
The paper in the lanterns are effectively emissive as well as picking up color from other light sources in the scene. The effect is so subtle though, that without a really bright lightsource, it's almost unnoticeable.
The paper has a very noticeable cloudy texture in some cases. In others it’s an anisotropic effect of fins like accordion blinds. This would require two separate approaches do differentiate those lamps.

This post talks about the shader used for "faceted" lamps, or lamps without curved surfaces.

I had to reduce my observations to equation form. My final lamp shader has variety of uniform data, but initially, the falloff + view dependant relationship of the hotspot was my primary interest.

As we see from this poorly constructed diagram that I made with Paint.Net, there are some obvious needs for uniform data. First we need to consider view and light position, adjusted for world coordinates.

First lets concentrate on light falloff. That can be expressed in terms of the pixel’s distance from the center. Since I’m working in Shader Model 2.0, and I want to get my pixel’s position in world coordinates, I have to pack the information into my vertex shader. In my shader code, that looks like this:

float4 worldPos = mul(float4(input.Pos, 1), world);

worldPos = worldPos / worldPos.w;

output.WorldPos = worldPos;

All I’m doing is transforming the vertex position into world coordinates, dividing out W (since I want coordinates in the form of (x,y,z,1)), and setting it in the output. Now the interpolator does the rest. I’m passing the WorldPos output using the TEXCOORD semantic, so the world space position will be properly represented at the pixel.

Now on to the pixel shader where the real work is being done. The next set of functions are used to calculate a light “intensity” on the paper. This is where the light falloff as a function of distance is represented.

float3 lightDelta = input.WorldPos.xyz - worldLightPos;

float lightIntensity = 1 - (saturate(pow(length(lightDelta), lightPower) * lightBrightness));

The lightPower and lightBrightness parameters give me a means to control the rate of falloff with distance. That way I can turn up the lightPower to get a more focused light, and increase lightBrightness to get a larger hotspot.

Now the last part of equation factors in the view-dependant portion of the lighting function. This function is not really based in reality – there’s no conservation of energy, I’m not calculating a proper light-scattering equation based on the light’s luminosity. This is a very unrealistic function that produces some spectacularly realistic results though, and that’s good enough for my purposes.

float3 worldLightDir = normalize(lightDelta);

float4 paper = tex2D(smp0, input.TexCoord);

float4 color = (dot(input.ViewDir, worldLightDir) * lightIntensity * paper * lightColor)

+ (.5 * lampColor ) * paper;

It’s not pretty, and the (.5 * lampColor * paper) is a contrivance. I’ve built a more “realistic” function to represent the scattered light, but the results have been unsatisfying unless the parameters to the equation are about .5 * lampColor for each pixel anyways. The paper texture I’m using is something I whipped up in Paint.Net using the Clouds and Pencil effects in a matter of about 5 minutes.

And now the proof; without seeing the effect in action, it’s tough to get a good idea of how it looks. I have provided a high-res screenshot though that should give some idea as to how the lighting plays out. I'm only using cubes as I haven't finished the look of the spheroid lamps yet.

Bloom Disabled

Bloom Enabled

I’m very happy with this part of the game's visuals now. The next big visual elements are my particle engine, my sky, and my “fog walls” which I hope to be demonstrating in my next post.

Brief Update on Rox 3D

RickHos — Mon, 19 Mar 2007 23:36:00 GMT

I have a very limited amount of free time these days, so the total time to date working on this project has been less than 25 hours. However, I'm very happy with the results so far, and I'm very excited to get all of the new game mechanics implemented.

First, the nature of the game has changed dramatically. I’ve always been peripherally aware of a Japanese folk ritual that involved floating paper lamps down a body of water. Thanks to Wikipedia as being the no-research gateway to instant information, I was quickly able to figure out the proper name for such a thing:

http://en.wikipedia.org/wiki/Toro_Nagashi

I’m a retired anime fanatic, and I remember always loving the commonly used imagery of paper lamps over water in nonrealistic lighting situations. I also like the concept of the Hitodama, which in some cases has been represented as a sphere of light. All of these things are basic geometries that will allow me to procedurally generate the majority of my resources.

So the new design puts the player in the position of a river spirit who is responsible for blowing out the lamps at the end of a Toro Nagashi ritual. I’m planning to have two pallets of lamps representing “good” and “malevolent” Hitodama that will spawn when their lamp is extinguished. For now, the player has one kind of “attack” which is a breath of wind. You can use this to blow out lamps or blow around ghosts.

The key component to this design is that the challenge of the game is obvious the player. If you don’t blow out any lamps, there’s nothing that can hurt you. In fact, I want to detect when a player goes idle long enough, and go into a screen-saver/attract mode by pleasantly moving the player’s avatar with some AI routines. If you want more challenge, you can blow out 200 random lamps and try to face hundreds of angry ghosts at once. There is no Dues Ex Machina in the difficulty of the game – it is laid bare to the player without any meddling by unseen mechanics.

So I’ve covered graphics and gameplay, but what about audio? Well for me, this is one of the most important points. I’m working out a small score right now of ambient, atmospheric music. It’ll be tough to wrangle the IP for audio without involving experts, so I’ll probably record the sound effects myself. I’m not a great musician, but I have some great gadgets and about 5 years of electronic music production experience.

Finally, I’m almost to a point that the tech issues I’m hitting are genuinely interesting. The big thing lately has been precesion issues in shader code giving me red herrings that end up requiring a ton of instrumentation to track down. Now one thing I was (somewhat stupidly) avoiding was PIX for Windows. Seems it’s ok to dump 12 hours of a weekend into coding, but it’s to much work for me to install the DirectX SDK. Well, lesson learned, and I’m now resolving issues quickly thanks to the fantastic SDK tools.

And now that I’ve done my ramble, I’ll put up a screenshot of where I am as of this writing. There’s a lot of scene elements, game elements, and visual effects to add, but the perspective and scale are near final. Also, I need to come up with a decent name for this game.

Also, the little PIP in the upper left corner is part of my debugging code. Any time I work with rendertargets, I hand their textures to a robust debug library I've been building up for years with managed apps. The rendertarget functionality allows me to bind keys to a PIP view of rendertargets in my scene. In the upper-left corner, you're seeing the reflected geometry for the water layer.

Rox 3D: Game Simulation Design

RickHos — Mon, 05 Mar 2007 12:28:00 GMT

Greetings from GDC! My involvement has been pretty low key so far, so I’ve had a little time to dedicate to my test game. I’m using this game as both a learning experience, and as a test application to try various performance techniques and API features.

The refactoring work on Rox is mostly complete, though I’m still determining how to split up may game logic into internal and external entitiy functionality. External classes in this case can be split into 2 distinct types: those that provide inputs into the entity data and those that strictly read from the entities. The latter type includes the graphics and audio – they are passive elements that shouldn’t inform any aspect of gameplay. When the world is updated events are triggered in the audio engine. When the world update has reached a complete frame, the graphics engine reads the states of the entities and renders them appropriately.

Of course, nothing is quite this easy. First there’s the issue of collision geometry. Up until now, the game engine has retreived a simple collision sphere from the Models loaded from the content manager. Those bounding spheres are then fed back to the game engine and the world has been scaled around the art assets.

There were a couple of ways to go from here. The obvious route was to create a content processor that would normalize the incoming assets into something that made sense in my world coordinates. However, remembering my desire to detach from the SpaceWar assets I have decided to remove all traces of external meshes for now.

My “asteroids” are now procedurally generated spheres. Eventually I’m planning to alter the entire look of the game to turn them into something a little more threatening, but for now the stand-in geometry helps me quickly move into my next phase – the game simulation.

I now have a static Singleton class that is the center point for all game data collaboration. The Game superclass has been pretty much stripped clean, but it will not remain that way; I plan to use the Game class to house my multithreading code. The Singleton class has a public static GameSimulation called “server” that is the centerpoint for all game state and gameplay logic.

I’ve decided not to differentiate between AI, physics, and animation. All of thise kind of “internal” state logic is being handled by functions within the entity classes.

I’ve decided not to use an object hierarchy for my entities for a few reasons. First, I want to use structs for many types of entities to avoid heap garbage and reduce the number of live objects in my game world by storing arrays of value types. Next, I’m planning to have only a few kinds of entities: players, spawners, rox, projectiles, and statics. Each has a fairly different set of priorities and variations in subclasses of object are probably best served using switch statements.

· Statics are elements that don’t move during update such as large immobile obsticles and powerup items.

· Projectiles are entities that share the common property that they have a time-to-death and they all behave the same. There may be more than one projectile, but due to their short lives and volitiliy, I don’t plan for them to share data. This gives me the flexibiliy to heavily optimise this system to support thousands of projectiles simultaniously in game. I found lots of weak, innacurate projectiles to be much more satisfying than solitary, powerful weapons that fire straight forward.

· Rox are the bad guys in the game, and will all share the same class. Their behaviors will vary using switch statements. The Update() part of the entity will call functions that do certain behaviors which can be used in serial to get a desired behavior. For example, an entity that is always attempting to orient towards the player while moving straight forward would appear to chase the player.

· Spawners make roxs. They are very different from other classes as their setup and rox generation code is enormously more complex than their update code, wich will leave them stationary or mobile along a path. The configuration of Spawners and Statics in the game arena determines the content of a “level”.

· Players contain a lot of information relating to UI and other feedback to the player. There is only ever one kind of player for this simple game, so I’m not going to rat hole my game with lots of complex capabilities.

Now that I have a plan, I’ll be busy turning it into an enjoyable game. I’m not messing with graphics or sounds until I have a satisfying game experience. I’m a coder by trade and the only person working on the game. For me, the entity code is still a data-driven part of the design.

An Unimportant Post about Rocks

RickHos — Thu, 01 Mar 2007 08:33:00 GMT

I update this blog so infrequently it’s somewhat embarrassing, but I finally think I have something to talk about. I wanted an informal chronicle of a very simple game I’m working on based off of source and assets from XNA Game Studio Express documentation.

The tale begins about a month ago when David Weller and I were signed up to give some XNA Game Studio Express presentations at an internal event called TechReady. My presentation wasn’t terribly interesting and my review scores certainly reflected that. I learned a lot though and it was a great experience. Dave gave a delightful presentation detailing how to take Tutorial 3 from the XNA documentation and turn it into an Asteroids-clone in an hour. He called the game Rox.

I think I have an old copy on my desktop, but this is kindof what the game looked like at the end of his hour:

…which is pretty damn amazing for a 1 hour presentation.

Dave let me play with his code a bit to add some nifty post processing effects. And I found when I started messing with the original source, I couldn’t stop.

After a suggestion from a coworker that the game should look “more 3D”, I decided to mess around with it to make a little “more game” out of it. After about 6 or 7 hours of scattered tinkering I ended up with something that I was actually enjoying quite a bit.

Rox 3D: I really did have this running before I heard about the 2D Wing Commander.

Believe it or not, it’s pretty much the same game code. The data fields were already there for 3D – I simply added another axis of freedom for the asteroids, a new camera, a cone-firing shotgun-like weapon, and that shield thing. The ship still moves on a 2D plane, but instead of warping from one edge of the play field to the other, everything bounces off of invisible walls now.

The things that took the longest time were just parameter tweaks to the simple shaders I wrote for the shield and post process “bloom”. Everything else is plain old BasicEffect and Space War assets.

I’m now working on Rox 3D 2.0 which starts with a major refactoring. The original game was pretty much packed into a gigantic Game1.cs file with a couple small “entity” classes. I’ve broken up the components into the following engines:

· Audio

· Game Simulation

· Input Handler

· Renderer

I’m planning to keep the entity system and pack the physics and AI work into the game simulation itself. I’m planning to expand this into something a bit more boisterous than a 3D asteroids clone, though I want to keep that concept of a 3D gameworld with 2D planar controls. Here’s what’s going though my mind as the features important to me:

· More procedural content

o Lose the Space Wars assets, try to roll my own textures out of glyphs made in Expressions Beta 1

o Dress up the backdrops and image-space effects

· New lighting model

o I want to use a BRDF like Cook-Torrance for lighting with multiple light sources

o I’m planning to make a hybrid of realistic lighting and fantastic objects

· AI Enemies

o I want stuff that will chase me or shoot at me

· Art style

o Make the game more visually interesting using LOADS of simple particles

o Make all the enemies share a color palette to differentiate stuff that hurts you from stuff that doesn’t hurt you

o Lay on the post processing. I’m barely touching the GPU, and since my geometry, shaders, and textures will be relatively simple, I’m planning for resolvapalooza.

· Tech

o Move to 360 development so I can concentrate on making shaders without taking multiple hardware config into consideration

o In that spirit, split my Update into 4 worker threads and start working on load balancing and multithreaded data management (I’m thinking about double-buffering my Update data)

Right now I’m deep in to refactoring:

Turning 4 code files into a nice organized engine with about 20 code files will keep me busy for a bit. I have GDC coming up and I figure if I have time at night, I’ll work on it then. I’m no longer the raging booze jocky I claim to have been in my youth, so I’ll probably be ducking out early most nights to geek out on source code.

So until next time:

XNA Beta Resources for MDX Developers

RickHos — Wed, 30 Aug 2006 23:05:00 GMT

The XNA Games Studio Express beta is available. It's not a complete representation of the final Games Studio Express functionality, but it's a good way to get acquainted with the style of the thing.

There's a lot to go over, even for Managed DirectX veterans. You'll notice a lot of name changes. You might find that there are a lot of new, unfamiliar technologies available. You will almost certainly find that some familar Types and Members are simply no longer present or have been replaced.

I talk about a lot of this stuff in my upcoming API migration whitepaper. A Beta version should be online soon. When it goes live, it'll be linked from the XNA Developer Portal. That should answer some of your questions when you start porting MDX source to XNA. As soon as it is live, I'll post about it here.

I will be on the forums a lot in the next couple days, collecting your feedback and answering specific questions about the XNA Framework.

Update: I wanted to link to an excellent article on David Weller's blog. How to report XNA Framework bugs to us.

MDX, XNA, My Book, and My Job

RickHos — Thu, 24 Aug 2006 03:51:00 GMT

Well, it's been a while, hasn't it? It's been many moons since my last inane post about problems I had with PC games. Well, I set out many years ago to try to fix some of these issues, and lately I've had some success.

Before I say anything else though, I want to address the topic of my book. Yes, it is on Indefinite Hold, at least with me at the helm. The reasons were many-fold, but the primary reason is that MDX 2.0 never shipped. The API on which I'd based my entire book is deprecated, which obviously made the book somewhat irrelevant. Perhaps someday I'll return to it and finish what I started, using a technology that might be called MDX's Conspicuous Successor.

I am very sorry for everyone who was looking forward to this book. Nobody is as disappointed as I am, but there's really nobody to blame. The Managed Game Development world has take a very radical turn, which is, of course, the XNA Game Studio.

For years I was a test developer working on the original MDX 1.0 and 1.1 products. A few strange years later I took over a new (on Windows) tool called PIX. For those of you unfamiliar with the tool, I highly recommend giving it a whirl if you do any D3D9 development at all. Later I'd take on test for all of PIX for Xbox 360. The combination gave me a great opportunity to learn about the inner workings of Windows graphics and XBox performance. The knowledge domain is immense, and I am a far better graphics developer for the experience.

However, just a few weeks ago, I passed the PIX torch, and I took on a new position. I am now a developer with the Games Technology Group and I'm specializing in the XNA Game Studio products. For me, this is like coming home. This means I'll once again be interacting professionally with the very community we've been building for 5 years with MDX. The XNA Game Studio product is like a dream come true for me. It's the realization of a dream shared by very few back when we started this Managed game programming business. Back then we'd already figured that managed had the potential to be a cross-platform framework for making games on PCs and Consoles. It wasn't until lately that that dream has been realized, and in grand fashion.

I know many of you are excited about the opportunity to create games on your XBox 360. I have friends who went out and bought a 360 in anticipation of the XNA Framework. I can't wait to see what you come up with! As new XNA products and services come online, the potential for new ideas, new talent, and new technology grows exponentially.

These are very exciting times to be a managed developer. With the XNA Cat out of the Bag, I'll be back on my blog, and I'll be surfing the XNA forums on MSDN as much as I can. It's great to be back, and I'll be on the front lines trying to make the XNA developer experience a good one.

Ideal Winforms gameloop: Corrections and Additions

RickHos — Mon, 04 Apr 2005 21:53:00 GMT

I discovered something this weekend while playing around with the game loop I outlined in my post last week. Seems I completely misread the function of SendNotifyMessage and was using it in place of PostMessage. However, if SendNotifyMessage works similarly to SendMessage when used on the same thread, why was I not getting a stack overflow exception like I would have received with SendMessage?

A reader emailed me today that he'd discovered that SendNotifyMessage was in fact causing some recursion, it was inexplicably breaking after 40 calls. This explained a behavior that had caused me to change my game loop in the first place over the weekend. I had noticed that when I enabled V-Sync in my game, my input handling became very granular -- on the order of 2 updates per second. With my refresh rate locked at 85Hz and a 40 frame updates per recursion loop, that would explain exactly the behavior I had observed. Every 40 frames, recursion would break, and my WndProc could handle all the input events that had stacked up.

After getting some feedback on last week's post, I decided it would be safer to have a WM_USER message to handle my painting rather than posting WM_PAINT, which is not a reccomended action in Win32 world. While I hadn't seen any adverse behavior because of it, I hadn't tested it across lots of different environments. Therefore, I chose to err on the side of safety and implemented a somewhat more robust solution. This solution included a counter that prevents my UserPaint messages from "stacking up" in my message queue, and would avoid any complications from posting my own WM_PAINT messages. However, the allocation profiler shows a that the UserPaint method might be delaying OnMouseMove and similar events. This is problematic for those of you wishing to use those events.

Updated

Using PostMessage still didn't work very well with Winform input events, so I'm taking it down. Thanks to feedback from poster Bernhard, he's discovered that this loop seems to work spectacularly, and is totaly compatible with WinForms input handling:

protected override void WndProc(ref Message m)

{

switch (m.Msg)

{

case (int)Win32Message.Paint:

Frame();

break;

default:

base.WndProc(ref m);

break;

}

So it seems that consuming the WM_PAINT message is causing a new WM_PAINT to be thrown by the WinForm despite the styles I've set (ControlStyles.UserPaint and ControlStyles.AllPaintingInWmPaint). Thottled back to an 85Hz refresh rate using VSync, I have verified that input was handled in-time (even better than the first solution). I've got 3 applications I'm working on concurrently to test the solution. The first is a super-lightweight profiling app designed to inject messages and look for allocations. The second is an app with no injections that looks for timing information. The last application is the game engine I'm using for the book. In my game engine and my timing profiler, Bernhard's solution gives similar results to the game loop above. I'm not quite sure why not passing the WM_PAINT message on works so well, but it does. I have to admit, it sounds too good to be true, but it's showing remarkably good behavior in my test applications.

I even tried this new loop in the April SDK and I was pleased with the results. I saw a slight (2 to 5%) improvement in framerates over the existing DoEvents() loop, and a monsterous improvement in number of garbage collections per minute (improved about 90% on a couple samples). So for a gauranteed framerate, it'll be tough to beat this code at the heart of your application. When I get some more time, I'll post a table with statistics on all the techniques I've covered and add new loops as we find them. Thanks again for everyone's feedback!

The ideal System.Windows.Forms 3D Gameloop, Take 15.

RickHos — Thu, 31 Mar 2005 04:11:00 GMT

I thought I'd take a break from my book to talk about some of the trickier points of using System.Windows.Forms for gaming. If you read Tom Millers's blog, you've probably seen him address similar issues in his lengthy discussions on game loops in Managed. The goal is to have no level 2 garbage collections at all during the execution of a real-time action game. That means minimizing ref-type allocations.

First I’ll digress a bit by discussing how I handle input events. Overriding OnMouse- OnKeyboard- functions is often better than attaching event handlers to the mouse events. Currently, I have an InputHandler subsystem that is triggered by these overrides and generates input messages which are added to an input buffer. Attaching input handlers directly to the form-defined events actually incurs a small allocation penalty in the form of enumerators (I assume are used by the event system).

Now for the good stuff: the ideal game loop. As in all frame-based 3D games, we needed a “heartbeat” that works with the windows message pump to process frames. There are two things we took into consideration: processing overhead and memory overhead. Memory overhead is the most devastating, causing the allocations that can lead to generation 2 collections that can cause hiccups that can be measured in tenths of seconds (or deciseconds if you’re a total Latin-masochist). If you’re trying to guarantee 60 frames per second or better, these collections during the normal course of play are unacceptable.

The first loop I used was the old standby loop:

while (Created)

{

Frame();

Application.DoEvents();

}

Sadly, this loop is mortifyingly bad about allocations. To give you an example, if you do nothing else in a frame, this kind of loop can generate over 50MB of garbage in 100000 frames. Under CLR profiler, you’ll see a shark tooth pattern of allocation and collection emerge in the timeline. Lots of collections == bad long-term performance.

There are lots of gameloops I didn’t try because I’ve seen the results firsthand. There’s a PeakMessage loop. There’s a timer-based loop. Tom and I have discussed these options and many others at length, and we have found something we didn’t like in every case.

On a hunch, I decided to place my Frame() function in the WndProc override. This means I am not overriding or hooking any events that might cause allocations in EventArgs. However, triggering this event without blocking other message types was a little trickier. I decided to trigger my frame on WM_PAINT (0x000F) so that I would redraw on any kind of validation as well as my own invalidation.

First, here’s some setup code I put in the constructor so that I would handle all painting:

SetStyle(ControlStyles.UserPaint | ControlStyles.AllPaintingInWmPaint, true);

Next, the ultra-simplistic WndProc override:

protected override void WndProc(ref Message m)

{

if (m.Msg == 0x000F)

{

Frame();

this.Invalidate();

}

else

base.WndProc(ref m);

}

Wow, was this slow. The processing overhead made this technique 3 to 4 times slower than the DoEvents() gameloop. When I pulled things apart in CLR profiler, I discovered correlating numbers of heap creations for InvalidateEventArgs and some sort of synchronization reference type in excess of 3 or 4 MB per 100,000 frames. So this was bad on both fronts.

However, with a simple DllImport, I can do everything I wanted to do via Invalidate() using SendNotifyMessage.

[DllImport("user32.dll")]

public static extern int SendNotifyMessage(IntPtr hWnd, int Msg, IntPtr wParam, IntPtr lParam);

protected override void WndProc(ref Message m)

{

if (m.Msg == 0x000F)

{

Frame();

SendNotifyMessage(this.Handle, 0x000F, IntPtr.Zero, IntPtr.Zero);

}

else

base.WndProc(ref m);

}

I know this seems insanely simple, but of the dozens of ways to make a game loop, this is the best one I’ve ever seen. The timeline graph in CLR profiler was almost perfectly flat – so much so that memory overhead was undetectable over 1,000,000 frames when compared to the Form setup and cleanup code. And processing overhead? This was consistently 10 to 15 times faster than Invalidate() and 3 to 6 times faster than DoEvents() over 100,000 frames.

I now have my “ideal” solution for the game that will appear in my upcoming book. Additionally, I will suggest this for DXMUT in upcoming releases of the DirectX SDK (since it’s kinda my job J). This may not be the perfect solution, but it solves the most significant problems I’ve encountered when developing a gameloop using System.Windows.Forms.

ISBN? Fail!

RickHos — Mon, 17 Jan 2005 22:34:00 GMT

Well, it seems the book that sites like Barnes & Noble have listed under my current ISBN are using information outdated by over a year. I'll take to my publisher ASAP to get that worked out. In the meantime, here's the book info:

Managed DirectX Game Programming

by Rick Hoskinson, Jon Steed, and Wes Greene

SAMS Publishing (Pearson Education)

The reason you may see Tom Miller's name still attached to the ISBN is because he was originally going to write this as a followup to his current series of books. My coauthors and I have taken on the next book in his series on Managed DirectX game development, but we are working under Tom's guidance to live up to the standards he set with his first two books.

Great talk!

RickHos — Fri, 14 Jan 2005 01:10:00 GMT

Thanks to everyone who participated in today's Gaming in .Net developer chat. The transcript of the chat will be posted here:

http://www.msdn.microsoft.com/canada/chats/transcripts/default.aspx

I'd also like to apologize, I don't think I actually ever listed the ISBN of my upcoming book. For those of you looking ahead, it is: [ISBN: 0-672-32695-7].

Work is progressing well on the book. I think I've finally nailed down all the topics that I want to cover, and I'm well into the first couple chapters. If I do my job right, this text will appeal not only to hobbyist developers, but professionals considering .Net as a platform for premium PC games. On the code side of things, our engine is maturing rapidly. I've been able to splice in a couple of physics and AI cores to test performance and "feel" of the systems. I'll be taking a step back soon to update my internal interfaces and make all of the interactions between the various engine components as clean and consistent as possible. This may translate to some "ugly" code in some of the implementation details (input handling comes to mind). I'll do my best to make sure the code is well documented, so that the few rocky parts are throughly explained. The benefit is that consistent interfaces will make the rest of the code much more readable, maintainable, and extensible. This allows the reader to concentrate on the really important information in the text with clear examples in the code.