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 had the opportunity to escape from work today and attend Microsoft's Heroes Happen Here conference in Las Vegas. For those unaware, it is essentially a produce release conference that Microsoft is doing all over the country through the end of June. They are giving away free copies of Windows Server 2008, SQL Server 2008, and Visual Studio 2008, well worth the attendance even without the speaking sessions. However, I did attend both the Data Platform (database-oriented) and Developer sessions. My thoughts: Data Platform session: There was really nothing that wowed me here. Granted, I'm a coder, but I have enough background in database management that it's not all just noise to me. However, I thought the presentation was poorly arranged and delivered. There seemed to be a couple of neat things (Resource Management, for one), but I didn't see many demos. Our speaker's delivery was fairly awful; he was rather weak-voiced, wasn't very exciting to listen to, and would basically stop talking when something didn't go right, which happened often. He appeared to be trying to run too much on his machine at once, which meant that all his demo time was sucked up trying to get the various application windows to switch back and forth. The first two hours had a lot of dead air time that was making me think I should like to go eat a real breakfast rather than listen to him saying things like "it worked last night". Skip this one if you have a chance. Developer session: Blew me away. The speaker, Rob Bagby, was an incredible speaker, keeping the audience riveted, cracking jokes, and flying through code samples so fast it was almost difficult to follow him (almost). He pretty much skipped over the boring marketing-type presentation slides and would go straight to the meat. Plus, he demonstrated many different cool elements of .NET 3.5, including WPF, LINQ, extending Office applications, and web service-driven solutions. He actually tied all of his demos into one continuous demonstration, building upon the system throughout the entire four-hour talk. It was amazing and I learned a lot of new things, plus good reference material for replicating his process (he mentioned a screencast of the talk would be on his blog). Despite his fast talk and fast coding, he did run out of time, provoking a mystery organizer to grab a mic and announce "This is not God, but it is 4:30". Rob wrapped up nicely and left me excited to get home and play with my new software. I highly encourage everyone to attend the Heroes event nearest to them, for the software, and for the Developer talk if possible. 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 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.
A few years ago, I came across this excellent article, written by Martin Echenique and hosted on GameDev.net. It discusses integrating Lua scripting into .NET projects by assigning custom attributes. Using reflection, these custom attributes can be examined at run-time, allowing Lua functions to be loaded into the virtual machine dynamically. I have taken Matin's project and modified it somewhat. First, I added the capability to sub-class Lua packages, allowing packages to contain other packages. Second, I have made the Lua virtual machine (VM) non-static. This was done for two reasons. First, I was having issues with exceptions being thrown due to reloading objects multiple times into the VM. This is caused by trying to register any functions/packages with a name that has already been registered. This is still an outstanding issue to be corrected in a future version, but is avoidable if you only load the functions/packages when you create the VM, then destroy the VM when you are finished with it, so it gets re-built the next time you run it. Not the most elegant solution, but it has served my needs so far and I haven't gotten around to fixing this yet. The second reason is that by creating separate virtual machines, you can restrict different security access in your Lua functions. For instance, you can have a public Lua VM that is available to end users of your game/application to modify interfaces or generate batch scripts. In addition, you could have a separate administrator VM that allows an admin to make network-wide changes to everyone's application, or to provide game masters with the ability to change change events, spawn new creatures, and fix bugged characters at run-time in your MMORPG. These libraries are required to build the revised LuaNetInterface (LNI) project and must be locally available to any projects that use LNI. They do not need to be referenced by any libraries other than LNI itself, but they do need to be copied into your executable's local directory. LuaLibraries_1.0.0.zip (652.09 KB)These libraries come from the official Lua and LuaNet releases at http://luabinaries.luaforge.net/ and http://luaforge.net/projects/luainterface, respectively. Here is the code for the revised LuaNetInterface project. Reference luaXX.dll and LuaInterface.dll from the previous .zip into your build. LuaNetInterface_0.1.0.zip (11.64 KB)Cheers! Devan Stormont -- [UPDATE] The files for this project have been added to Codeplex. They can be accessed here: http://www.codeplex.com/luanetinterface/. Future revisions to the project can be found there.
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
|