Game Summary: A turn-based tactics game aboard an abandoned space station
Author
Joshua Fox
Title
Robomancer
Genre
Turn-based tactics
Platform(s)
Android, eventually iOS and Windows
Revenue model
The game will be released as a free demo, with the first few levels included. Players wishing to play the full game can purchase the full version for $4.99.
Development tools/Language
Robomancer was created using Unity and C#, with art assets created in Maya and Photoshop.
Game audience
The target audience for this game is fans of other titles in this genre, such as Final Fantasy Tactics, XCOM, Fire Emblem, etc.
Copyright/Reference
Robomancer © 2015 Joshua Fox
Backstory
Sound Bite
One man's junk is another man's robotic army.
Executive Summary
Robomancer is a top-down, turn-based, tactical RPG set on a space station discovered by the main character. The hero finds the station is full of powered-down robots, and using his technical know-how he powers up a few and explores the station with them. The game features tactical battles in which positioning is key: the main character is more vulnerable than his robotic allies, but he also must stay close to them in order to direct them around the battlefield.
Inspiration
Science fiction stories have always fascinated me, especially those involving space stations--Star Trek: Deep Space Nine is one of my all-time favorite shows. Combine this with my love of tactics games, and you have Robomancer. I wanted to create a game that included the same feeling of danger and tension as the XCOM series as well as a diverse cast of characters and abilities like Final Fantasy Tactics into something uniquely my own.
Ideal
The initial vision for the capstone project was to create a slice of the eventual game. During the design process I included far more elements that I could implement in the capstone time frame alone; this was done in to create a cohesive design. Since the goal was to create a small slice of the overall design, for the most part I was successful. I would have liked to have had more visual content in the game in the form of character models and animations, as it would have added a lot more variety for the player. From a technical perspective, however, I think I achieved what I set out to do. Going forward most of the effort will be spent on creating additional content, though there still are some systems which were not in the capstone project that need to be implemented as well.
Gameplay Screencast
The Critique: What went right…
Unity
Unity is a powerful engine with a lot of capabilities. It is very easy to pick up and get started, though it is not without its own challenges when trying to something complex. Using Unity gave me a good start on my project, as all of the core systems for any game (a renderer, level editor, etc) are already in place.
Unity's Asset Store
Early on in the project I found some content packages in the asset store that allowed me to fill out a large portion of my game's assets (at least for the prototyping/capstone process), so I could focus on making those assets do something interesting. The asset store has a lot of good content which can provide solutions to common problems, as well as act as a learning tool in some cases.
Grid System
One of the first big systems that I wrote for Robomancer was the grid system. All unit actions and AI behaviors revolve around this system--finding units in range, determining a valid movement path, etc. Though I added to this and tweaked it a bit as the project progressed, by and large I got this system right from the beginning. A few extra bits of functionality here and there in the planning stages made later features which utilized the grid much easier to implement.
 |
| The 3D level on the right, and its grid representation on the left |
Lightmapping
Unity's lightmapping system allows for light detail to be calculated and then "baked" into textures called lightmaps. These textures are then rendered on top of the static geometry at run-time, in lieu of using real-time lighting . As a result, the final rendering cost for an object using this method is much less than it would be using a more realistic, dynamic lighting model. Using these lightmaps, I was able to achieve a great deal of visual quality while still maintaining a high level of performance.
Another useful element to go along with lightmaps is what Unity refers to as Light Probes. Light Probes allow a moving object (such as the characters in the game) to look up information about the baked lighting, and change the colors of the objects based on their position in the level. What this means is that dynamic objects are affected by the lightmap information to give the impression of a detailed and dynamic lighting model. The result is not entirely realistic, but just hinting at a bit of realism can make a huge difference.
 |
| Light Probes hinting at realistic lighting |
The Critique: What went wrong…
Unity
This was my first large project using Unity. Prior to this, my experience was limited to a tutorial here or there, and often those only covered the basics of the editor: dragging a GameObject onto a script variable, creating a Prefab, and so on. Creating Robomancer has been a crash course in how to use Unity on a deeper level, and I had to learn as I went along. Unity is a very flexible engine, and someone using it can accomplish virtually any task in a variety of ways. Unfortunately this is a double-edged sword, as some ways are better than others, with no real guidelines as to which is which for someone not completely familiar with the engine (e.g. me).
This is not the fault of Unity; the engine is there to support the developer's project, not structure it for them. This project forced me to develop some more organizational skills, something I often struggle with. Knowing what I know now, there are some things I would have structured differently from the beginning, and some things that I will rewrite once I resume work on the project.
Asset Store Content
Not all asset store content is created equally. The assets that I used for the bulk of the environments had issues with baking lightmaps, and I spent a fair amount of time attempting to debug the problem. Eventually, I discovered there was a problem with the way that Unity was importing the assets, and that it was a known issue with the version of Unity I used for the project (which was 5.2.1). A Unity developer had mentioned in a forum post I came across that the bug was fixed in a newer version of Unity, but I was reluctant to update in the middle of a project because that can be a risky thing to do. I found a workaround eventually, but the time spent trying to resolve those issues could have been spent elsewhere.
 |
| Lightmapping artifact from an Asset Store mesh |
Incomplete Planning
There is the expression which says someone "Can't see the forest for the trees." It implies a person is missing out on the big picture because they are focused on the smaller details. I often have the opposite problem, in which I can't see the trees for the forest. I see the big picture, but the small (and often critical) details are overlooked. Early on in the project, I overlooked some of these details when planning some unit abilities, and the visual aspects of these abilities (unit models, animations, etc) were not planned. The features were implemented, but during usability tests everyone playing the game was confused about what was happening--understandable, given the lack of visual cues. Better planning at the beginning stages could have alleviated this.
Tutorial
I created the tutorial as my first level, and this ended being perhaps the worst decision I made on the project. First, I had no way of scripting level sequences or events (and didn't have time to create one), so every step of the tutorial had to be hand-crafted. I had to rip apart some existing functionality in order to be able to essentially pause in the middle of something and check to make sure players performed the correct action for that part of the tutorial.
This was all very tedious, but the real problem is that other game features were being implemented or tweaked after they were created for the tutorial. If I changed the way a system worked, I would have to make sure that the tutorial version of the system was modified as well. I made numerous tweaks and adjustments to the game after the tutorial was created, so I had to rework it over and over again. Going forward, I would save the tutorial until the very end, once I was certain the game and its features were finalized.
Summary
Overall I am very happy with my capstone project. I think the design is solid, and the implementation so far is good, given the tight time constraints during the last few months. Going forward there are some areas that need a bit of work, and there are still some missing systems and features, but this was only ever meant to be a slice of the final product. There are three big areas that I will be focusing on in the months leading up to this being released as a finished product.
Systems Redesign
Knowing what I know now about Unity, there are some things I would like to go back and change. How certain classes interact with each other, how GameObjects can be created dynamically, these types of things can be improved to make it easier to integrate into other systems later on.
Level Encounters
Currently the levels in the game play out as just an arena for the two teams to shoot at each other. Long-term, I would like to have levels play out as individual scenarios, with goals or objectives for the player along the way. This will make the game feel more like a progression through the levels (and the space station in which they are located), which is one of the overall goals for the game.
Asset Creation
The placeholder assets I used for this game were fantastic overall, but they are just that, placeholders. The main character needs to be created from scratch, as do many other units and the environments themselves. Having never created much content for a mobile game before now, I look forward to the challenge of creating interesting art assets that will run well on a mobile platform.
Publish
I plan on releasing Robomancer in mid- to late-2016. I would like for it to be completely finished by then, but if only the first few levels (i.e. the demo) are complete, I will still be releasing it then, with additional content to come out later as an update.
References
Fox, J. (2016). Robomancer [Android video game]. Oviedo, FL.
