Wednesday, October 30, 2013

ID@XBox Seattle Event notes

Last week I attended the ID@Xbox conference at Microsoft’s main campus in Redmond. It was a very useful event for me because I was able to get my most pressing questions about the new platform addressed by some of the Microsoft staff working on the Xbox One. There were a number of presenters ranging the spectrum of technical, business and management areas of the Xbox One. They covered a wide variety of topics over the course of the day, all of them of interest to me. Apparently it was a more condensed version of talks given at a previous conference, but overall it was useful information that really helped solidify my understanding of where the platform is headed and how Indies can be part of it. There was a Q&A session after each speaker and at the end of the day with all the speakers available to answer questions that may have accumulated during the day. I have to say, the folks presenting were all very eloquent, articulate and almost visibly radiating their brainpower as they spoke in detail about the features they have been working on. 

Since NDAs were required to be there, I’m going to have to skip any specifics of what I learned but I will say the tech seems pretty dang cool. There are definitely some new things going on with this platform that will enable fun new features in the games we make, and it doesn’t appear there will be any of the unfortunate limitations that were imposed on XBLIG. From a technical standpoint, I'm pretty happy with what I saw and look forward to working with it.

Like any big product, there are lots of ideas and other things they would have liked to have ready for launch that will have to wait for the future but they did make it clear that their plan for the platform in general involves a lot of evolution. They expect it to change and grow, and built their systems with that in mind. That’s not to say anything seemed lacking for launch, in fact it has a ton of great things going on, it's more about how there is a lot of potential for the future of the platform and they have been as forward-thinking as possible. It’s plain to see they learned a lot from pushing the Xbox 360 so far beyond its original specifications and this is a good thing because this motivated them to put effort into making sure the Xbox One will be easier to manage and extend through the life of the product. Being able to safely update and extend the platform is from my perspective far more important than getting every last feature they could think of in the first release. It's easy to think of more features than you have time to implement, regardless of the product; it's much harder to make a framework that supports evolving a product's core features while maintaining compatibility with previously released titles.

The thing that I am most excited about is that it does seem likely the Xbox One will be generally a lot more open than the Xbox 360 was. A shorter wall for the garden, if you will. Not as open as the PC, but not as restricted as the previous generation either. While I get the impression a lot of things are still being decided, I think there is a good chance Microsoft will strike a better balance between the chaos of completely unrestricted app stores and the stifling limitations of access to the more visible marketplaces of the previous generation. One thing is certain, they are deliberately choosing a business model for the Xbox One and Indies that is different than what I’ve seen before and I can only think that is a good thing. It could just be the afterglow of the event affecting my opinion, but right now I think there is a good chance they will hit the right combination of curation and openness that will allow innovation to occur on their platform without flooding the market with junk apps that cause visibility problems for games worth having.

In the end, I left the conference optimistic about the platform. WinRT+DirectX, here I come!

Friday, September 13, 2013

Update notes for Thunder Moon Online

I've made all the changes I plan to make for the update to Thunder Moon Online tomorrow night. The final build has been made and I'm going through my pre-submission tests now.

The goal with this update is to fix a handful of crashes people have reported and to improve network performance. While I expect to submit the update about 26 hours from now, it will take a minimum of 48 additional hours for it to reach the marketplace. It might take longer, depending on how fast my fellow XBLIG devs will peer review it. That part of the process is out of my control, unfortunately, it's just how it works on XBLIG.

Here's a breakdown of the things that have changed.
  • All reported crashes have been fixed. There were a handful of these, and they generally happened when players joined a game. I've only received a few reports of crashes, so hopefully this means it hasn't been too much of a problem. In either case, everything I know of has been fixed.
  • Bandwidth usage has been reduced by about 50% overall. This should help a lot overall lag and with the voice chat quality.
  • There is now motion smoothing to the characters, hover bike, and lander so these should all be less jerky in their movement. There is now a bit of glide that occurs with characters when they stop moving, but its much better than the popping that used to occur. This is a pretty common technique for networked games.
  • Fewer pickup items, those blocks that pop out of bugs and terrain, will be physically active and moving around at once. This probably won't be noticed except when tons are being spawned while mining.
  • Units would sometimes be vertically offset from where they should have been. This was most often noticed with the spawn portal and beacons.
  • Sometimes, units would be re-spawned despite having been destroyed. I found one problem with this which was fixed, but I never found a way to reproduce this bug reliably so hopefully this is all that was wrong.
I took care to make sure these changes wouldn't break save files and is compatible with existing data. Hopefully this will all go well and the game will be more fun as a result.

Thanks for playing!

Thursday, September 5, 2013

Announcing Thunder Moon Online!

Today, I am announcing Thunder Moon Online. It is the culmination of over 3 months of work building on the Thunder Moon engine which brings multiplayer, improved AI and other new content to the Thunder Moon universe.

I had been planning to provide these new features as an update to the original game, but it turned into three months of work which is just too much to do for a free update. Also, it became apparent late in testing that the changes to how data is stored makes it impossible to apply this upgrade without causing loss of player data. While this is something that could be solved with more development time, it is not a trivial task and as a solo developer I simply can’t afford the time to do that. I didn’t make this decision lightly, but if and when you play Thunder Moon Online (and I hope you do!) I think you will find that the addition of multiplayer, over 150 new blocks and other features will make this new iteration a lot of fun for a dollar.

Thanks for playing!

Tuesday, August 27, 2013

Thunder Moon Crafting simpified in the coming update

I simplified the crafting interface in Thunder Moon based on feedback from testers & players. There are now just 4 item filters to flip through: Equipment, Supplies, Buildable and Terrain Blocks. Previously there were 9 (!) filters, and objects could appear in multiple sections based on meeting the filtering criteria. It was just too confusing, and too much to take in. This should help a lot with finding what you are looking for amongst the hundreds of items you can create in this game.

Items will appear in only one section, unless it's Buildable then it will show there also. The Custom filter used by "Find Related" feature is still there and behaves the same.

The Equipment filter is for things you wear or activate. Items that do things.

The Supplies filter is for all those items that are only used as crafting components. These items are not equippable or activatable.

The Buildable filter shows only those items you can build right now.

Previously, there were filters for each equipment slot (Held, Worn, Aux), and one for items that were activatable or had some passive effect (such as a heal kit, or persistent shield buff). These are all consolidated into the Equipment filter. There was also a filter for "Partially buildable" (meaning you had some of the parts required to build) which was redundant because the items already indicate if they are partially buildable by being yellow instead of red background.

In all, I am pretty happy with this change. The original crafting UI didn't turn out as user friendly as I wanted and this is a good improvement.

Thursday, August 22, 2013

Thunder Moon Multiplayer Update & new box cover art.

Over the past several weeks I've been working through the very difficult task of rewriting the way game units are saved to make it work properly with multiplayer. As a bonus, I expect this will fix the sporadic bugs people have reported about certain mission-critical NPCs not being where they should be for missions later in the game.

One big challenge was to make NPCs work in a way that didn't kill performance on the host while properly tracking all the units that might be around each player, where each player could be at very different parts of the world. When the old system was used with the new multiplayer games, there were lots of problems that never happened in single-player games. Unit duplication, lost units, misplaced units.. these are all problems the old system wasn't able to deal with and these should all be fixed with the rewrite. There were actually a whole host of difficult problems that had to be solved to make this work, but after a lot of head banging and keyboard pounding I wound up with something that I think does the trick pretty well.

The new multiplayer-friendly unit management system is all up and running and so far it seems to be working. This is the last major barrier I know of for getting this next update out, and it's the reason why it's taken longer than I expected. I still have a lot of testing of the new system and some UI stuff to deal with but seeing this new unit manager work for the first time is a big relief. It was a really complicated solution! Often that's a sign of bad planning or sometimes just me trying to do something "the cool way", but sometimes a complicated solution is the only way to solve a complicated problem.

I'll be continuing the push hard to get this out as soon as it is safely possible. I never want to publish buggy code and since there were a lot of low level changes since the last update this will have to get a lot of testing. Hoping it goes well!

While working on the multiplayer has been a priority, I did take some time to update the box cover art. I hope you like it.

Saturday, August 17, 2013

Thunder Moon multiplayer dev update

Wow, it's already been a month and a half since the last blog post on this. Time for an update!

Multiplayer has been coming along pretty well! One of the biggest challenges was to get the world map data to sync up and cache efficiently, but after a several weeks of long days that system finally came together and has been behaving properly for a while now. A few days ago the final planned features were wrapped up and now we are testing. As was expected, some bugs and unexpected feature requirements have come up along the way and I've been working through them as fast as I can.

Multiplayer supports both XBox Live and System Link. There is full support for game invites, both friend and party, which I hope you will find makes it very easy to bring your friends into your game. It also supports private slots, so if you want an invite-only game you can just reserve all the slots and others won't be able to join. These can be changed on the fly, too. The number of players the game will support is still up in the air and the final number will be decided on after I do some load testing and optimizing.

In addition to the world state, all of the characters, vehicles, weapons and their corresponding animations are all synchronized over the network. It's pretty neat to see the backpacks animate, or weapon aiming, and all the other animations working across the network the same way they do when playing local. I paid careful attention to the bandwidth for all these things and made sure the code doesn't cause needless latency.

Multiplayer is supported for Survival and Explore modes. It won't be enabled for story mode in this chapter of Thunder Moon because that wouldn't fit the storyline since, as you will know if you have played it, chapter one is all about being stranded by yourself. Chapter two, however, is planned to work with multiplayer as natural progression of the story and I look forward to seeing how that turns out.

I am hoping to be ready for peer review soon. It feels nearly ready, but there are a number of issues that I have to wrap up still so stay tuned for more info.

Thanks for playing!

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!

Monday, May 27, 2013

Thunder Moon is finally in peer review!

It's been a long haul, but Thunder Moon is finally in peer review on XBox Live Indie Games!

If you have an XBLIG dev account, and wouldn't mind doing me a huge favor, please take a little time to review the game and help us get it that much closer to the marketplace. I'd be very grateful!


While the build going through review is stable and complete, there are of course a lot of things that I'd like to improve. Few games ship with everything we'd like in there, or with everything as polished as it could be so I'm looking forward to tuning up the game some more over the next couple weeks while I work towards the first update. I'm still sorting out what I'd like to add for the first update, but some of thing things I'd like to do include new items, new random encounters and improvements to the UI. Hopefully the players will give me some feedback about what can make the game more fun!

Friday, May 24, 2013

Time Dilation Crystal + FX

Here's a clip showing the crafting of a Time Dilation Crystal and using it combat to get the upper hand against a few critters.

The item system in Thunder Moon is one of my favorite systems. The tools behind it make it very easy to add new items, icons, effects and set them all up with cooldown timer groups and that other various things that make items tick. While the items in the first release are done at this point, I plan for content patches to include new & interesting items that build on what is already in place. Going to be fun!

Thursday, May 23, 2013

New box cover art!

Here's the latest version of the box cover for Thunder Moon. Hopefully it will help catch the player's attention when they see it in the XBox Marketplace!

Tuesday, May 21, 2013

Thunder Moon - XBLIG playtest 5/21

It's been a very busy time since the last playtest build was put out there. This version has more improvements, bugfixes, and changes than I can possibly list here but many of them were topics of earlier blog posts.

After 1.5 years of effort, I'm very excited to say the game is nearly ready for peer review. It's been quite a crunch for longer than I care to think about but it's looking pretty good to me at this point. It's almost time to get this thing out there!

Here is a copy of the playtest post on the xblig forum:

Here are some highlights of the changes since the last play test build: 
* Huge improvements to voxel system performance. It should be much more difficult to get to the edge of the world now, and if you manage to do it, the game handles that situation much more nicely.
* All story missions in place. With the "testcraft" command line parameter to allow free crafting, the game takes around 45 minutes to an hour to play through the storyline, depending on play style.
* The lore of the world has been finalized, along with name changes to items and characters.
* The story intro sequence has some dialog shown during the descent to explain what is going on and to set the story in motion.
* There are several new special encounters in story mode.
* Story mode difficulty ramps up as the game progresses.
* All crafting recipes have been reviewed and built in game using harvested resources.
* Many new items with active and passive effects.
* The Lander now has a very powerful terrain destroying weapon.
* The cargo pod missions now have NPC attacks triggered. There are a lot more items at the cargo pods, the idea is that it should be easy to get make to at least one of the cooler items just by playing the story.
* You can now trigger your backpacks and aux items while driving the Lander or Hoverbike. This is especially useful in one of the story missions later in the game.
* You can trigger generic items from any slot.
* All the help text now uses a larger font. The text itself is less verbose to fit in the same space, but I expect this will do the trick for readability. I've compared with several other games at this point, and the text size is larger than many of them so I expect this isn't a problem any more.
* The item inspection features of the inventory have been improved and include helpful information explaining what each slot of the item panel is for.
Here are some issues you may notice which I'll be working on:
* There are occasionally framerate slowdowns. It's not too common, and not game breaking IMHO, but I do plan to fix them. The game should generally run at better than 30FPS.
* The flying NPCs don't move around so well. Most of the time they behave well enough, but once in a while they don't. I am going to be working on this some more.
* The final mission is a bit wacky with the spawns, there are a little too many.
* When you respawn the world is not obscured, so you can see the geometry getting built.
* The front end of the game needs a little polish.
There are a number of minor things I would like to improve that I won't flood this post with, but if there is anything that jumps out at you as needing help please let me know.
At this point the plan is to fix any major new bugs that show up and try to address any major feedback people might have.
I really would like to hear anything you have to say, positive or negative, about the state of the game, how fun it is for you and what I could do to make it better.
Thanks very much for any play testing and your feedback.

Hopefully this playtest will go smoothly and I can wrap this thing up soon!

Sunday, May 19, 2013

Character & terrain destruction tests

Here are a few videos related to some things I've been working on lately.

This one has some variations of the main character with some very simple motion logic hooked up.

This one shows the characters getting taken out by turrets, showing how they break into parts that bounce around the terrain.

This one shows some tests with the new lander weapon system. It's able to destroy terrain, which is nice when you are flying around in a cave and its a little too tight to get where you want to go. The rate of fire is much higher than it will be in the actual game, I was just stress testing the system.

Saturday, May 18, 2013

#screenshotsaturday Thunder Moon portal & lander weapon FX

Another week, another #ScreenshotSaturday! Lots of tuning, mission work and a few new assets were added this week.

Here's a quick clip of the new portal effect in action:

 Here's the screenshots:
The portal fx
A boss encounter
Random shot from later in the encounter

A shader bug that turned magical. Maybe I'll use it for something!

Saturday, May 11, 2013

#screenshotsaturday Thunder Moon pics & notes

Here's a few shots taken during the week of work on Thunder Moon.

Here's a portal that is used in one of the missions.

Here are some neat looking beam effects. The still picture doesn't really do it justice.

This week has been a crazy one with a large amount of time spent going through all the missions, tuning them, making sure mid-mission saves work correctly, and working towards finishing the remaining few missions that are just stubbed out right now. I'm actually on the second to last mission now which is pretty exciting and I hope all these special encounters are fun for people. Of course, if missions & story isn't your thing, there is also Survival mode, which is pretty much the world without the missions to guide the gameplay, and Explore mode, which is an empty world that is designed for non-threatening exploration & construction.

I also spent a fair amount of time troubleshooting some very difficult problems with the low level serialization system. The game is an open world, with the ability for NPCs and other game units to be added and saved in the world, allowing you to return to a spot and have not only the modified world geometry but also any NPCs or special units that may have been placed there. Missions rely on the persistence to set up encounter areas. There were some problems related to units not always being deserialized correctly, which I am glad to have finally fixed and the game is more stable than ever now. I'm a big believer in good systems to build upon, and the efforts put into serialization system have really paid themselves off not only for tracking the world state, but also for all the not so obvious state data required by the inventory, missions, and character stat systems. Perhaps the best part of all is that it works with reasonable performance on the XBox, which has a notoriously slow file system that requires a specialized solution like this in order to avoid major performance problems when storing this much data.

Monday, May 6, 2013

A little AI work

Over the past few days much of my time has been spent improving NPC movement behavior. Here is a video showing a flying NPC that is forced to navigate around some blocks in order to get somewhere it could attack the player.
This video also shows a few problems with the way the character is moving around, which have since been fixed as part of this work. I like to show the buggy stuff sometimes so people can get a sense of the kinds of weird things we have to deal with when making games. It doesn't generally just show up on screen working as we would like it to, usually it's an iterative process as we figure out why our first take on sometime only got us part of the way (hopefully most of the way) there.

This next video shows a bunch of ground NPCs trying to get into melee range of the player. It's a bit of a load test where I just spammed the debug key to spawn a bunch of them. The main thing I was testing was how they behave with some new code that causes them to separate instead of overlapping the same space.

Prior to this change, a swarm like this would pretty much stand right next to the player with so much overlap going on it would look like one giant unbelievably buggy mess.

Saturday, May 4, 2013

Screenshot Saturday!

Here's a few pics from the week.

The comm dish appears in a few missions as part of the storyline. Here is a shot where I was testing them to see how many I could draw. Because of the instanced model rendering, it could actually render quite a lot before having any real impact to performance.
Communication Dish
I have to say, I'm pretty happy with the instanced rendering tech in Thunder Moon engine. Being able to author rigid body or skinned models and with any number of bones, shaders and integrated lights and then having the pipeline cook everything so it just appears on screen with environmental lighting and other localized effects is really useful.

Here are some dishes as seen in a mission:

Earlier this week I added colorization features to the renderer. Here's a before & after of the same creature with different tunings:
Xeno Crab, original color

Xeno Crab, alternate color
Check out the previous blog post for a video showing more about the color features.

Here's just a fun shot of trying to get away from a large flyer.
Trying to escape a large flyer

Thursday, May 2, 2013

Thunder Moon - NPC Color variations

Here's a quick clip showing a few color variations of one of the NPCs of Thunder Moon. After months of looking at the same characters, it's pretty nice to see some new varieties.

Saturday, April 27, 2013

A little bit of Thunder Moon gameplay

Here's a short clip showing some gameplay near one of the early mission encounters. It shows off the new messaging system which is now integrated with the mission progress and the item wear systems.

Friday, April 26, 2013

Thunder Moon - Message display test

The game really needed a way to present general messages to the player, and this is what I came up with:

The speed of movement and the fade times are going to get tweaked, and possibly the whole thing will get shifted to the side of the screen but the general push of messages upward seems to work pretty well.

Edit: Tweaks complete! Here's how it looks now:

Item Durability & Powerups

The latest update now has a feature that's been in the works for a while: Item durability. The game now tracks a health value for each item that can wear out, which is essentially everything that provides a functional benefit to the player. Weapons, packs, powerups - they all fit into that group.

Pistol with a heat exchanger to increase weapon fire rate, the jet pack with two types of energy generators, and a fusion reactor in the aux slot provides enough power to keep the jets running almost non stop.
Here are the highlights of this update:

  • Items that are activated or which have passive effects now have finite durability and take wear when used. This is shown with a horizontal health bar over each item that has durability. 
  • Items with effects have durability reduced when their effect is providing a benefit to the player. For triggered items, such as the heat exchanger or beam focus, this will trigger wear when the player shoots a weapon that has the item equipped in the socket. For passive items, such as the transformer, auto repair kit or fusion reactor, it will only take wear when the stat these generators are boosting is not at max value. This was a pretty complicated system to implement so I look forward to any feedback on this now that I've finally enabled it.
  • Items now have their backdrops color coded to indicate when they are active. This is important for items in sockets shown on the side of the hosting item so you can see when they are getting worn, possibly deciding to remove the powerup and save it's durability for another time. They are green when ready to activate, yellow when active, and red when the item has worn out indicating it's time to install a replacement. Worn out items currently have no value but I may add recipes or a repair mechanism in the future.
  • Deployable items (currently, the Turret) now keep track of their health when recovered, saving it as item durability.
  • New powerup items: Power Supply, Fusion Reactor. Both boost energy generation, allowing for more jetpack time or other energy consuming activities.

The item wear features is the big thing with this update. Most items take quite a while to wear down. I plan to adjust these after more testing to make them last a reasonable amount of time; too long defeats the purpose and too short is not fun. Please let me know if you have any opinions on this or anything else in the game, thanks!