The Pivot
We started the project with a wide open possibility space, but the frontier is a dangerous place. It’s not uncommon for pitch projects at the ETC to over-scope and we had the added unknowns of new technology, being used in new ways. Local multiplayer networked AR is a new area with few to no guideposts. It turns out that our designs were very optimistic, compared with the reality we found.
So where do we go from here? We re-evaluated and made some hard choices about our goals and how to spend the time we have left. We originally hoped to have a finished game at the end of the semester. Our new plan is to finish a proof of concept slice of the game, along with a design document showing the existing features and where they could be extended. Something that we could show to developers to prove out the potential of our concept. Let’s take a look at some specifics.
Plan A
Our earlier designs were not very efficient from a cost/benefit perspective. We did a good job picking out our core features for the minimum viable product that we built, but many of the features we planned for later just don’t get us the same bang for our buck. Here are the actions we originally planned to build:
- Scanning and internal scanning for the academy faction
- Shields & point defenses for the outlaw faction
- Repair & repair beams for the crusade faction
- Harpoons & ramming jaws for the raider faction
- Scrambler attacks & lockdown turrets for the hierarchy faction
- Harvesting and broadcast harvesting for the carnival faction
- Selling cargo for points
- Laser attacks
- Flak cannon attacks
- Boarding actions
- ordinance & fighter attacks
- Stealth & fog of war
- 3D AR Movement
After going through the process to build our MVP and finding out how much overhead is involved with each new action we now know how many different kinds of actions are actually feasible in our time-frame:
- Shields
- Harvesting cargo
- Selling cargo
- Laser attacks
- 3D AR Movement
That’s a pretty big difference. On the bright side, this process has taught us a lot more about estimating feature development time. Also, this shined a light on how inefficient our previous designing was. Many of the above features were used by only 1 or 2 factions so even though they took similar amounts of work, a given player may never see them. So we went back to the drawing board and designed our game and fleets of ships around those mechanics that we knew we could have.
We had designed 48 ships for the game. We had 6 factions, each with 2 kinds of ship that come in 4 sizes. This again meant that a given player can’t see most of the content in one play-through. That makes for great replay value in a AAA product, but it isn’t right for a student project. Also, many of our ship types were designed around a faction-specific action. If repair beams don’t make it into the build, well there goes the rescue ship class.
The 6 ship option
Instead, we built our ship types around 4 qualities: attack, defense, movement speed and cargo storage. If each kind of ship is good at two of those, that gives us 6 types.
- Battleship: good offense and defense
- Cruiser: good offense and speed
- Scavenger: good cargo and attack
- Freighter: good cargo and defense
- Blocker: good speed and defense
- Scout: good speed and cargo
As we designed these ships we realized that the 4 qualities gave us more design space than we thought. Under “attack” we have diversity in the quantity of firing arcs, damage output and range. Defense gives us different shield arcs, and different total shield strength. Under movement we have the distance a ship can travel in a turn as well as how much they can pivot. Storage determines both how much cargo you can hold in a given run as well as which directions you can harvest from. In retrospect, this system gives us plenty of variety to work with.
Faction Differences
We planned to have a fleet-selection process where players could choose a few big ships or lots of small ships. Instead of faction-specific actions we brainstormed faction traits that would modify their base stats or behaviors. Here are a few:
- Long-Range Delivery (sell action): You can sell cargo from double the distance away
- Reflector Shields (defend action): When your shields are hit there’s a ⅓ chance to deal ⅓ of the damage back to the attacker
- Transporter Blasters (attack action): When your attacks hit there’s a ⅓ chance to steal 2 cargo from the defender
- Disruptor Blasters (attack action): Your attacks have a ⅓ chance to deal ⅓ more damage
- HIgh-Efficiency Mining (harvest action): When you harvest you are twice as likely to find gold
There were some problems with this approach though. We were still thinking like board game designers. For a board game it takes only minutes to write out the above on a player’s card but coding some of these would take much longer. From the art perspective, the shift to giving each faction the same 6 ships meant that we no longer had distinctive models for the ships. Factions would only look different based on texture color, which meant we were throwing out a lot of our visual design work and losing some of the character of the game. Also, from talks between designers and programmers, we learned that giving players a variable quantity of ships was not feasible.
Pre-Built Fleets
Our third design managed to both cut development time and improved several other aspects. Now we plan to fold the fleet selection into our existing faction-select screen. Instead of faction abilities, each faction has a ready-made fleet of one big and two small ships. Now there’s no need for a separate menu, onboarding is faster and players can see all the options, even if they only play with a few of them. Each player also gets the chance to experience all of our core mechanics. As an added bonus, since each faction will only have access to 3 ships, we may be able to put in more decorative distinctiveness into those ships and inject more flavor into the game.
It is painful making big changes and cutting features that have already been planned out or have existing art already made, but it was necessary. With our new scope we can spend time polishing the core interactions and making quality-of-life changes to make our interface more user-friendly. Some of these structural simplifications even have a positive effect on the user experience.