Development for Competition
It’s safe to say the notion of creating a video game has crossed the mind of almost anyone that has played one, the nearly 10,000 modifications on ModDB alone attest this. To accelerate the production of these mods, Epic Games tapped into the competitive nature of gamers and modders with the Make Something Unreal Contest. The MSUC made its first appearance in 2003, sponsored by Nvidia and utilizing the UnrealEngine 2.0. The outcome was the production of such acclaimed modifications as Red Orchestra, Air Buccaneers, and Alien Swarm. As Epic Games polished their third iteration of the UnrealEngine, they teamed up with Intel to once again revive the competition. The Make Something Unreal Contest for UnrealEngine 3.0 was announced in April of 2008.
The idea of the MSUC resonated well with my competitive personality. The thought of being rewarded for work I was willing to do for free was enticing. I participated in Phase 4 and the Grand Finals of the original Make Something Unreal Contest and revived the project for the second MSUC. It started with the typical naivety that I could single-handedly put together the greatest mod imaginable in a matter of months and claim my reward. My scope of work was way out of perspective.
It has been six years since I imported my first weapon into the Unreal Editor – an untextured bow that lacked animations and fired rockets – and I can only imagine what I would have done differently had I the modding insight I have now. I cannot say there is a definitive right or wrong way to approach modding for competition since every project is unique, but there are some general strategies I have learned that make success within reach.
The Never-Ending Design
My first mod, Archasis: Battle for Durian, was started just for the fun of it. I had been playing a lot of Team Fortress Classic as well as Day of Defeat, a WWII mod for Half-life that involved capturing flag points. My affinity for fantasy games led me to the idea of a class-based multiplayer game (TFC) with swords, bows, magic, and capture points. My “design document” was a paragraph long with a few bullet points. I started production right away and let the project evolve as I learned more about the Unreal Engine and the ins & outs of modding. Archasis was my experimental project, but the adlib design kept production moving very quickly. I used a lot of “programmer art,” which of course didn’t look great but still allowed development to move forward. By the end of the project, I had a multiplayer game with six unique character classes, RPG-like progression, and a bunch of special skills and character upgrades for players to choose from.
When the second MSUC came around, it was time to get serious about competing. A team was assembled and we got to work on a fully-fleshed out design document for Archasis II. This ended up being a disaster. No need to get specific, but basically the whole team fell apart from detail-related disagreements and a lack of motivation since there was no visible production. After several months of design, the team went from eight to two and all we had to show was a lengthy design document full of unpractical detail (of which maybe 1% is actually being used now). At that point we knew our strategy had to change, so we reverted to Archasis 1’s improvised style of design. The team focused on one core aspect of the game at a time, evaluating how time-consuming it would actually be to implement and then test it out in-game. Within a few months, we were actually hacking each other up with swords and having fun doing it!
Team Member Flux
Production since our initial turning point had been steady and fruitful, but not without trouble. Team management was a significant struggle. After the departure of the original team, the remaining members put in a huge recruitment effort to attract talent; but without content to show off our mod, our lack-luster attempts to get help failed. The team advertised “the opportunity to boost your portfolio with modding experience” as well as “the chance to compete in the MSUC and win prizes,” but with so many other promising mods in existence there was nothing unique in our offer. We managed to catch the attention of a few contributors, who offered their two cents and then vanished. Our best bet was to move forward with who we had in order to show the modding community we were serious about development.
For most of Archasis II’s development to date, the team size never exceeded more than a few active members. Since we are dealing with a competition deadline that is fast-approaching, we had to scale the scope of work to accommodate this, deciding to eliminate superfluous ideas and details that could not be accomplished with the current team. Although there is the possibility of finding additional contributors and team members before the end of the competition, we also have to deal with the possibility that the pool of available talent is empty. After all, a finished simple mod is far more effective than an incomplete complex one. Currently we find ourselves relying on the fluidity of the ad hoc design process, which allows us to adjust the direction and amplitude of development relative to the available workforce.
Involving the Community
Both Archasis mods had surges in production throughout their development, directly following their first public release. Unlike a game development company that had in-house play testers, I relied on the community for feedback. This meant I had to put together an alpha build and make it available as soon as possible. Screenshots and demonstration videos brought in valuable critiques on art-related aspects, but for me that wasn’t particularly helpful in development. After the first release of the original Archasis, my forum was instantly populated by community members that wanted to share their thoughts on the mod. The feedback ranged from “good work” to four-page design change suggestions. I wanted to please the community, but couldn’t possibly satisfy everyone, particularly with deadlines looming overhead. I filtered the critiques to those most appropriate for the mod and then explored them as viable additions or changes. The forum was a great place to do this because I could have an open, guided dialogue with the community who then became an element of the design process.
However, there were risks involved in releasing alpha builds of the mod. Plenty of trolls loved to prey on the early releases with unproductive critiques, which if taken to heart could have substantially hurt the motivation of the team. Also, some of the bugs and incompleteness of the content in early releases hindered evaluation and it was easy to overlook the completed elements. This reinforced the development team’s need to hold back on the details and solidify the basics first. The alpha releases were geared to demonstrate specific aspects of the mod, and were often a few steps behind the actual development.
Archasis II’s production had a rough start compared to the original mod, but our adjustments in workflow improved the rate of development and we have been able to get back on the competitive path. With phase 4 of the MSUC fast-approaching, the team has been working vigorously to put together something for all to enjoy and we are pleased with the direction the mod is headed. As always, the design continues to evolve and we look forward to the input of the mod community!
Written by Jamie Galimberti
Edited by Ryan Anderson