Rick Hoskinson's Blog

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.

Hello, for anyone looking at my recent posts on game design, there will be a bit of a delay before the next one.  It has nothing to do with the content -- I'm going through a bit of a family emergency right now.  My polan was to post a discussion Domain Interaction up sometime in April.  The interactions are the part of the model that makes predictions, making them one of the most important aspects of the model.  However, this is the most volitile and (currently) subjective area, so I might go with Standard Domains first, which are easier to scope, but are largely a toolset for quickly describing systems in your game.

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.

 

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.

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.

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.

Apologies for the lack of updates, it's been a crazy month.  Even with all the madness of work, I have had some spare time to work on my private game project.  I've been using this to keep my game-dev/c# skills sharp as well as to "feel the pain" of my customers.  Though to be perfectly honest, there's been very little painful about my development experience so far.  Working on this game has taken over my usual leisure time.  Not necessarily a bad thing, as I've been burning out on my usual MMO time-sinks.

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

Despite my lack of posting, work on my ambient game continues.  I'm working 60 to 90 hour weeks these days so I don't have a lot of free time for things like blogging, games, or sleep.  Anyways, here's an updated screenshot from the game, complete with my first pass at rendering "ghosts".  I say first pass in a very literal sense, as they are being rendered to an accumulation buffer which I haven't recombined into the scene yet.  I'm still dealing with all manner of depth buffer issues, ranging from precision & performance to simple order of operations.   

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

 

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.

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.

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.

 

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:

I see this coming up on the XNA forums a lot, and I wanted to fire out my recommendation.  First, I find enabling unmanaged debug spew in VS is pretty slow.  I'm also a multi-mon fanatic, trying to chain as many monitors as I can to a single PC.  So I like to have some flexibility with window placement and memory.

I highly recommend the Sysinternals tool DebugView, which pretty much does everything I could ever want in a debug viewer.  I find unmanaged spew to be essential for anything going though Direct3D, so a good debug viewer is essential.  I also use System.Diagnostics.Debug for runtime spew when I'm testing bits to give me text feedback without have to draw stuff on my screen or use a command window for console.write spew.

The beta version of the MDX 1.1 to XNA Framework Migration Guide is now available.  Sorry in advance about the formatting, after all, this is beta!  I wanted to get something into our existing MDX developers' hands so they could rapidly move thier code to XNA and start providing us feedback.

Any feedback you have on the migration guide is also appreciated. If there's anything missing that you'd like to see in a future version of the document, please file bugs via the Microsoft Connect service.

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.