Postmortem: SkyScrappers

SkyScrappers

SkyScappers was developed by a team of seven developers in over 650 man-hours at the Guildhall@SMU. The game mocks corporate greed in a competitive multiplayer game set in a futuristic mega conglomerate advertising war. Players control robot taggers to dominate electronic billboard control points and use fast-paced first person shooter tactics to knock opposing corporation taggers off the advertising space at the tops of skyscrapers. This postmortem represents what went well, what went wrong, and lessons learned during the game’s development.

What Went Well:

HUD

SkyScrappers’ game modes, especially its domination mode, required the conveyance of a large of amount of information to the player. We decided early in development to tackle this issue. Work on the HUD began in the Vertical Slice milestone, about two milestones earlier than the other teams, allowing plenty of iteration time.

As it turns out, HUD design was more difficult than we anticipated. Things as simple as team color and team score needed constant rework, and many other student teams did not have enough time to test and implement changes to the HUD. The extra iteration time given to SkyScrappers’ HUD design resulted in a stylish user interface that conveyed information quickly and easily.

Figure 1: Game poster by Nick Clark and DiVionte Gorham

Flexibility for members to take on different tasks

One of scrum’s many strengths is the ability for team members to take on any task, regardless of discipline. For SkyScrappers, the art team was extremely busy with building the in-game models and did not have enough time for particle creation. Scrum allowed the producer and a few level designers to step in and take on the tasks associated with particles, offloading a large burden from the artists.

Weapon balance

SkyScrappers was praised by many students at the Guildhall for having the most fun and unique weapons. This was the result of countless playtests and balances. We knew from the beginning that the weapons would be a focus for the game, and began rapid prototyping the weapons very early in development. Through many playtest sessions, the weapons of SkyScrappers went through a variety of changes. Some weapons like the flamethrower and the mine launcher were cut entirely, while other weapons’ firing modes were shifted from one gun to another. All of the aforementioned changes contributed to creating a weapon system that was accessible and enjoyable.

Figure 2: Environmental concept review by Nick Clark and DiVonte Gorham

What Went Wrong:

Network

SkyScrappers marks the team’s first time working on a competitive multiplayer game, which required extensive work on networking. While the team performed constant playtests on the weapons and HUD, not enough time was dedicated to playtesting over the network. Initially, network testing was conducted once a week. We soon discovered that once a week was not enough.

In early milestones like proof of concept technology and proof of concept gameplay, the build of the game was often unstable due to network problems. Replication issues were everywhere: scores and health were not displaying properly over the network, and characters were holding their weapons backwards. The team eventually fixed most of these issues by including more network testing in later milestones, but some minor network bugs still carried over into the final build.

Unfamiliarity with UDK

The Unreal Development Kit is a powerful development tool. It is the most versatile game engine the team has used to date. However, SkyScrappers was the first game the team built in UDK, and introduced a significant learning curve for many members. Before SkyScrappers, few team members had worked with Kismet and Matinee, and none had worked with Cascade. The team ran into many problems with light maps and BSPs and spent a lot of time on particle creation. Many of these problems had simple solutions, but inexperience with UDK’s tools took up more time than initially anticipated.

Art style not locked down early enough

While SkyScrappers delivered a simple and cohesive art style at the end, it had a rough beginning. The game received a very short pre-production, and we allocated most of that time to ironing out the game’s mechanics. Not enough time was spent on art concepts, which resulted in problems for early milestones. Because the style of the game was not fully fleshed out, the game’s visuals lacked a sense of cohesion. Weapons looked entirely different from one another and some meshes did not match the environment. Due the lack of a solid art direction early in development, many of the game’s assets had to be recreated. All weapons went through multiple remodels and retextures, costing valuable development time.

Lessons Learned:

SkyScrappers proved to be a great learning experience for the team. The term, “Test early, test often” holds especially true for game development. Many of the issues of SkyScrappers could have been fixed if they were spotted early enough. While the team playtested the weapons and HUD of the game extensively, more time should have been allocated to network testing. Additionally, we learned that conveyance of a game is extremely important. A game can have the most fun mechanics in the world, but if the player cannot understand them, the fun factor of the game is of little importance.