Thursday, June 27, 2013

Thunder Moon - Multiplayer First Steps!

Work on adding multiplayer to Thunder Moon is progressing well. The general infrastructure is in place and the remaining work largely involves discovering the data that needs to be kept in sync between peers and a fair amount of UI work. It's been quite a while since I've been able to use my networking background, and it's been a lot of fun to get back into it.

Here's a quick clip captured on my PC showing a connection to the XBox over the LAN.
I expect this is probably a pretty boring clip to most people. It just shows a couple characters walking around each other for a little bit. Personally, I'm excited to see this because it shows that the networking system exists and that it works. Next on the list is to start finding all the things that need to be synchronized between machines for gameplay to work as expected. I've already synchronized some of the character animation and physics as the video shows, but there is quite a bit left to do: inventory, equipped items, projectiles, NPCs.. it's actually a fairly large list that is bound to grow more as I dig into it more. The good news is that I am pretty sure that most of the work is fairly low risk and I hope to power through it quickly.

Monday, June 17, 2013

Indies on XBoxOne : The questions remain.

I'm still seeing mixed reports about what will actually be required to publish games on XB1. Matt Booty, the general manager of MS's Redmond Game Studio, has told the media that publishers will be required, while Don Mattrick has said they were planning to support developers of all sizes. I don't understand why Matt Booty's comments seem to be carrying more weight in the media than Don Mattrick's, considering who is actually in charge of the XB1. Don Mattrick: "We're going to have an independent creator program... There's no way we're going to build a box that doesn't support that.". Seems pretty clear to me, and he's in charge, so why are we hearing others say a publisher is going to be required?

I wish the MS crew had a consistent message, the opportunity cost of this mixed message is getting bigger every day by not making it possible for indie devs such as myself to plan. I'm hoping the //build conference next week will set things straight; it would be a logical place to bring out the official message and I'll be holding my judgement until then. Microsoft is obviously huge, and it would be no surprise if not everyone knew exactly what the final, official plans and requirements are going to be until it's made clear in that kind of forum. It could very well be that things will turn out better than what indie devs are fearing right now. Then again, it might turn out that MS just wants to put out the AAA games and call it good. Of course, players wouldn't call that good, but that's another issue.

Another possibility is that plans are in flux and the MS execs are still sorting things out. The type of press XB1 has had since E3 is almost certainly the center of some serious conversations at MS HQ. It's entirely possible their plan all along was to give out as little info as possible for the express purpose of being able to change plans based on the public reactions without losing face in the process. Personally I'm ok with a little corporate backpedalling if it means the customers get what they want. 

As far as the publishing requirement goes, if it does turn out to be part of the plan I won't fault MS for not wanting to spawn another marketplace of fart apps, online vibrators charading as games and barely reskinned tutorials. It's no fun seeing my serious efforts, the result of literally years of work, sitting next to that sort of thing in the marketplace either. If getting on XB1 meant establishing some kind of low-commitment relationship with a publisher in order to maintain some reasonable level of quality in the marketplace I can see that actually being a good thing, despite the hive rage brewing in the indie scene right now about needing a publisher. I have heard of far too many people who avoid XBLIG because of the perceived lack of quality games to be found there, and there is some truth in that. Keeping expectations of quality high is a good thing for keeping people interested.

Right now I plan to stick with XBLIG on XBox 360 for a while and let things settle down a bit, and then aim for whichever console seems to make the most business sense. If that means a publisher to get on XB1, I'm OK with that, assuming any would take me and it wasn't a lopsided deal. Who knows, maybe it could mean money for artists which is a real bottleneck for me at this point. It's always been my goal to turn this business into a small group of people anyway, maybe that would be part of making that happen. I'm going to keep my options open, and right now I think that means holding tight and doing my best to make Thunder Moon the best game I can.

Speaking of Thunder Moon, the work on multiplayer will be starting soon. I'm happy to be able to tell you that it's climbing the charts and the daily conversion rate has risen to over 45% which suggests to me players are looking for the game and not just stumbling onto it. This is a good sign, and hopefully the trend continues. Thanks everyone for your support!

Friday, June 14, 2013

#ThunderMoon update now in #XBLIG Peer Review!

I just submitted Thunder Moon v1.0.2 to Peer Review!

It's always hard to predict how long it will take to get a game through Peer Review, but it is always a minimum of 48 hours to get through the system even under the best conditions. Hopefully my fellow XBLIG developers will be able to help out and get it through the system quickly, because this update fixes a number of problems players have reported as well as tuning of the gameplay that I hope players will find to be improvements. Most of the changes are listed here in an earlier blogpost, with a few additional very minor changes.

The biggest of these small changes is a new message on the loading screen which explains how important it is to exit to the main menu when finished playing. As you might imagine, this game saves a lot of data to disk. The system for saving & loading this data is very similar to a database. Because it is almost constantly writing data, jumping to the dashboard or powering off the XBox will leave the database in a bad state that it can't recover from so players need to always "save and exit" to the main menu in order to be sure everything is cleaned up properly. I have a task in my list to work on making the system more tolerant of unexpected exits, but for now players will need to make sure they exit through the main menu.

The other, even smaller, changes are related to fixing up the URLs to the new Thunder Moon website. That's right, I finally got a proper website up for the game. It's not much, just a little artwork, the trailer video and links to the Facebook page, the YouTube channel, my Twitter page and the Marketplace for Thunder Moon. Hopefully this page help to make a good first impression to people new to the game.

Thanks for reading!

Thursday, June 13, 2013

#ThunderMoon playtest update 6/13

Thunder Moon has been out for nearly a week now and I've been gathering feedback from anyone and anywhere I could find it. Some players were kind enough to send me information directly, and others even went so far as to make "Live Plays" (LP) and reviews of the game. It's been a crazy week keeping up with all this and I would like to thanks everyone, especially the players, for helping Thunder Moon get a good start in the marketplace and for giving me information I need to make the game better.

Along with all the info-gathering this past week, I've also been working on code & testing changes to address the various problems and feedback that has come to my attention since the game launched. A few minutes ago I posted a playtest build for Thunder Moon onto the XBLIG service with all the changes I expect to go into the first update to the game, which should be tomorrow. Hopefully some of my XBLIG developer peers will have a chance to check it out and let me know how it goes for them.

Here's the changes:

* Random NPCs generally no longer spawn during the day.
* Random NPCs no longer spawn above a certain elevation.
* Thunder now plays at sunset, indicating random spawns will be happening more often.
* Spawn rates of random encounters tweaked. They ramp up during the night. Generally don't happen during the day.
* Fewer random NPCs will spawn at the same time during early stages of Story mode. Hopefully the ramp-up will be easier for people.
* Music should not be cut off prematurely any more.
* Activation of stacked items no longer leaves the item activated, it consumes stack item as intended. Turrets, for instance, should be more usable now.
* Timewarp effect is disabled when exiting game; previously players could return to the main menu with time slowed down & effects still visible.
* Timed Items that are activated in the inventory do not actually use up their timer until the game is continued. For instance, the time dilation crystal.
* Player teleport is now disabled during cutscenes.
* Player items are deactivated during cutscenes, fixing problem when entering certain cutscenes with jetpacks or other items active.
* Players should not be able to re-enter the crashed lander during the early part of the game any more.
* Lander weapon collision size 1.5x larger, hits NPCs more easily now.
* The "Feedback" page converted to "Our Games" with boxart for my other games.
* There was a user who cancelled the message+credits shown at the conclusion of Chapter 1 and thought the game was stuck in the finale cinematic, so I made the message+credits reappear after a few seconds.
* The default blueprint filter now shows all blueprints. I saw some LPs where players didn't realize there were more than a few items available.
* Footstep volume reduced.
* Power Supply now generates +2 energy/tick, was +1
* Battery no longer stacks, it is a durable item with +2 energy/tick.

Thanks for reading!

Wednesday, June 12, 2013

Thunder Moon Mini Post Mortem: #Softimage in the asset pipeline (Technical)

Softimage is one of those powerful high end 3D tools that can be used for all kinds of things. Over the years people have used it to help make movies, ads, content for videogames, all sorts of other things. It's also one of the tools at the center of our asset production pipeline. Here are some of my experiences with Softimage in the context of the exporter & pipeline I created for the game engine behind Thunder Moon. 

I wrote an exporter for Softimage that produces files in an intermediate binary format (.ecf, for Engine Content File) that is processed by tools specific to my game engine to make the final data loaded by the game. Pretty typical stuff I suppose, but I wanted to mention that for me, I found it easier and more useful to make my own exporters than to write parsers for FBX or Collada (which I put a lot of effort into trying to do, not just guessing here). Those formats are either proprietary or pretty dang complicated to deal with and by writing my own exporter to my own binary format I regained control of the situation and the problem of how to get data from Softimage to the game became much more straightforward. 

There were some challenges getting all the UV data and shader data out of Softimage, but in the end it all worked out well enough. It's able to export models and animations, together or separately, in a way that really helps smooth out the process of getting assets into the game because of how they can be worked on together or separately, with the game able to load and manage assets in groups that make logical sense. For instance, the main character model is one standalone asset, and animations for this character are created in separate files  because there were far too many to put into a single file without it becoming a maintenance issue. More simple models, such as weapons, generally have both the mesh and the animations created in a single scene and they are all exported together. This kind of flexibility has been very helpful in keeping what sometimes seems like an overwhelming number of assets under control. 

One challenging part of the exporter was dealing with the real time shaders because the pipeline supports arbitrary shaders and will export all the parameter settings. The APIs for this work well enough but there seems to have been some undocumented changes over the past few versions. For instance, SI2014 seems to have a few new shader parameters associated with RT shaders that are automatically created by Softimage, which my exporter discovers and exports like it does any other global glsl variable despite me not actually having these variables in the code. This was a small issue for me because the game runs using parallel HLSL shaders and expects to be able to set all parameters that were exported. Since these “ghost” variables do not exist in either the glsl or hlsl source, I had to put special case code to handle this recent change. Of all the things I wish Softimage would open up the source to and let us tinker, this would be it. One thing that worked well here was to make a “property dictionary” that had was basically a set of dictionaries, one for each data type, all keyed by string, which let me export an arbitrary amount of loose data without having to change the file format. This was essential for dealing with different shaders that usually had different parameters to push to the game engine.

The game supports rigid bodies made of composite shapes. The exporter knows how to produce physics data for the models being exported. Originally, these were set up with the Softimage rigid body objects but I had to stop using them because of crashes that would occur when attempting to get data out of them with the C++ api (I think it was GetPatriarch or something like that). I reported these bugs and proceeded to work around the defect since there was no telling how long it would take before Autodesk to fix it. I now do something a little different, which works better for me anyway. I use a collection of meshes that are each constrained to a bone in the character or model. The hierarchy of these meshes, combined with custom properties for essentially “rigid body root” and “rigid body part” allow me to define a collection of rigid bodies for an asset. When exported, each RBR is composed of all the RBPs underneath it, with any sub-RBR’s defining a new rigid body. The RBR property has various parameters to define the rigid body as a whole such as total mass and various game metadata, and the RBP has parameters that mainly define that shape of that part of the composite rigid body. Shape being a sphere, capsule, box, or mesh etc, the actual final geometry being derived by the local axis and the points the mesh is composed of. It took a little work to get the shape generators to properly contain these control points but it wasn’t too big of a deal and this approach allows me to circumvent the limited set of primitive objects provided by Softimage’s physics system. Thunder Moon uses this rigid body exporter setup to create the bits and pieces that fly around when certain objects are destroyed, such as the main character and turret. The custom properties also allow for additional metadata specific to my game engine’s physics such as friction parameters and so forth.

Speaking of additional metadata, there are a number of custom properties the exporter knows how to deal with. “Locators” is one of them, these are "nulls" (basically, empty transforms in the character hierarchy) that have been tagged with the “Locator” property. These allow the game to find named transforms relative to the animated hierarchy of deformers. Locators exist in the hierarchy of deformers and their data propagates all the way to the game runtime, but these matrices are not included in the set of matrices that are constantly updated for the characters – they are updated on demand when they are occasionally needed. This allows for any number of locators to be set up for an asset without incurring continuous overhead. This is used for particle emitter points and attachment points, among other things.

As you can see, for better or worse I've coupled the asset pipeline to Softimage. If I want to switch to another package in the future, I’ll need to do the same sort of exporter there. This would be a lot of work and is easily the biggest downside of taking this approach to the pipeline. Before deciding to commit to this, I really tried to make the other formats work but I just couldn't convince myself I would get the kind of user experience I wanted for the artists (which so far, is just me, but I'd like that to change someday!). The way it is set up now, I can hit export and have everything related to the asset get sent out with a minimum of human error. There is no massaging of meshes to make them deal with quirks of the file format. All animation sources are included in the exported data. It works with referenced models, and can export meshes and animations separately or together, whichever makes sense for the asset. It knows how to deal with subdivided meshes. It all just works, and by eliminating the manual steps in the export I have avoided a lot of “oops I forgot” type of problems I've seen in the past with other pipelines.

Originally, I had set up the exporter to be something that ran as a service in the background on a PC, constantly listening to network requests to export an asset. The idea was that if the content pipeline changed, or if an asset file was changed, the build system would trigger exports of everything that depended on it. This actually worked, and was really quite fast, but in practice it just turned out to be easier to make a list of all assets the game uses and make a single batch file and run it when that happened (which wasn't very often, and hardly ever happens now). Typically, triggering a manual export when “done” building/tuning an asset is how it works now. It’s just simpler at so many levels this way. Rather than having the pipeline deal with Softimage *.SCN files, it just deals with the engine *.ECF files. This is good for another reason; since the ECF format is something I made, I can make other tools that create these files and not have everything coupled to Softimage. I haven't done this yet, but it does open the door to more specialized custom tools such as level and character editors, among other things.

In a sense, it’s kind of like having written my own FBX or DAE format. Perhaps in the end it might be better to have just parsed either of those, but I don’t think so. They are both great for pushing data between 3D apps at a high level, and I often use them for that. I think it’s likely either of them could theoretically work as an intermediate format, there is probably a way to get the extra metadata I need, but the downsides of working with them just didn’t make sense for me. With FBX being closed format and given my experiences with waiting sometimes over a year for show stopping bugs to get fixed, the potential for that to happen is unacceptable. Collada is better in that regard but the parsers I could find were difficult to work with. Both of these formats have export steps that require things to be remembered and performed manually, correctly, every time. As I looked into both of these, I realized I was essentially making a layer between Softimage -> FBX -> ECF -> Game when I could just go Softimage -> ECF -> Game and skip the step of dealing with either of them, avoiding any limitations they may have and reducing chances of human error in the process.

I’m hoping to do a Windows version of the game at some point. Thunder Moon, and the engine behind it, has been designed from the outset to be moddable by the players. If & when that happens, I plan to provide this exporter to players to help them get their assets into the game.

Sunday, June 9, 2013

Calling all XBLIG reviewers!

I'm hoping to get in touch with anyone who does reviews for XBLIG to try to spread the word about Thunder Moon. To make the reviewer's job easier, here is a condensed bundle of information that will help them decide if they should take a closer look along with additional media & information. Please feel free to contact me via email: Thanks!

YouTube trailer:

Marketplace description: Explore Thunder Moon's cavernous alien landscape by foot, with jetpacks and by vehicle in this sci-fi shooter adventure! Fight bosses, warp time, craft weapons, boost stats and items with powerups, place turrets, mine resources, build structures, and much more as the story unfolds in the vast world of Thunder Moon!

Media Pack: is a 7MB zip that has various images including the box cover and a number screenshots and alpha blended images to help with any layout needs. It also includes links to all official & related websites.

Media Pack Online Preview: is an page that shows many of the assets you will find in the media pack. 

Player Reception: Thunder Moon seems to have been well received so far, having reached as high as #3 on the XBLIG top rated list as well as the title of Indie Game of the Week by Geek News Network.

More Info:  The two main websites are and Contact email is

Thanks again for your support!

Introducing Curvin Huber!

Curvin Huber is the artist behind the great icons and bug creatures in Thunder Moon! He is an Associate Professor of Design at Becker College where he teaches 3D animation and I've been so lucky to have his help and support with Thunder Moon. We both learned a lot working together to make the creatures and icons in Thunder Moon what they are today. You can see more of his amazing work on his Flickr site, but I'll put a few examples below to give you a sense of his great talent. Thanks Curvin, I look forward to working with you more in the future!

NPC DesignThe Red Coats are Coming

Thunder Moon - Multiplayer Test January 2012

As you probably know, the current version of Thunder Moon is single player but as this video demonstrates, that hasn't always been the case.

Back in January 2012, when Thunder Moon was still called Squad Miner, client-server networking was already working. While this game has gone through a lot of design changes before it finally hit the marketplace, having multiplayer has always been part of the plan and remains part of the core tech within the engine.

The networking code is still in there just waiting to be turned on. Unfortunately, before MP will be available to the players, I will need to take care of a wide variety of things in order for it to work well. First, all of the mid level code to sync objects between peers. Then the UI. The Lobby. Testing. And more testing. Despite having a head start on this task, it will be a big one. I hope to get working on MP in the near future, but there are more pressing issues that need to be taken care of in the first two updates.

Thanks everyone for your support of the game so far and please let me know what you think is important for Thunder Moon going forward. I'll do my best to listen to everyone and make the game as good as it can be.

Friday, June 7, 2013

Thunder Moon - Available now!

Wow, that didn't take long. Now on the XBox Marketplace! You can also get it from the XBox website which will send it to your XBox once it is turned on (pretty cool setup they have for that, btw).

Thunder Moon passed peer review!


It should be up on the marketplace within the next 24 hours. Pretty exciting!

So, what now?

My immediate plans are to keep working on Thunder Moon.

While I've been doing what I can to promote it so far, there is only so much you can do before the game is released. I'll need to step up the marketing effort even more now that it's actually on the verge of being on the marketplace. There is an awful lot of stuff to do for that! The website, the media package, press release, etc.. pretty big list.

As for the game itself, like most projects of any complexity there are a bunch of small things I wanted to do but couldn't hold back releasing the game over. For instance, when you use the "teleport back" feature, the screen doesn't fade to/from black like it does when you respawn from being destroyed. There are also some item stat tweaks, such as boosting the amount of energy regeneration that battery objects provide versus transformers since the battery is harder to make. After cherry picking the easy and more noticeable items from the task list, I'll be making some more significant changes related to feedback I received late in the process about the crafting UI. I would like to make it more approachable and generally easier to use. The blueprint filters will be simplified, and there will be a new construction dependency tree view to show what objects are required to make a specific object. My goal is to have a build ready by next week to smooth out the player experience as much as possible while still holding a prominent position on the new releases list in the marketplace.

As I think about all the things that I still need to do, it's plain to see I'll need to keep the pressure on for quite a while yet. Hitting the publish button was really just the start of the next phase of the project.

Thursday, June 6, 2013

Thunder Moon's PackedContentManager (technical)

Recently, I was having a discussion with a peer on the XBLIG forums about how the XBox 360's filesystem is pretty slow dealing with loose files, and how it can be especially slow if there are a lot of files in the folder for it to deal with. Neither of these facts should really be an issue for a game that implements the time-tested technique of merging all the loose files into a single file with a dictionary that tracks where each original file's data resides in the packed content file. Think of it as putting all your game content into a zip file, and making the game use only that zip file instead of loading individual files. I think the first time I became aware of this being useful for games was way back in the Doom days where ".WAD" files were used for this purpose.  I suspect nearly every large scale commercial game made since then uses this technique in some form or another because it is a well known and low risk technique for optimizing data loading that I expect is usually worth the effort.

I don't know of an existing page describing how this the packed file technique would be done for XNA, so I'll give a brief rundown of it here. Unfortunately, I don't plan to release code for this technique because my implementation has encryption and other engine specific stuff built into it which I don't have time to extricate, but hopefully my explanation will be enough to put you in the right direction. Also, please keep in mind I am writing this from memory so some of the methods or class names might not be exactly correct as I write this up but you should be able to get the gist of it. It took me about half a day to get the initial code & tools set up, and various minor bugs worked out during the course of the next day or so, but I didn't have any guide to work from so hopefully it will be much easier for people reading this who need to implement something similar.

The first step, which is arguably optional but I prefer to do it this way, is to put all your content into a separate project outside the scope of the game project itself. This is to make sure the main project never has .XNB files in it's bin folder and is always using the packed content. I call this the "GameResources" project. It has the added benefit of allowing you to unload the project if you know you don't need to be rebuilding assets, which can be a huge time saver over the course of the project's development. Just make the game reference this project and the dependencies should just work.

The second step is to make a simple tool to merge all your content from the resource project into a single file. While you could make the tool read from a list and build a fixed set of files, I found it easier to make the tool recursively scan the content bin folder and include all the files it found. The first thing is to create the file with a pad of 4 bytes which will late be replaced with the position of the header data. As you read from each source file and append to the packed file, just track the start and length of each file. When you are done, save the header information at the end of the packed file and set those 4 bytes to the offset in the file where the header was. If you like, make the tool emit some logging information to a timestamped log file so you can see how the set of content changes over the course of the project.

Once the tool is set up, you can optionally make your game's build settings run the tool each time it makes a new build. I do this; the amount of time it takes to merge all the files is surprisingly small and hasn't been  enough to bother optimizing further.

Next is the runtime. There are two main parts to this: A custom stream class, which I call "PackedContentStream", and a derivation of the ContentManager called "PackedContentManager" that has an overloaded OpenStream. The XNA Game's LoadContent is modified to create one of these PackedContentManager objects (which I will start calling PCM) instead of the standard one. The PCM has a constructor that needs the path to the packed content file (PCF) which it opens once and retains an open stream for. Now, the PCM.OpenStream is overloaded so that instead of just trying to open a standard file stream, it instead creates a new PackedContentStream. If you are garbage-sensitive (as I hope you are), these will be pooled and will be set up to be reusable objects to minimize pressure on the heap. Once the stream is prepared, the PCM pretty much just does it's usual stuff and the higher level code doesn't need to do anything special.

The PackedContentStream is fairly straightforward implementation of the Stream class, with a little bit of extra info related to the current packed file. Namely, a reference to the existing stream for the packed file provided by the PCM, and the start position and offset of the embedded file. When you first create the class, you can just use the Visual Studio helper to auto-implement all the abstract methods, which is a great way to get started fleshing it out. This might sounds like a lot of work, but the good news is that the PCM doesn't call very many of these methods since it tends to just read data in a very simple manner. I found it very straightforward to just run the game with all of the methods still containing the default "throw" code and just implement the needed logic in the few functions that actually needed it when the exception was hit. The basic thing you need to do for the implementation is make sure all reads, seeks and other methods/properties are offset by the packed file offset and incorporate the packed file length to make sure they are reading the correct embedded file data and do not read beyond the embedded file's length. It's a pretty straightforward thing to do once you get to this point.

Finally, bonus points for making the PCM log the files opened and making the content packing tool order the files in the same order they are loaded by the game. This isn't necessary, but the reduced seek times can speed things up a useful amount.

That's about it. Hope this explanation is useful to someone!