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.

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.

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.

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.

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.

Most of the changes I've been making have been in the interest of preparing for a major content update.  I have some final graphics features to add before I'm ready to begin adding levels to the game.  Then it's content time -- I've got 25 levels specified and I'm shooting for 100 levels in the final game.  Why so many?  Well for one, they're pretty easy to develop now -- they're written entirely in C# similar to a script.  I've fleshed out a huge number of helper functions and classes turning c# into an effective design language for making levels.  I have a few more features before my Content Bash where several levels will be added and the game prepared for play testing.

Gameplay concepts have solidified nicely.  I'm moving away from an ambient game to more of a puzzle game format.  Each level will have a objectives which the player must discover through a combination of trial-and-error and visual cues.  The visual cues are intentionally elaborate, designed to inform the player using a "warmer/colder" heuristic.

The game itself features paper lanterns floating down a river.  You play the part of a river spirit that must extinguish these lamps with its breath, releasing many flavors of "ghosts".  Some ghosts are simply harmful.  They'll swim through the sky and attack you if you get close enough.  Other ghosts have more complex functions, such as seeking out other ghosts or altering your abilities when "caught".  Your inputs are your breath, your movement controls, and a simplistic "action" button that is context sensitive in each level.

 Let me give you an example of some levels (SPOILERS!):

Level 1: Tutorial  --  The first level is a simple introduction to the controls.  There are several colors and shapes of lamps floating about.  One of them stands out from the rest and will spawn helpful ghosts that will seek you out and help you progress toward your goal.  All other lamps will spawn evil ghosts that will rapidly eat up your health if you get too close.

Level 9: Sea of Light  --  This level spawns one color of lamp though it will spawn one of two kind of ghost.  The first will slow you down and moves randomly.  The other is a slow moving but dangerous ghost that can destroy you if 10 or so catch you.  A visual cue will get more intense as you spawn each ghost.  It's a hint to let you know that the goal is to spawn as many ghosts as possible while never stopping.  The key is speed -- once a certain number of ghosts are spawned (currently the number is 250), you win the level.

Level 5: The Display  --  And easy level with a cool visual effect.  There are three spatial "regions" of lamps.  The first two spawn harmless "firework" ghosts that lazily wander around the river.  The center line of lamps spawns "hunter" ghosts, which chase down other ghosts.  When you spawn a hunter and there are unexploded firework ghosts about, they chase down a firework ghost and cause a firework-like explosion!  The goal is to cause a huge fireworks display to move on.

The total time spent in May has been about 65 hours.

Features added in May

• Menu & Text System
• New Level loading & scripting system
• Graphics
• Area Fog
• Improved Water with Fresnel
• Local light sources
• River Bed
• Ghost Effect (image space accumulation with blur and falloff, gives the ghosts a spooky "tracer" effect)
• Breath distortion effect
• Transition effects
• Skybox improvements
• First-pass batching improvements
• Alpha and rendertarget re-ordering to support necessary graphics effects
• All-new audio engine & first music & ambient tracks laid down

Features to add before Content Bash

• "Light Globe" progress heuristic  (est. 2 hours)
• "St. Elmo's Fire" progress heuristic (est. 6 hours)
• Transition Engine (est. 6 hours)
• Input Engine Revamp (est. 4 hours)
• Improved Chase Camera (est. 2 hours)
• Force Feedback (est. 1 hours)
• New Player Geometry, Lamp Geometry, & additional Lamp shaders (est. 25 hours)
• Level-Dependant graphics settings plumbing (est. 4 hours)
• Particle Engine (est. 8 hours, borrowing from creators.XNA.com GPU particle sample)

That should keep me busy for the next month or two.  I only want to work on this at night or on rainy days, so weather and work will determine my schedule.  Now I leave you with a couple of screenshots taken in game just today.

Full-Size BMP

Full Size Image 1

Full Size Image 2

So my remaining graphics dev work items are:

• New Bloom Shaders
• Corona Post process effect
• Accumulator add-in
• Final Skydome with clouds and moon
• Arena border clouds & fog
• Particle Effects Engine
• HDR/tone-mapping investigation
• Local light
• Additional Lamp Geometry and lighting shaders
• Text effects engine

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.