Dev Diary Entry #5: Afterthoughts about Project Strategy

Introduction

It’s mid November, we are heading towards the final weeks before the due date and, despite my greatest efforts, I am once again behind schedule. Things are moving forward, though, and, as a token, I’ve created a work-in-progress video, captured straight from my brand new Xbox One S.

The small detail that amazes me regarding Microsoft’s UWP technology is that, in this particular case, the very same executable works for both PCs and Xbox consoles – the Xbox control can be used in both cases, although gamers will most likely use the keyboard when it comes to PC. For my little tablet, though, I’m afraid I still need to recompile it for a 32 bit processor, but that will do the trick regarding touch screen control.

Once shown graphic proof of how the game is going to look, I can finally talk about the technology and tools used without raising serious credibility doubts. However, I don’t want to write a sad blog entry overly justifying the use of tools that have become so unpopular on this day and age, using arguments that nobody is going to believe anyway – that won’t give any added value to my readers, and I already have enough hate mail to deal with. Instead, let me address that same topic from a different point of view by talking about Project Strategy, using “Antimatter Instance” as an example.

What I mean by “Project Strategy” is the list of steps taken to identify the development path to follow in order to deliver a given project. Following a structured path will ensure that all efforts made are done congruently, efficiently and towards a common objective, scheduled within the given time frame. Sure, we can always “wing it”, but that usually leads to an unproductive and expensive learning experience rather than a successful implementation – no doubt it is fun, but most of the time is fruitless.

Note that these steps are based on my personal experience as an “Indie” rather than a serious Project Management research.

Step 1: Identify what you want to accomplish

Every single project I’ve work with, as an Indie and as an IT Professional, starts by identifying what exactly is what we want to accomplish. A work-related project focuses on fulfilling a need and making the life of our users as easy and simple as possible. A videogame, however, focuses on the “dream game” that we have always wanted to create.

No doubt this step is the best phase of project planning, as usually we have long, frequent brainstorms of the videogame we want to create. We get inspired from other games, we get ideas of our own, we read on the Internet what can be accomplished on this day and age, we put all of this together and define what we want to accomplish. The more we define it, the more we want to put everything aside and start working on it. It is this vision (along with unlimited supply of caffeine) that will fuel all the long nights ahead.

In my case, I always wanted to create a 3D fighter / action game of the likes of the blockbuster “God of War”, although with much less gore, no racy scenes and a wee bit more cheerful story. I even had the perfect name (which I’m keeping close to my vest for now), as well as the main characters design. There were five particular scenes that kept me inspired, and I even wrote down the dialogues of each one so I could remember them as detailed as possible.

Step 2: Identify the resources and skills at hand

Once we have defined what we want to accomplish, then we identify what resources and skills we have that can be of use. Each of us is unique and our “skill set” as independent videogame developers vary from case to case. This step also includes defining the budget we currently count on, as well as a timeline, if any.

In my particular case, I am a software developer /.NET programmer. I have some experience as a web developer and, about 20 years ago, I used to provide technical support to the image centre of a famous newspaper. These two last entries in my resume gave me enough knowledge to create and handle digital images.

Here is where things get interesting: About 10 years ago a huge project for a Silverlight solution presented itself, and my day job boss asked me to learn and master C#. As the obedient employee I’ve always been, I downloaded XNA and published three games (not on her time and dime, though I have to say that the Silverlight application was a success). To do so, I created a game engine that used differential frame animations for 3D models. It is like a script language that can be extrapolated to generate in-between frames (e.g. change the animation speed to anything and still be a 60 frames per second animation clip) and allows me to add (e.g. play two animation clips on the same model at the same time) and subtract frames (e.g. inserting a set of frames right in the middle of an animation clip). As any language script, the best tool to create these animation clips is Notepad. Eventually, I created a set of in-house tools to aid in the creation and editing of animation sequences. I call these my “in-house animation studio tools”.

Later on, when Windows 8 was launched, I migrating this engine of mine to C++ as a Metro-style application by copying and pasting code… although I did have to translate some classes like the “Generic.List” to native arrays (commonly known as “vectors”), as well as the “.” notation To “->” for object references. Also, I had to implement the “DrawIndexedInstanced” function in order to substitute XNA’s SpriteBatch class with something that would run on DirectX 11.

About the budget available for the Dream Build Play challenge, well, there is none. I’m actually running on a shoestring so there is no way I can incur in an unplanned expense.

The timeline is defined by the Dream Build Play 2017 Challenge. Originally, we were given 6 months to create an entry. Granted, a finished product is not required, and even a running prototype is acceptable. Still, this is a contest, and 6 months is a tight timeline to create anything from scratch.

Step 3: Identifying what we require to reach our goal

This is the discouraging part of Project Planning: This is where we identify everything that we don’t have that we will need to create our dream game. Unless we know exactly what we are doing, we realize more often than not that, unfortunately, we are not the right element for our very own game. No matter, though, for where there is a will then there is a way. Here are some alternative paths to acquire what we are missing:

  • Purchase: Game assets that we cannot create in-house can be purchased in an asset store.
  • Outsource: certain tasks that cannot be done in-house can be outsourced to an external team. This is a very dangerous option since most of the external teams bill by the hour, which is an approach that more often than not drains our fiscal resources providing very few results for our buck.
  • Learn: If the budget is limited and the project’s timeline is somewhat flexible, we can purchase a book or take an on-line course to acquire / hone the skills that we require to create our dream game.
  • Team-up with another indie: When a single project is too big for one single person team then it is best to create a team of people with skill sets that complement each other. If all members have the same skills then all team meetings can be described as a match about who’s right or wrong, and the whole project is reduced to following the instructions of the alpha member. On the other hand, if all skill sets complement each other then each member can focus on his/her area of expertise and create a masterpiece altogether.

In my particular case, here was my first reality check: I looked at my dream game vision, I listed my skill sets, I counted the resources at hand and I came to the sad conclusion that there was absolute no way I could materialize my dream game within the given timeframe. The only way I could still participate in the challenge was to reduce the scope of the game and start planning all over. So, I created a “spin-off” of my dream game in such a way that, instead of being a truly 3D fighting / action game, I focused on creating a side scrolling brawler which would be a 2D game but with actual 3D models. I created a new story and a whole new set of characters. It is not what I always wanted to build and the story is nowhere as appealing as the original one, but it has some interesting ideas that I’m looking forward to implement. That is how “Antimatter Instance” was conceived.

The advantage of putting my dream game aside and creating a spin-off instead is that I leave the biggest vision aside, hoping that one day I could revisit the project and implement it in the near future, perhaps even in the following DBP challenge. In the meantime, everything I create for the spin-off can be of use for the bigger project.

Step 4: Get the tools to use for the project

Once we know what we have and what we are missing, it is time to round up all resources, get the tools we need, install them and start working for our dream game.

Talking about “Antimatter Instance”, here is a quick list of the Microsoft tools chosen for this project:

  • Game Engine: The game engine selected for this project is my home-made game engine running as UWP application on DirectX 11. The main reason for this choice is because I am very familiar with this engine, and I’m quite confident that the animation tools I have for it can be used to create an entry worthy to participate on the Dream Build Play 2017 Challenge.

    To elaborate a little bit, all game engines available have its advantages and drawbacks. One of my previous games called “A Snowy Slalom” (proudly participant of the DBP 2012 contest) had a generation algorithm that created slalom tracks at run-time, which required the use of skinned meshes for the tracks, assembled in an array similar to a chessboard. Due to performance challenges, it was imperative that these track components should be drawn in batch mode, which was a need that reduced the number of commercial game engines that could be used at the time. Due to this technical roadblock, it made complete sense to create an in-house game engine using DirectX 11. Despite popular knowledge, it was not that difficult to create, and the blue print can be found in this other article that I wrote some time ago for the Microsoft’s tech wiki knowledge base. This same approach was implemented in my third-person shooter by generating mazes at run-time.

    However, a side scrolling brawler does not need to have the background drawn in batch since the number of individual meshes is way much smaller than in an open world game (to throw some numbers, 600 meshes in my slalom game compared to 50 in my side scrolling brawler, both at a 60 fps). Instead, the main feature to use is an animation engine with a sophisticated hierarchy and programmable flow that can emulate a sparring match. In this regard, I’m inclined to believe that my home-made game engine has reached this level (as seen in the featured video of this article), although I have to admit that it would take me a few months before I can reach the quality of the user interface that commercial game engines provide.

    There is one big advantage about using my good ol’ game engine: The model editor, included in the tools I created during my XNA days, allows me to mix and match mesh parts and bake them in a single model embedded in an X-File. For example, “Anabelle”, the main character of “Antimatter Instance”, is a re-incarnation of “Alice”, the lieutenant in “Battle for Demon City”, who in turn is a re-incarnation of “Danika”, the main skier in “A Snowy Slalom”, who in turn is a re-engineered character of “Aida”, the mermaid from “Merball Tournament” (well, at least half of her).

    The other advantage is that I can implement special animation effects to be computed at run-time, as seen on the work-in-progress video shown at the beginning of this article, like the animation of the hair, the skirt and the eyes, among other elements.

  • Development Environment: For this project, I have a Visual Studio 2015 development environment with Windows 10 SDK Anniversary Edition. I thought about upgrading to Visual Studio 2017 with the Creator’s Club SDK (edit: now there is a 2017 Fall edition), but the truth is that this kind of upgrades always come with an unexpected technical challenge and, because of the aggressive timeline provided, I don’t really have time to spend in any surprise.

    For example, when I migrated from Visual Studio 2013 to 2015, the internal class structure for a DirectX game changed, which was expected when changing from a Metro-style to a UWP application. What I was not expecting is that the helper class, used to load game assets in the background, changed as well, which broke my implemented object pool managers. This meant that no shaders, textures or sounds could be loaded anymore. It took me a while to fix them since I am not a C++ expert.

    Also, when I changed Windows 10 SDK versions from the UWP version (10240) to the Creators version (15063), the DirectX SDK could not be compiled anymore. I don’t have the exact error message, but it was something like a particular function within the DirectMath library was returning a result in an unsupported format, and therefore the DirectMath could not be compiled. Later on I found out that there was a hot fix for the header file (it’s documented in GitHub), but I felt rather nervous about changing official libraries. At the end, I went one version behind and decided to stay with the Windows 10 Anniversary Edition.

  • Test Environment: As a UWP game, I’m targeting consoles, PCs and mobile devices. To test the game, I have an Xbox One S, a PC with an NVidia GeForce 8500 and a Tablet with an integrated Intel HD Graphic adapter. To elaborate, the Xbox console’s technical specs are standard. However, the technical specifications of PC’s are widely different from unit to unit. Same problem is present with mobile devices. The Microsoft Development Network suggests using an Atom device (that would be my tablet) to test the game. The line of thought I’m following is that, if the game runs on my tablet, then it can pretty much run anywhere.

  • Sound: The tool I’m using for background music and sound effects is Microsoft’s DirectMusic Producer. This is one of the hidden treasures that failed to get the recognition it deserved when it was published – personally, I’d have given a standing ovation. It can no longer be used to create the “mood” at run-time (since DirectSound is now deprecated), but it can still be used to create and edit midi files. In fact, I created the background music in the work-in-progress video with this tool. It was one of the first pieces I wrote back in the XNA days.

Conclusion

I am well aware that this should have been the very first entry in my developer blog. After all, it is rather pointless to list the tools to be used for a project when the project itself is half way done. On my defense, if I have stated on day one that I was going to use Notepad as my primary tool, I would have lost all my readers right then. On the other hand, If I create a work in progress video showing how the game is probably going to look like and then, and only then, I state that I was going to use Notepad as my primary tool then I would have kept my readers… at least for the duration of the video.

As an “indie”, the skill set I have puts me in a unique position:

  • I am a software developer that makes his living by creating custom applications that fulfills very specific needs. That is why, when I don’t have the tools to achieve something, I create them. It’s like second nature to me, and I have to admit that it is part of the fun about being an independent developer.
  • On the other hand, I really want to be an artist. I know, my art sucks, but that doesn’t mean I don’t enjoy creating masterpieces. “Antimatter Instance” has given me the opportunity to create some quite fluid animation clips. True, the in-house approach means that only my game engine will be able to play those clips, but that’s ok since I don’t think anybody would hire me as an animator anyway.

These two roles I play as an “indie” complement each other, and have been the factors that defined the technical framework and the tools I use to create videogames. Everybody is unique, and I don’t expect that the same approach may work for someone else. But I really hope this utterly long post may provide a good insight for other game developers.

Advertisements