Friday 4:59pm

This is my first Global Game Jam. Super excited. So I’m going to liveblog it. I’ll be working on a MacBook, so I decided to port the essentials of my XNA component entity system over to MonoGame. Here’s what I got so far!

Breathtaking, I know.

Saturday 12:20am

Opening meeting was awesome. Heard some fantastic keynotes from fantastic people. We got to hear some great insight from Ian Schreiber before starting (I’m at the Ohio State jam). The theme has been given to everyone by now, so I’ll go ahead and say that the theme is this:

We heard a lot of great ideas that seem quite achievable. I think we’ll see some great things come out of this jam. I had an idea to do a prison game where the goal is to escape and every room is the same, and it turns out the prison is infinite and there’s no way to escape. Pretty lame idea, but one of the few artists expressed interest and joined my group.

We brainstormed for a while and came up with some interesting ideas. Most interesting was an idea to make the game a bit like Shutter Island. The player begins by strangling a prison guard until he passes out. As he goes through the prison, he finds clues that suggest things are not as they seem. Eventually he discovers that he’s actually a patient at a mental insitution, and all he has to do to escape is talk to the guard at the beginning.

Interesting idea, but not very related to the theme, and probably out of scope of the game jam. Then suddenly my partner had a great idea that’s very scalable. It will work with just the basic gameplay elements, but could eventually be expanded to a full-blown title. I won’t say too much about it yet, but it takes the theme very literally.

My partner and I got along so well that we actually grabbed some food and talked for over an hour and a half. So not the best start as far as getting work done, but honestly the main reason I wanted to do this game jam was to connect with people, and so far that’s gone great.

Now we’ve gone our separate ways to work on our individual areas. I’ll be wrestling with MonoGame and Box2D, and he’ll be working on some of the art. Tomorrow we have a room in the Ohio Union from 9:00am to 1:00am, and I think it’s gonna be a great day! I’m very excited about our game design.

In other news, apparently MonoGame has XACT support in the works… which might have far-reaching consequences for Project Lemma. But that’s for another time! For now I have to get to work.

Saturday 2:40am

Box2D.XNA is compiling and I have a sprite displaying. MonoGame is working pretty well. Taking a break from coding to post this masterpiece giving a peek of the final gameplay:

Basically, it’s a giant snake tearing through a skyscraper. It lengthens as it eats people. Your goal is to survive and direct the snake by opening doors, building obstacles, etc. Eventually the snake gets long enough that you can trick it into eating its own tail, and then you win!

Saturday 5:03am

Bed time. Got Box2D.XNA working and figured out the SpriteBatch weirdities.

Saturday 12:55pm

We started around 9:00am today. We have some artwork in progress (although not in-game yet), and a pretty decent snake. I’m planning on implementing all the game logic with Box2D sensors sized automatically to our artwork. Here’s a screenshot.

Saturday 7:49pm

Hit some frustrating bugs. I was pretty grumpy before I got some Chipotle in me. On the plus side:

• The snake’s basic AI is done.
• Stairways are basically implemented.
• The game has been successfully tested on Mac and PC.
• We’ve got some nifty art now.
• The project is officially entitled “Snakes in a Tower”. Yep.

Here’s a screenshot:

Saturday 9:32pm

Things are finally shaping up! I think I’ve discovered a fascinating gameplay element. Since the snake gets longer by eating victims, the player has an incentive to feed them to the snake. Originally we were going to have the victims randomly run out of office doors, but now I think it would be better if they only come out when the player actively opens the door. Man, this is going to be a morbid game.

Sunday 1:24am

Calling it a night. We added the innocent victims AKA python food. When you open an office door they literally explode outward and basically run around like headless chickens. They also have the ability to traverse stairways, resulting in a lot of random door slamming. The victims also tend to stack up and fall to their death in the elevator shafts. All in all, it’s enormously entertaining.

Also, if you leave a door open to a stairwell, the snake will always take it, smashing the staircase and emerging enthusiastically on the other side. Soon the player will be able to repair the staircases so he and the victims can use them again.

Here’s a screenshot of the whole fiasco.

Tomorrow I’ll finish up the repair functionality, add sounds, a life counter, and polish things like a basic main menu and game over screen. If we have time we’ll work on a pistol to fight off enraged PETA supporters.

Also, check out this fantastic logo courtesy of our artist!

Sunday 9:10pm

Whoops, I sort of went dark today. Busy polishing!

Conclusion

Global Game Jam 2012 has come to a successful end! All the games presented at our local event were fully functional and quite a bit of fun. I ran into some technical difficulties literally at the last minute; we kind of held everyone back. I felt bad, but we were so close to perfection!

Here’s a screenshot of the final game:

And here’s the gameplay trailer:

I learned a lot from this game jam. A lot of people say they learned to start very small and fight feature creep, but I think we had that under control from the get-go. The idea would have been a decent success even with less features than we got done, which is one of the big things I took away from this jam.

If you frequent game development forums, you’ll often see new people with great ideas and no experience. And everywhere in the threads, in the stickies, in the FAQs, you’ll see little blurbs telling these people that ideas are worthless, and the real value is in the execution. I think I’ve bought into this mindset a little too much. Before this jam, I didn’t realize how long it’s been since I’ve actually made a drop-dead simple game that’s just about pure fun mechanics. I spend most of the time on my game projects writing things like voxel renderers, script engines, and nice editors, features that don’t directly impact gameplay. I skip right past the gameplay stage and go straight to the hard stuff.

This game jam has taught me how much depth a gameplay mechanic can add to a game. I’m definitely going to revise my techniques in the future because of it.

The one thing I regret is not spending enough time talking to people and helping them out with their games. I think I would have learned even more if I had done that, and I certainly could have helped other people learn more. I spent most of my time dealing with technical issues which taught me nothing I didn’t already know. Next time I think I might just float between groups helping people, because if I decide to take responsibility for a project, I now know it will become a matter of personal pride and I’ll take it way too seriously.

That’s all folks! Download the game and source here. Thanks for reading everyone. Back to Project Lemma next week.

This week was a lot of under the hood improvements. The voxel engine got a TON of performance optimizations, which allow my Nvidia GTX 260 to render my test scene at 100-200 FPS.

Screenshots:

New features:

• Rough-draft tutorial level with instructions and whatnot.
• Fullscreen toggling on-the-fly by hitting F11
• Rudimentary fog effect

Performance optimizations:

• Voxels are now rendered as surfaces, rather than complete cubes. This lets me cull a lot of unnecessary geometry.
• Voxels are now split into chunks. This lets me easily implement frustum culling and view distance, which helps tremendously with shadow map rendering as well.
• I fixed some bugs in the voxel modification code, making voxel modifications of up to 100-150 cells practically instantaneous.
• Shadow maps and reflections are now rendered every other frame. It’s a hack, but the important thing is that the gameplay is responsive.

My biggest development challenge was my battle with fullscreen toggling and graphics resource management. Switching from fullscreen to windowed mode, the entire XNA GraphicsDevice is invalidated, along with every vertex buffer, texture, shader, everything. So that was interesting.

Just a quick update this time. Expect a playable alpha soon! Very soon!

My last two posts focused on general game development topics, but no longer. It’s the end of the year, time to look back and review before looking forward to the new year!

Digital Art

First off, some fun diversions. In my pursuit of an art minor at Ohio State, I took a digital art class autumn quarter. The instructor let me use software I was already familiar with, so I didn’t learn much. But the class gave me the motivation to plonck my butt down and make some art, which is all I really wanted.

One of the assignments was to create a mapping project, which resulted in this monstrosity:

It’s not the most efficient representation, but it’s a diagram of all the files I’ve created while at Ohio State. The brightest circle is the root directory, and the other directories branch off of it. It would have been really interesting (not to mention embarassing) to map out all my files all the way back to 6th grade, but that would have roughly doubled the size of the project. Maybe I’ll revisit it later.  (Bonus: see if you can find where this image itself was stored! I N C E P T I O N)

Then my teacher wanted me to actually do some “real” image manipulation, which resulted in this series:

I built the cube scene in Blender 2.5. The pictures were taken with the crappy camera in my Droid X for two reasons. One, it’s the only camera I had. And two, the gritty low quality would help mask my terrible image editing skills.  The picture of me climbing in the window took around 50 attempts to get right. The hardest part was probably lining up the camera in Blender to match the perspective of the photos. The one thing I really regret now is making the window have zero thickness. I wanted it to look like a portal, but the fact that it has no thickness makes it look a bit like a projection.

For the final project, my instructor said we could do whatever we wanted. So I built something I’ve been wanting to do for a while: a 3D Facebook Graph explorer! Rather than simply graphing your friends’ mutual relationships, I wanted to graph EVERYTHING. You can see connections between posts, tags, photos, people, places, events, everything.

This came about after I saw how easy and awesome the Facebook Graph API is. Really, it’s amazing. They provide a simple graph explorer for you that shows the kind of JSON data you can get. It’s fun just to mess around with. Check it out.

I used the super easy Panda3D engine which allowed me to write everything in Python. For this project, I took advantage of the engine’s built-in bloom, text rendering, and ODE integration for the nifty physics bounciness. Panda3D also features a browser plugin, which made Facebook integration very easy. I used Facebook’s Javascript library to do the authentication. All I had to do was pass the access token to the plugin via an embed parameter. Then this simple library made it easy to talk to Facebook from Python.

The one feature I really wanted that never panned out was asynchronous HTTP requests. You’d think something like that would be built into Python, but noooo. And the third-party solutions are generally pretty complex (looking at you, Twisted). Anyway, I’m posting the source here in case anyone’s interested. The whole thing weighs in at around 1000 lines.

Project Lemma

I’ve made a lot of progress with Project Lemma over Christmas break. I started by adding C# scripting support, followed by some useful tools for scripting, like triggers. I also added an immensely useful animation system similar to the Universal Tween Engine. It allows you to create transitions in one easy line of code. For example, to double the scale of a sprite over the course of three seconds, you might do something like sprite.Run(new Scale(2.0f, 3.0f)). I learned this from developing on the iPhone, whose success I am convinced is entirely due to nifty transitions.

Combined with the property binding system and the scripting system, it’s incredibly powerful. Here’s a script I wrote that runs when the first level loads (it tries to simulate the player “waking up”).

renderer.BlurAmount.Value = 3.0f; // Start out blurry and completely black
renderer.Tint.Value = Vector3.Zero;
script.Add("Animation", new Animation
(
  new Animation.Sequence
  (
    new Animation.Vector3MoveTo(renderer.Tint, Vector3.One, 1.0f), // Fade in from black
    new Animation.Execute(delegate() { enablePlayerComponents(true); }), // Enable player movement
    new Animation.FloatMoveTo(renderer.BlurAmount, 0.0f, 4.0f) // Slowly decrease the blur amount
  )
));

Hopefully this is enough to show how it works. I just pass a property to the animation, and each frame the animation object updates the value of that property. The real power comes in the ability to combine animations together, as demonstrated by the Animation.Sequence. Once the base was done, it was very easy to add classes like Animation.Reverse, Animation.Parallel, Animation.Repeat, and Animation.Speed.

In fact, here’s the complete source code. It’s less than 500 lines.

After that, I revamped the editor UI. And by revamped, I mean I built one. The old one was a single text label with a bunch of spaces and newlines to create the illusion of formatting. The new design supports mouse navigation and is much better!

I again took advantage of the property binding system with this UI. For example, in the image above, the fields are displayed in a series of lists. The size of the list depends on the number and size of items contained in the list. So, I just created a binding on the Children property that notifies the list whenever a child is added, replaced, or removed. Whenever a child is added, I add a binding to its Size property that also notifies the list when the child’s size changes. When notified of these changes, the list marks itself “dirty”, which means it needs to recalculate its layout before being drawn.

At first I had it recalculate the layout immediately upon receiving a change notification, but that resulted in the entire UI layout being recalculated every time something changed, which could be multiple times per frame. The dirty flag ensures the layout is only recalculated once per frame.

Next, I quickly threw in a few graphics updates that allow more control over the look and feel. I added support for spotlights (which is easy with deferred shading; it’s just like point lights, but with a cone instead of a sphere). So now there will be dramatic lighting all over the place. I also got some feedback from the last video (thank you, by the way!) that everything looked a little dark. After fiddling with all the lights in the editor a bit, I realized I needed a better way to tweak the overall color of the game.

I implemented a simple, quick, but effective solution described in a GPU Gems article. Rather than rolling your own color curve editing tool, it takes advantage of the fact that you already have a fantastic curve editor: it’s called Photoshop (or GIMP). Here’s a synopsis of the technique:

1. Take a screenshot of your dark/bland/whatever game.
2. Edit the curves until you like what you see.
3. Save the curves profile. GIMP saved mine automatically.
4. Make a new 256×1 image with a gradient from black to white going left to right. This is called a color or light ramp.
5. Apply the saved curves profile.
6. Save the image and use it as a texture in your post-process composite effect.
7. Use the source code below in the composite effect.

float3 inColor = ... // This is your unedited color
float3 outColor;
outColor.r = tex1D(LightRampSampler, inColor.r).r;
outColor.g = tex1D(LightRampSampler, inColor.g).g;
outColor.b = tex1D(LightRampSampler, inColor.b).b;

DONE. Easy, right? It’s the poor man’s tone mapping. Here’s a screenshot showing off the brighter color correction and deferred spotlights:

A lot more work has been done on Project Lemma, but it’s not very exciting. I fixed a lot of memory leaks. There’s a lot of exciting work happening on the gameplay, but I’m not quite ready to show it yet. More on that in the new year!

Work

I went back to work for two weeks over Christmas break. My co-workers released Sarge and Oculus while I was gone! Check out Sarge, it features some great voice acting and hand-drawn animation.

Anyways, my employer let me take my work machine (MacBook Pro) back to Ohio State so I can continue working. Unbelievable! Now that I have access to my work computer in my free time, I’d love to take some screenshots and talk about the game I’m working on, but I’m not sure what I’m allowed to say under NDA. I’ll ask and double check. At any rate, the game should be done by this summer, so stay tuned.

Wrapping up

Whew. That was a lot. It’s late. Needless to say, I’m excited to keep progressing next year. Hope everyone had a great year as well, and I can’t wait to continue the journey with you all! Thanks for reading!

There are a lot of .NET scripting solutions out there. Here’s a few I found in my research:

• IronPython. Fully dynamic, kinda slow. Requires marshalling of some kind between the script world and .NET.
• CSScript. Very well supported, includes Visual Studio extensions and shell extensions. Compiles C# to bytecode at runtime, with caching. Scripts cannot be changed once loaded.
• Lua. The industry standard in scripting. From what I understand, a little challenging to get working with .NET.

I decided to try out C# runtime compilation. Really, C# is the best scripting language I could ask for. If I succeeded, I could keep writing the same code I’ve been writing, but I could recompile it and see it in action with a keystroke instead of restarting the game!

Setup

I started by writing a ScriptBase class that every script would inherit from.

public class ScriptBase
{
    public static Main main;

    protected static Entity get(string id)
    {
        return ScriptBase.main.GetByID(id);
    }
}

“Main” is my main game class. The “get” function is a utility function I wanted to provide for the scripting environment. Using the ScriptBase class, I can add utility functions that can speed up the scripting process.

Next, I wrote a prefix and postfix for the script files. This will help the scripts actually look like scripts, i.e. not object oriented, pretty much just a list of statements to execute in order.

private const string scriptPrefix =
@"
using System;
using Microsoft.Xna.Framework;
// ...

namespace Lemma.Scripts
{
    public class Script : ScriptBase
    {
        public static void Run()
        {
";

private const string scriptPostfix =
@"
        }
    }
}
";

The idea is: compile the assembly, reflect it and get the Script type, then call the static Run function on it. Like so:

Type t = assembly.GetType("Lemma.Scripts.Script");
t.GetField("main", BindingFlags.Static | BindingFlags.Public | BindingFlags.FlattenHierarchy)
    .SetValue(null, this.main);

this.scriptMethod = t.GetMethod("Run", BindingFlags.Static | BindingFlags.Public);
this.scriptMethod.Invoke(null, null);

Compile some scripts already!

This code isn’t particularly interesting, but I’ll provide it for reference:

string scriptPath = ...;
string binaryPath = ...;

try
{
    Assembly assembly = null;

    using (Stream stream = TitleContainer.OpenStream(scriptPath))
    using (TextReader reader = new StreamReader(stream))
    {
        CodeDomProvider provider = CodeDomProvider.CreateProvider("CSharp");

        CompilerParameters cp = new CompilerParameters
        {
            GenerateExecutable = false,
            GenerateInMemory = false,
            TreatWarningsAsErrors = false,
            OutputAssembly = binaryPath
        };

        // Add references to all the assemblies we might need.
        Assembly executingAssembly = Assembly.GetExecutingAssembly();
        cp.ReferencedAssemblies.Add(executingAssembly.Location);
        foreach (AssemblyName assemblyName in executingAssembly.GetReferencedAssemblies())
            cp.ReferencedAssemblies.Add(Assembly.Load(assemblyName).Location);

        // Invoke compilation of the source file.
        CompilerResults cr = provider.CompileAssemblyFromSource(cp, Script.scriptPrefix + reader.ReadToEnd() + Script.scriptPostfix);

        if (cr.Errors.Count > 0)
        {
            // Display compilation errors.
            StringBuilder builder = new StringBuilder();
            foreach (CompilerError ce in cr.Errors)
            {
                builder.Append(ce.ToString());
                builder.Append("\n");
            }
            this.Errors.Value = builder.ToString();
        }
        else
            assembly = cr.CompiledAssembly;
        }
}
catch (Exception e)
{
    this.Errors.Value = e.ToString();
}

The goal here is to compile the script to a DLL so the next time the game runs, I could check if it already exists and just load the DLL instead of recompiling. You can do this with the CompilerParameters object, by setting GenerateInMemory to false and OutputAssembly to the path of the DLL you want to save.

Recompiling scripts on the fly

Now the problem is, once we load the DLL, the .NET runtime locks the file until the program exits. There’s no way to unload the library and unlock the file, unless we put it in a different AppDomain, which means we have to marshal data back and forth between the script and game, which defeats the purpose.

Since one of our requirements is being able to recompile the script without restarting the game, we need to find a way to load the DLL without locking the file. Enter shadow copying. You can tell the .NET runtime to make a copy of every assembly it loads, and load the “shadow copy” instead of the real file. That leaves the original DLL free for us to rewrite. Great, so let’s just enable shadow copying and we’re done.

Unfortunately, life is never that easy. You can’t enable shadow copying for an AppDomain once the domain has been created. You have to create a new AppDomain with the settings you want. Solution: create a tiny launcher executable that creates an AppDomain with shadow copying enabled, and then executes our game in that AppDomain. Here’s the code:

public static void Main(string[] args)
{
    string baseDirectory = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);

    AppDomainSetup setup = new AppDomainSetup();
    setup.ShadowCopyFiles = "true";
    setup.ApplicationBase = baseDirectory;
    setup.PrivateBinPath = baseDirectory;

    AppDomain domain = AppDomain.CreateDomain("", AppDomain.CurrentDomain.Evidence, setup);
    domain.ExecuteAssembly(Path.Combine(baseDirectory, "Lemma.exe"), args);
}

Note: the AppDomainSetup.ShadowCopyDirectories property lets you provide a list of directories to limit the use of shadow copying. I tried to use it to specify that only the script DLLs be shadow copied, but it didn’t work. YMMV.

Okay, so I fired up my game, compiled the script, went to delete the compiled DLL, annnnnd… still locked! What’s going on?

I did some reflecting and found out the C# runtime compiler is kinda janky. It isn’t, like I assumed, a .NET wrapper around some kind of compiler library. Instead, it actually invokes the C# compiler executable, then loads the resulting DLL. If you specify GenerateInMemory = true, it invokes the compiler with a temporary DLL file path and loads the temp file into memory.

Furthermore, it doesn’t shadow copy the DLL when it loads it, even if the AppDomain is configured to do so. I’m guessing this is because it uses a different Assembly.Load function… don’t quote me but I believe Assembly.LoadFile does not shadow copy files, while Assembly.LoadFrom does.

Anyway, to solve this, we can take advantage of the compiler’s quirky nature here by not specifying an output assembly path. That will cause the compiler to generate a temporary file path for the output assembly. So it will still lock the DLL, but we don’t care, because it’s a temp file. Luckily, we can still read the DLL even though it’s locked, so we can copy it to the path we originally wanted for later use.

Here’s the modifications to our original compilation code:

CompilerParameters cp = new CompilerParameters
{
    GenerateExecutable = false,
    GenerateInMemory = false,
    TreatWarningsAsErrors = false,
};

// ...

assembly = cr.CompiledAssembly;
File.Copy(cp.OutputAssembly, binaryPath, true);

The next time we load the script, we’ll see the DLL at binaryPath and load it. But it will be automatically shadow copied. Mission accomplished!

Conclusion

One disadvantage to this approach is that when you recompile a script, the old assembly remains in memory, and the temp DLL file will remain locked until the game exits. Like I said, there’s no way to unload an assembly from a running AppDomain, and we don’t want to put the scripts in another AppDomain. Luckily most script assemblies should be pretty small, and we’ll only be recompiling scripts in the editor, not the final game. I can live with that.

I’m still in the middle of all this, but I thought I’d share what I’ve learned about .NET in the meantime. Might be useful if you’re thinking about doing something similar. Here’s two StackOverflow threads that helped me through this process:

• Recompiling code without AppDomains
• Discussion about different .NET scripting solutions – lots of links

Thanks for reading!