I discovered today that there's a port for XNA to run on Mono (powered by OpenGL).  I'm not sure how up-to-date the port is (there doesn't seem to be much recent activity in the group discussions), but I may look into this once I pull my spare box out of storage (and load Linux on it).  It's been a few years since I played with Mono and I'm guessing it's much more stable now than when I first toyed with it (back in the days of .Net 1.1).  I'd like the idea of being able to port my games over to Linux and Mac OS X as well.

But it looks to be an encouraging idea of a port!

Also, I ran across this compiler for Lua to Microsoft IL.  It may just solve those problems about using Lua on the XBOX 360.  Again, something to look into and report back on.

Cheers!

Devan

Unit testing can create some problems when working with GUI applications, like an XNA game.  How do you verify that something looks right when you're running automated tests?

I've been working with building a simple game engine (so far I've got sprite rendering, collision testing, quadtree culling, and a Lua console) and I bumped up against the unit test problem.  I'm afraid I attacked it from the wrong direction.  I started with some automated tests, but I started to devolve into using a patchwork system of visual (non-automated) unit testing.  It's my plan this weekend to go about and fix the issues I've encountered.

Lessons learned:

You should generally only visually test (as an independent test) the elements of your application that actually involve drawing.  I failed this by creating a test that simply draws my sprite (a valid use of the test), then creating another that updates the sprite's properties.  Updating properties and other non-visual changes should be tested in automated tests; you'll be much more productive.  The only time you should create a new visual test when you're testing something new about the drawing process.  Assuming your automated tests passed okay (and that you are testing for the right things), your visual tests shouldn't care about whether the same code was done properly, only that the rendering looks okay.

It's just been one of those weeks where you start thinking along one line, get distracted, and before you know it, you're lost in the urban wilderness.  :-P

Cheers!

Devan

I've been studying Lua more in depth lately and I've been turning over a more difficult question in my head:  How can you combine XNA, with it's inherent constrictions due to the XBOX 360, and a scripting language such as Lua?

The problem is that, at runtime, Lua uses JIT compiling of unmanaged C code.  Unmanaged code can not be run on the XBOX 360 alongside XNA.  There is the possibility of using C# scripting; however, the necessary functionality for building the scripts on-the-fly are not included in the version of the .NET Framework running on the XBOX 360.  As described here, it is possible to pre-compile your scripts and load them as an assembly....  But that is not particularly helpful for debugging/development.  Is there a solution to this problem?

I've been tossing the idea around of writing a Lua-like implementation in C# that would not need to be compiled; it would simply be parsed at runtime by an assembly written for such a purpose.  However, there are two main concerns that have leapt out to me so far:

• The obvious, performance issues.  It may be possible to work out a method for this.  I haven't spent the time on this yet, however.
• Functions.  I could use delegates, but I'm not sure yet how to handle the variable number of arguments into a function.

Of course, it may be better just to go with the pre-compiled C# scripts to begin with.  Thoughts?

Cheers!

Devan

I've got the first attempt at a XNA state-machine driven particle system up and running, but it has some issues.  Taking a second look at the way I integrated the particles into the more generic state machine, I'm not happy with my implementation.

I think I'll keep the foundation of my state machine, but re-design the interface with the particle system.  Right now, I'm having some problems differentiating the different states of the independent particles because I built the "current" state into the state machine, rather than into the particles themselves.  Thus, when one particle changes states, they all change states.

This is an easy enough fix, but the way the particle system is tied to the state machine bothers me.  I think I'll use the core state machine as a foundation class (I think I designed it rather well as a generic state machine system), but I'll create an inherited class that implements the particle system specifically.  That part of my design wasn't so clean the first time around - that's what I get for trying to rush and get it done in one sitting!

One problem I ran into with the generic state machine is how to modify settings within the StateObject class that is passed into the StateMachine.  I ended up creating a Hashtable of attributes within the StateObject.  In the State object, an attribute can be set to change and is looked up by its identifier string.  It's a fairly expandable system (attributes can easily be created and modified at will), but I'm not 100% sure that I like it - there is some overhead with looking up into the Hashtable for existing attributes, as well as not providing very elegant ways to process that information.  Time will tell.  I may end up replacing it with a static system within the various inherited implementations of the StateMachine (the ParticleStateMachine, for instance, would know that the Particle objects have an "Age" attribute).  On the other hand, I may decide that I'm adding so much to the Particles that the Hashtable turns out to be handy!  We'll see.

Right now, the basic system looks like this:

StateMachine - Contains the different states, as well as system-wide settings (maximum particles to create, how often to create them, etc. - specific examples for the ParticleStateMachine).
State - Contains processing details about a specific state (changes attributes, performs if less than/greater than checks, tells the StateObject to switch to another state contained in the parent StateMachine, etc.).
StateObject - A generic interface into an object being passed through the StateMachine.  Each inherited implementation of the StateMachine will expand upon this as needed (i.e., the ParticleStateObject will contain an "Age" attribute as mentioned previously).

Knowing that I'm going to be changing the implementation, I'll hold off on posting code till I clean up the system a bit.  I wouldn't want just everyone to see my messy coding! 

Cheers!

Devan

Sitting bored in the Data Platform session of Microsoft's Heroes Happen Here conference, I began formulating how my state machine-driven particle system for XNA is going to be structured.  Here is what I've come up with so far:

The ParticleSystem class:  This class will be the top-level system, containing both the state machine that drives the system, as well as performance optimizations for rendering (under the initial assumption that the particles will be rendered as point sprites).  During creation of the ParticleSystem, a maximum number of particles will be specified and a dynamic vertex buffer will be created to arrange for them.  That's the basic rendering part.  The real joy of the system will be in the state machine.....

Every elementary particle state machine will have three basic states: Creation, Processing, and Death.  Every pass through an Update, the particle system will make each particle start at it's current state and run through all the states it possibly can until it is not directed to process another state.  At this point, it stops being processed until the next pass, at which point it starts back at the top of the last state it had entered.  To make this more clear, I'll demonstrate with some pseudocode how the different states work:

Creation:
  - Create the particle.
  - Go to the Process state (and continue processing during this pass).

Process:
  - Check if the particle has reached it's age limit:
       - If so, go to the Death state (and continue processing during this pass).
  - If processing gets this far, the particle's still alive and may perform additional manipulation.  Once it's out of actions to perform, it will stop being processed for this pass and the next pass will start at the top of this state.

Death:
  - Remove the particle (and stops processing).

I'll start pounding out a system for this over the weekend.  I may forgo the point sprites for now in favor of just a quick and dirty normal sprite rendering centered at the particle's location until I get the state machine working.

Cheers!

Devan

(I need to get in the habit of posting when I don't have code to share.)

Something I've wanted to do for a while is develop a really flexible and highly configurable particle system for XNA.  I've seen some solutions (samples, really) that are rather hacked or not very extensible.  Microsoft XNA Unleashed had a solution that I thought was decently constructed and easy to use with small projects, but was still fairly constrictive for what I'd like to see.  Maybe I've just been pampered....

Several years ago, I ran across the Particle Flow system in 3ds MAX.  It is an incredibly powerful system.  Using a state machine driven system, it provides a drag-and-drop view for designing systems.  Modifiers such as rotation and scale can be added at different states, if/else conditionals can be added for branching, new spawning/death events can be added at will, and even collision checks against objects in the 3ds scene.

So, I'm going to start designing a particle system similar to Particle Flow that can be used with XNA and I'll be detailing my progress right here in my blog.  I think to start with, I'll break the system down into these parts:

• The system:
  
• States
  
• Rules
• Particles

The state machine system will be broken into states (duh).  Each state will hold a list of rules, which will consist of different attributes (rotation, scale, position), actions (spawn, die), and hooks (attachments to [update: point] sprites) to begin with.  Tentatively, conditionals will be added eventually, as will such things as AI behaviors, attaching 3D objects, and bounding volume collision checks.  The particles will be the physical objects in the system.  Each time a particle is created, it will start at the top of the state machine specified during its creation.  Some particles may spawned by other particles and may traverse the same state machine or a different one.

That's what I'll start with and we'll see where this takes me!  Leave me a comment if you have a suggestion or questions.

[Update:] I think I'll have a top-level particle system that will hold all of the particles, as well as handle their updating and rendering through the use of dynamic vertex buffers, as done in the Creators Club sample.

Cheers!

Devan

I’ve made an extension to the Console component sample posted on Ziggyware. It provides access to a Lua virtual machine through the console. I believe many of you budding (or experienced) XNA developers out there may find of use.

Well, here we go again.

I suppose I ought to introduce myself.  My name is Devan Stormont and I am a firmware engineer and a game developer/hobbyist.  This blog is intended to be primarily a source for me to discuss new developments in Microsoft's XNA game development framework for Windows and the XBOX 360, as well as to post tutorials as time permits.

Hopefully, I won't forget my pasword again!

Cheers!

Devan Stormont