What is XSE?

The XNA Shooter Engine, or XSE for short, is a set of libraries and tools aiding in creating FPS-style games using the XNA Framework. It is being created for an as-of-yet unannounced XNA title.

What's In XSE?

XSE Game Development Kit
The GDK consists of our own home-grown, scratch-made tools used for building content for the engine. The centerpiece of the toolkit is XSE GameStudio (name likely to change), an application for handling virtually everything the engine can import, from object libraries to map files. Also included is Model Viewer, a tool for previewing and optimizing your shaders to work with your object without having to build and test each version in-game.

XSE Game Engine
The engine itself is largely incomplete at this point, but the framework structure is decided and we're confident it'll work brilliantly. The engine development is driven by the development of the tools, allowing us to figure out what works and what doesn't in our own home-grown testing tools before committing it to the engine. This development strategy prevents the engine from becoming too fragmented with bits of code from many different revisions of features.

Open-Source Goodness
A lot of commonly-asked questions about XNA are solved in our code. Things like model manipulation, shaders, lights and using XNA outside of game contexts are all used by the engine or its tools. Not only is our source freely available, we'll be creating a sort of FAQ-style mini-book that hopefully answers so many of these commonly-asked questions. Obviously, sites like Riemers definitely help, but I feel they aren't written as a one-question-solution; they're written as part of an entire project, which can make picking out the relevant pieces of information fairly difficult.

News

July 19, 2010

Apologies for the lack of updates recently. We've had some setbacks and have missed a few goals we had set for ourselves. That said, here's what's new:

The GDK
Our big, ambitious GDK tool has taken a back seat for now so we can get the engine up to a feature-complete version sooner. In changes I'll describe later, the tool we had planned may even become unnecessary.

Effect Class Generator
One of the tools that have been whipped up is a cool little utility for pre-compiling shaders and generating classes for them. The reason we needed to do that was because we're hoping to keep content files from having to float around with our library. What the tool does is allow you to compile a shader and through various options, output a strongly-typed C# representation of that class. If you choose to have the compiled shader output as a separate class instead of a binary file you would have to add to your project resources, everything is pre-wired up and ready to drag-and-drop into your project.

It's not XSE-specific and will work with just the XNA framework itself. What it does is create a class of a specified name that inherits from XNA's Effect class. It will then generate the proper constructors based on what options you've selected. Effect parameters are read from the shader and properly-typed properties along with matching backing fields are created. A method for automatically initializing the properties is generated and called from the constructor.

What this allows you to do is set parameters and techniques just as you would any other class, much like XNA's BasicEffect class. This provides several advantages:
  • You don't have to repeatedly type out effect.Paramters"name".SetValue(val) anymore
  • Removes risk of misspelling or not knowing the parameter's proper name
  • Strangely-named parameters like g_WorldIT are easily changed into dev-friendly names like WorldInverseTranspose without modifying the shader
  • Classes using the effects won't need to require a ContentManager object to manually load each effect
  • Allows you to set up custom logic not available in HLSL like checking support in the GraphicsDevice or setting default values based on other data

It's saved us loads of repetitive work. Once I fix some bugs in it, I'll throw it up for mass consumption.

The Engine
We're working very hard to finish our rendering engine as that will be the largest and hardest piece to implement. The rendering engine is of the deferred shading persuasion and supports HDR, bloom, screen-space ambient occlusion, and VSM shadow mapping, along with a complete post-processing pipeline.

Earlier when I mentioned the GDK was going on the backburner, I said it might not be necessary anymore. We've expanded the design of our content pipeline to allow a much higher amount of data to be passed between artist and programmer via opaque data. This move made sense as it removed the burden of having to create our own world editor and allowed us to set properties like lights, spawn points, etc. all from within our tool of choice, Autodesk's 3ds Max 2011. I'm assuming other programs allow similar functionality. If not, you can always easily create your own pre-processor to inject the data you need for your game.

We should have our rendering engine feature-complete very soon here and from that point it should be much smoother we're hoping. Once we get some higher-quality artwork pumped into our game, I'll put up some screenshots to show off the gorgeous glory that is our rendering engine.

-Eric

Last edited Jul 19, 2010 at 4:23 PM by ricodued, version 20