A Snowy Slalom - Danika

“A Snowy Slalom”: Leading the way towards the new era of gaming technologies

In an era where technology is always evolving, he who stands still will be left behind. On the other hand, he who follows it so closely runs the risk of being led to a dead end. Yup, during my professional career, I had a good share of surprises about technologies and third-party frameworks that all of a sudden get discontinued, leaving the investment done in custom applications dead in the water. I have also gotten scolded for not having frameworks up-to-date, losing a sale due to the fact that our technology does not support this or that other requirement that other products do.

As an “indie”, I took the decision of branching out as a way of reaching a bigger audience. I have to admit, the pile of options to choose from is rather overwhelming, as each one offers features compared to none, most of them highlighted with a “wow” factor using multimedia assets widely distributed over the Internet. Crowds of followers are not shy to chant over and over the benefits that each framework has, and some of them are happy to share their knowledge by publishing detailed tutorials for free.

Regardless, the thought of venturing to an unknown landscape, using a different framework, in an unfamiliar development environment and programming for a hardware that I don’t even have, can be daunting. Therefore, it was decided that the best approach to embrace this quest was to port an existing project rather than to start anew. The champion chosen for this challenge was our game “A Snowy Slalom”.

Starting Point

The project “A Snowy Slalom” started in the winter of 2011 – 2012. It was a time when I had already published my first game in the XBLIG channel, and I believed that my 3D engine had evolved enough to take over a wide variety of projects. I still had the strong believe that game developers should be conscious about our influence, so I wanted to try and create something not violent at all, something that would be in contrast to the mass murdering shooters that were in vogue. While going through the standard brainstorm process, I remembered the time when I tried a pool of waves for the first time: It was a cute experience when dodging waves on the shallow end, and yet it was rather impacting when doing so on the deep end, where the water was literally up to the neck and where no floor can help you jump. I recalled such experience while watching a winter sport event on TV (I really need to get cable), and that is where I got the idea of creating a skiing game. Not just the average “dodge and be happy” or “jump & stunt” kind of skiing, but a project in which the overall experience changed completely once the player was right on it, an experience that would allude that the elements of nature should not be taken so lightly.

Back then, there were two main design styles for sports games: On one side, there was the “realistic” approach, in which all efforts were spent towards mimic reality at all costs. On the other side, there was the “cartoon” style featuring characters with over-sized heads and wobbly movements, aiming for a cute gaming experience. The design chosen, however, was something between these two: The style is based on a colorful environment (even the snow has a tone of blue), and yet the character rigs (or character proportions) are close to reality, allowing the execution of natural human movements. Overall, the design is heavily influenced by the masterpieces of leading American animation studios.

By June 2012 the development of the main components of “A Snowy Slalom” using XNA was complete. The game was featured in the “Dream, Build, Play 2012” contest, and it was officially released on September of that same year on the XBLIG marketplace.

The Technology to Use

During the last couple of years, the indie market got flooded with new engines, technologies, frameworks, programming languages and assets stores. The new generation of gaming consoles had gone all of them through a promising debut, the id@xbox program was gaining popularity and everybody started talking about game development. By June of 2014, after taking a well-deserved break, I was ready to choose the technology to use for my next project. So, I started my research and weighted all available options based on my current needs, knowledge, experience and resources. While learning their benefits and restrictions, one by one I scratches these options off my list until, suddenly, my list was empty. This was an unexpected surprise, contrary to what was promised by all marketing material widely spread through electronic media. Shockingly, I found myself with a set of tools and assets that I could no longer use for the brand I wanted to work with, and that was a fact that was hard to swallow.

For starters, from all options available, back in 2014, there were only three frameworks supported by Microsoft’s new gaming console: Unity3D, DirectX11 and Unreal Engine (this last one was not free, so it got discarded by default). Of all these, none of them supported a type of file for 3D models called “X-File”. This was an important requirement since I had worked with a game engine that used this kind of 3D files and, for years, I had enhanced it and enriched it on every game I released. I had chosen to work with this file format back in 2011 because this was by far the most well-documented from the two 3D model file formats supported by XNA. The other option was Autodesk’s “FBX”, and it is not easy to create one of these files programmatically. On my defense, the X-File had been the standard used by DirectX for almost a decade, and never in my life could I have even imagined that Microsoft would drop support for its own 3D model file. About a year before, I had dropped a line in a DirectX11 forum requesting the support of this type of file, and the answer I got was not encouraging.

My situation was a little bit more complicated than an unsupported file: I had my own game engine based on an event-driven animation language of my own invention that pretty much allowed me to create any type of game I desired. I even had quite a set of tools to assist during game development. These tools created the game characters by mixing features like hair, skin color, body type, clothes (to mention a few), compiling them in an x-file ready to use. I had proven the efficiency of this engine with a third-person shooter, “Battle for Demon City” (released on April 2014), which had earned good comments (at least when it comes to the animation used) from gamers and critics around the world. To give some perspective, “Battle for Demon City” has 230 different animation sequences for 10 different models (some animations were applied to more than one model), for a grand total of over 2300 individual frames, all of them loaded, compiled and executed at run-time almost instantly. The best part was that the installer was 22Mbytes big, which was well below the 50Mbyte limit imposed by the XBLIG marketplace.

The importance of this animation engine resided in the fact that it had been the tool that allowed me to create games that were different from all others. This is paramount in a market where there are literally thousands of games available. The results I got with this algorithm had become my style’s “signature”, and I was not keen at all to the idea of discarding everything and start all over from scratch.

I was just about to give up on consoles and focus on games for PC using Monogame, when a thought crossed my mind: If I was able to create x-files programmatically then I might just as well be able to read and upload them, even in an unfamiliar framework. So, I gave it a try. From the two options remaining, Unity3D is more a “commercial game engine” rather than a development platform, so the implementation of my own animation engine was not going to be so easy to achieve. On the other hand, DirectX is a collection of APIs, thus it welcomes any kind of implementation I desire… although it was clear that I had to do it myself, without warranty that any custom development would be supported in further versions. I jumped in, and in two week’s time I had the routine to read, load and animate a 3D model from an x-file format (I think it has taken me more time to write this article). At that point I decided to give DirectX a try, hoping for the best.

I know, this document is sounding more like a charade rather than a serious article since I started talking about new technologies and the buzz around them, and I ended up with the oldest API available and the one framework that nobody seems to cheer for. To give credit to all those who disagrees with my choice, I am very well aware that the extra effort invested in this technology is the result of refusing to let go an “outdated” file format. For those familiar with IT management, in-house development of proprietary technology has a great risk of incurring in a high cost at a long term. Still, I’m willing to take that risk, just to make sure that my games are different from all others available in the market.

The Migration

Not everything went smooth. Once I had migrated all code to C++ and DirectX11 using Visual Studio 2012, I started to suffer from performance problems. The same game in C# and XNA had better performance, which was a cold reminder that the programming language is not always a decisive factor for overall performance. I was just about to throw everything out and start working from scratch with Unity3D (this time for good), when I read something about “instancing”. The more I researched about it the more excited I got. After implementing this feature in full, all performance problems were gone. I got so “hyped” about it that I extended it to all 2D graphics as well.

By early December the migration of “A Snowy Slalom” was complete. The next steps were to ensure that it complied with Microsoft’s Windows Store policies, including support for touch screen. By the end of February, the game was released in the Windows Store as a “desktop app” game.

What Worked

  • The migration project was a success. Overall, the game developed both in XNA and in DirectX have the same gaming experience, although this last one has a better performance as well as some camera enhancements applicable during collision detection, which was a feature that was recently added to my game engine.
  • The music I wrote for this game is, by far, the best thing I have ever done. It’s an up-beat, old-style midi file, played with childish instruments, yet the tone is quite dramatic. It really fits the overall game style.
  • DrawIndexedInstanced(): Everybody who works with DirectX should read about this function. This is the one that fixed all my performance problems.
  • Fonts have “Intellectual Property”. A project released to the public usually has to pay royalties to font creators. Depending on the package, it is a $50 to $100 expense. Still, I was having so many problems displaying text that I decided to implement my own font. I mean, I was hitting a dead end, and the thought of still having to pay for it after all that pain, was upsetting me. So, I took my stylograph pen out and created my own font. This was a struck of luck, as at the time I didn’t know that DirectX has some serious performance issues when it comes to text.
  • I had problems identifying a system that would represent the minimum hardware requirements to support my game engine. However, at the beginning of 2015, I got an HP Stream 7 tablet for only $99 USD. This is the best device I could ever find for performance testing (not to mention the useful touch screen). I highly recommend using one of these devices for QA and load-test.

What Caused Pain

  • The main problem with DirectX is content management. I had to convert all images (png, jpg, bmp) to “dds” files because that is pretty much the only format that I was able to load.
  • If the graphic part of DirectX is complex, the audio part takes the winning prize, by far. I understand that Audio2 is a low-level API, but it really took a big effort, just to play a sound. Likewise, all sounds had to be converted from “wmv” to “wav”. This increased the installer size by a 396% (from 16Mbytes for Xbox 360 to 63Mbytes for App Store).
  • I couldn’t make the C++ XML reader features to work. That was a little bit of a shocker, as all my animations are stored in this format. I mean, normally, in a standard custom application, I would have linked to the XML reader included in the .NET Framework. However, for App Store Applications, is not that easy to identify what can be used and what should be avoided. It’s nowhere documented. As a work-around, I had to create my own XML parser.
  • Managed classes in C++ can become a real pain. In most cases, it was much easier to use native structs and keep them loaded for the entire session rather than create, on every call, instances of managed classes and rely on the garbage collector to clean the mess.

What Didn’t Work

  • The Windows Store is not quite crowded. The more I announced “A Snowy Slalom” for Windows, the more sales I got at the XBLIG marketplace. I’m starting to consider going back to the Xbox 360 platform.
  • The pricing schema may not have helped at all. “A Snowy Slalom” is sold for a dollar at the Windows Store, just like in the XBLIG marketplace. However, the audience at the Windows store seems to be keener to download games for free, even if they have to deal with marketing ads or in-app content purchases.
  • I could not reach the deadline of December 2014. I published my game a couple of months after that, when winter was already half way through. This is a serious draw-back for a seasonal game. Maybe if I had focused on migrating this game from the beginning instead of first migrating my game engine and then re-applied it to the game would have been faster.
  • As an indie developer, I lost a little bit of popularity between my peers. It seems that not many people welcome the idea of creating their own game engine, and some of them are prone to defend their position a little bit too passionate. It’s really not that big of a deal, many people before me have created their own game engine as well. Also, I understand that what works for me may not work for somebody else.