How Game Development Veterans Made the M4 Tank Brigade
War simulation game development never get old! Same goes for the creators behind M4 Tank Brigade, a WWII Tank Simulation game offering offline single player and online multiplayer combat with multiple armored vehicles where players start on early WW II tanks and progress from 1939 through 1945, upgrading better and deadlier tanks as the war progresses. Players must choose either the Axis or Allied sides.
We talked to Arnold Hendrick, Director of Game Design from iEntertainment Network and got a glimpse of what makes their studio succeed year after year. The interview turned out to almost a case study for all aspiring game development and design professionals.
Being in the industry since 1995, the time when many of you have been in short pants, a few friends who are also military veterans created their first game, a massively multiplayer flight simulation called the WarBirds, which has won numerous awards around the world since its release the same year. Following a big success of WarBirds, the team had decided to use their military experience to create other realistic and historically accurate war simulation games such as the M4 Tank Brigade. Released in 2011 and upgraded in August 2015, this game is constantly being improved in a real time, with early access offered to gamers as an opportunity to express their opinions on features that could improve the gameplay. The developers says it may take more than a year of gradual development and improvement of the 3D and UI graphics, streamline tank controls, adding an advancement system, fix irritating bugs, and add more tanks for various nations.
“We are in the process of reworking a “classic” game. It is going up against recent and well-established products,” says Arnold. “Our approach is to fix our game’s features in places where it is “behind” the competition. We are also adjusting the UI and gameplay so it emphasizes the features present in our game, and not present in competitor products.”
Defining What Works For Your Game
Arnold is one of the most experienced designers in the industry and yet he suggests that any good game development expert designer must be familiar with other games. Almost all hit games “borrow” concepts from other games (for example, “Civilization” was inspired by Sid Meier playing a lot of “Empire” for a while, and observing why he and others around the office enjoyed it).
“The trick is decide what is good or bad in other game development pieces, what ideas to borrow for your latest game, and how to merge those pieces into a harmonious product that is ‘easy to learn but hard to master,’ ” he says.
In Arnold’s opinion, storytelling doesn’t always lead to profitability, and takes World of Tanks as an example: “I believe most of the best games are where the player’s actions form a narrative story in his or her own mind”. However, SWTOR seemed to impress Arnold from a storytelling side, because player-choice was involved and they were super-well-written with the extremely professional voice acting. “The combined cost of all this is so high that I don’t see “good story” being cost effective. I’d prefer to invest 10% of that in things that help players create their own story in their own minds. I’ve found that is much cheaper, and much more engaging,” he is convinced.
4 Essential Things About Game Development
We asked Arnold to share with us his tips to smooth the design process, and he complied:
- Do spend time to create a good high level outline that clarifies all parts of the game experience and all features of the game, but preferably in less than 50 pages. This a gating item to leave concept. He recommends regular revisions during prototyping and pre-production.
- Do use shorter, smaller individual design docs for artists or engineers that give them what they build a specific part of the game. It’s best to create these “as needed” during prototyping and pre-production.
- Do not attempt to create a gigantic GDD that describes every bit of the game. Writing it takes months, nobody ever reads it all except the designer. As soon as any programmers or artists start working on it, changes occur, the GDD must be updated, and there is even less likelihood that artists and programmers will find the specific changes affect their work.
- Do attempt to document how each of the tools used to build the game work. Get artists and programmers to write up their conventions and processes. If you don’t, when those workers leave the company, their successors will be unproductive for months as they figure out how to do stuff. If you think your company will last a shorter time than some of its workers, you’re planning on failure, which is just silly.
The Hardest Part: Game Physics
Despite being very experienced in the industry, the team did hire contractors for a few items.
Arnold explains: “Our development for M4 is in three phases. The first is totally done with internal resources, the second mostly internal with some external, and the third will need a lot more external work. This allows us to evaluate progress and success potential without “blowing” a lot of money on external work”
Physics is one of the most important part in M4 Tank Brigade, because motion that impacts gameplay or game rewards must integrate smoothly with the controls and visuals. In general, player expectations of visuals are often dictated by what they see on TV or in movies. The above principles have a big effect on what physics systems are selected, how much of the physics is adjusted by game code, and how animation of physical activities interacts with gameplay.
For example, tank and airplane games have custom-built physics engines to represent vehicle activity, and they build around them supporting animations. In an MMORPG with hand-to-hand combat, animation routines must integrate with gameplay with great care (i.e., designers and artists work together). Off-the-shelf physics engines, like ragdoll explosions and kinetic reactions, is simply another animation tool that might or might not work for the game at hand.
One of the things that is always neglected is keeping the UI system documented, and Arnold insists on it: “I know I’ll need to borrow from it to write instruction manuals, hints and tips, etc. Similarly, I like to keep all charts or files of in-game data up to date and human readable (typically Excel), so testers and live team operators have a quick, easy way to see if the game works “as expected.” If changes are made, I want to record what those changes are. If not, after a month or two you start forgetting, and that leads to ridiculous amounts of rework.”
During the later stages, they may also have certain types of documentation so they can bring in outside contractors and volunteers so they can work productively with appropriate instructions and guidelines.
Project Management: Communication is a Key
When starting a project, based on his tremendous experience, Arnold strongly emphasizes the following important things to remember:
Following a six stage program: concept, prototype, pre-production, production, beta-testing, live operation – including updates, expansions, DLCs, etc. As a producer (instead of designer), he insists the bigger is the project, the better the team must adhere “gating requirements” for transitioning from one stage to another.
The one advice that can be applied to any project is having practical, sensible, well trained, and game-industry-knowledgeable project management. Arnold’s recommendation is insisting that all Producers and Project Managers have and maintain both a CSM and a PMP. If nothing else, a PMP insures a level of honesty and professionalism sorely lacking in many parts of the industry.
Production staff should have at least a couple years experience developing games in one of the major disciplines of games – be it design, programming, art or QA.
Daily stand-ups and end-of-scrum retrospectives work very well, even with a virtual team. Even if the video doesn’t work, talking via Skype to the team almost every day creates a sense of personal knowledge and camaraderie that is invaluable to achieving amazing results in very little time. A half hour extra conversation can save hours of rework.
Close coordination between design, engineering and art e.g talking daily while looking at the program running, or the art happening on screen, can cut down on the cost and time to develop game components. The longer any of these people are off on their own, the more rework is required.
Arnold suggests using Rally for Scrum: “It works well for me because I’ve used it for six years now and understand its UI problems, and how to get around them. I do not recommend it for organizations unfamiliar with Rally or Scrum. If Rally would hire a good UX designer, and commit to one consistent UI long enough to make the whole program work together seamlessly, it would be great. Until then, expect a steep learning curve for scrummasters and product owners”.
“I refuse to schedule or plan crunch for any project. In the last 15 years, I’ve only asked for crunch once, it was only for 3 weeks, and I made sure I was there every minute the team was there,” adds Arnold. “Doing anything else is so unethical I refuse to consider it. Instead, we cut features or change the schedule. This is one of the great “learnings” in Scrum. Usually the schedule is not movable either. Therefore, as a producer, you’re constantly figuring out what you can cut back to get back on schedule.”
“Many times, in retrospect I’ve found that features we thought were important, but had to cut due to schedule (and no crunch), would not have changed the game’s success (or failure) when released. A good designer (or producer) will scream bloody murder if truly key features must be cut. At that point you work carefully with them to figure out the core elements of that feature, do those, and leave all the “bling” in the backlog for later. If this isn’t enough, you examine features you hadn’t plan to cut, and see what pieces you can remove or postpone. Surprisingly, many times just doing the core elements of a feature is good enough.”
“For example, an MMORPG design team desperately wanted player housing, but the game shipped without it, and did very well anyway. A number of updates later, player housing was finally added.”
Resources: What To Do When You Lack Them
Despite being very successful, iEntertainment Network experiences a lack of the resources, as do most smaller companies. Arnold was quite frank about his experience and told us that in 32 years of designing and producing computer games of all types he has never worked on a game development project with unlimited resources. To solve this problem, he is planning to outsource in later stages using a combination of an external development team to build a new 3D engine, hire professional 3D object artists for sample asset construction and art path documentation, and use semi-pro and volunteer labor for some production art and game data. Audio SFX will be also purchased where they lack existing clips. They are planning to outsource music as well. Being a musician himself, Arnold knows how to talk to young but promising composer-performers.
“You can get some great people if you look beyond someone’s latest experience, examine all their abilities, and have high expectations.”
Unit Tests and Focus Groups
Really high risk code can benefit from code reviews, but they are costly in staff time. Instead of code reviews, Arnold strongly advocates that engineers write unit tests that will continue to work throughout the life of the project. If new additions to the project prevent old unit tests from working, the automatic response should be to immediately rewrite the unit test so it does work. “I have seen a good battery of unit tests catch vital stuff that human QA or code reviews would never catch, or take ages to diagnose. I expect the full battery of unit tests to run right after the nightly build, before people get in the next morning. Test failure info should be automatically waiting as emails in the appropriate in-boxe, so people can include test failure info and fixes in the daily standup”.
Focus group testing is the best way to gather game feedback and application data, continues Arnold. If the designers and producers have the discipline to watch carefully and understand what they see, it can reveal important issues.
Fundraise, Market, Monetize!
iEntertainment Network includes a fundraising team, lead by the CEO, who raise investment money through a variety of sources. This money, along with income from existing games, determines their budgets.
iEntertainment Network (IENT) publishes its own products via Steam, Apple iTunes, Google Play, the web (mostly for legacy products), on various content platforms. The first four are the many sources of their revenue. They have found the downloads/revenue ratio of Google Play to be disappointing in comparison to iOS. IENT considers Steam a great platform, because getting a greenlight approval is rather difficult. This raises the value and earnings of each game that actually gets onto a Steam store page. Unlike with Steam, game discovery on mobile may be a huge problem, so they hire a PR firm to help raise awareness and visibility of their products.
He also reveals that iEntertainment Network uses almost all known ways of monetization in their games: up-front purchase, monthly subscription for online play, and F2P monetization using owned items (like weapons) as well as expendables (weapon repair, ammunition, energy to play more). However, different games use different monetization methods. Arnold is planning to put them all in an upcoming PC product.
Arnold suggests that despite a de-prioritizing of game development analytics by top management, it is very important for success, so he is learning to build in analytics on the go. “If you wait until “later” analytics never go in. The first analytics questions are about where we’re earning money, and the second is about how long players are in the game, and where they’re dropping out. However, during development, it’s easier to get the second set of questions working first, then add the financial questions as you are closer to release”. Integrating advertising campaigns with analytics is always helpful. For any specific ad campaign, marketing may not take the time to look beyond the CTR to see how many started a download, how many finished a download, and how many even entered the game.
Finding the Right Door
Arnold started in computer game development at Coleco, a big successful toy company that was one of the “big three” in first generation console games in the early eighties. Since then he has always been involved in gaming industry. He is confident that the game development door is always open. “If you have the good people and make wise choices about what area of game development technology to specialize in, you can make successful games,” he resumes. Arnold recommends against social and mobile because they are over-saturated with product, but suggests that there are opportunities in PC gaming and even greater opportunities in VR gaming. However the risks are much higher, because no one knows which VR hardware system will win. There is also a potential play in TV service platforms, such as Apple TV.
Arnold thinks that their games are successful because they have gameplay experiences not found in other games – and we strongly agree with him!
“We’re not rich enough to stomp the competition into the ground with big-budget higher quality everything. Instead, we have to know what makes a product special and different, and play to that”.
About iEntertainment Network
iEntertainment Network, Inc.(IENT:OTC US), formerly known as Interactive Magic, is a provider of online entertainment communities and publisher of online and retail games. It is based in North Carolina, U.S.A. It was founded by JW “Wild Bill” Stealey, the co-founder and former CEO of MicroProse Software with Sid Meier, a game developer. IENT currently operates WarBirds, M4TankBrigade, BowHunter2015, Outdoors Unlimited, and the IamGame.com.