Over the last six weeks, we’ve been prototyping our major project – A Wizard Did It. AWDI is a 4-player asymmetrical multiplayer game, with one team focusing on action team-based gameplay and the other on strategy and manipulation. One team is the Heroes – 3 players who are working together to defend their castle from the oncoming horde of monsters, which are being summoned by the other player, the Wizard. The following is a list of what went wrong, what went right and we’ve learned from developing our prototype.
What Went Right
AWDI relies completely on it’s multiplayer – a singleplayer mode was never planned or intended, and we’ve managed to implement multiplayer that’s not only functional, but very well polished. Actions occur for both players simultaneously, and we don’t have any real synchronization issues in the final build. Since our focus for the prototype was to set up the groundwork for the bulk of development in the next trimester, this is a huge win for us.
This was a big worry going into the project, and it was an equally big challenge – developing an asymmetrical game is essentially developing two games that are fun not only on their own, but when played together. It’s too early to give a definitive answer as to whether our design’s going to pan out nicely, but as of the prototype both sides of the game are good fun to play and function well together. The logic is consistent across both modes – either way, the crystal’s the goal. and the monsters are the key to either your destruction or your downfall. It’s very easy for players to understand the mechanics of both sides, which was also a concern of ours. Developing the prototype’s given us the confidence that – assuming we do our jobs properly – we’re onto an idea that’s actually a lot of fun to play, and seems to have a good amount of appeal.
For our prototype we used a fair bit of asset store meshes and materials (purely for the sake of saving time) to get our art style across, and it worked well. The final prototype build isn’t quite where we envisioned it in terms of art, but it’s very close – certainly more than close enough for what we actually needed to show. We’d always planned for AWDI to have a very “cartoony” art style, and it’s apparent in every screenshot that we’ve accomplished that.
What Went Wrong
A massive part of AWDI (arguably the biggest part) is how monsters act and react in the game world. Our plan for the final build is to have them running around the castle doing things, like destroying buildings and kicking over buckets. At present, they’re just…pretty awful, really. They don’t navigate the game world very well, and are frequently getting stuck on terrain. This wasn’t a problem with our implementation so much as it was a problem with our pipeline – we simply tested the AI too late. It was great that we learned this in our prototype, though, as we now know to use greyboxes to test the navigation before we finalise anything.
I’m a little hesitant to put this in the “what went wrong” section, because it’s an issue we knew would be present in this build all along and opted to work on other features instead. So this didn’t “go wrong” so much as we let it “be wrong”, but our prototype doesn’t have much in the way of player feedback, whether positive or negative. Hitting monsters isn’t satisfying, and being hit doesn’t worry players the way it should. We’re conscious of the importance of feedback and plan to spend a lot of time developing and polishing it during main development next trimester, but as of the prototype it’s sorely lacking.
During the course of developing our prototype, we’ve done a lot of documentation – I’d say more than ever. However, most of it has become irrelevant in the face of what we’ve learned from our prototype. This is actually normal – it’s why you develop a prototype and have several GDD versions – so that’s not the problem. Our problem is that the documentation hasn’t been updated since, and needs to be for next trimester. There’s still time to get that done, but it means that as of our deadline, our documentation isn’t up to par. We could’ve potentially avoided this by finishing our prototype earlier and getting testing done, though there’s every chance that would’ve left us with a less polished prototype and less useful feedback, so it was always a hard choice.
What We’ve Learned
Have awful players test your level (or game)
While we didn’t spend as much time testing as we could have, those that did play the game were all experienced gamers, which is a problem. People who play a lot of games are, of course, much better at them – gathering feedback exclusively from people who are good at something just isn’t that helpful by itself, as average-or-worse players are going to have much lower performance, leading to our game being overtuned for skilled players to the detriment of the majority. In the case of AWDI, it’s important for players to quickly navigate around the level, as well as tell where the monsters are in relation to their current position. After developing and testing our prototype, we don’t really have a definitive answer as to how difficult it is to navigate our level, which is something we’ll look to as soon as possible.
Game design is hard; Asymmetrical game design is harder
I’m not sure we ‘learned’ this so much as we expected it, but it’s still true – designing an asymmetrical game can be kind of a nightmare. At first, we assumed the difficulty would come mostly from balance (and that’ll almost definitely be the case in the future), but for our prototype we actually had a very difficult time designing the level. For a long time we were trying to develop a square level where enemies could come from all directions, and each of us went through dozens of designs that all had big flaws for either the Heroes or the Wizard. Eventually, we realised a rectangular, linear design was the answer – if the Wizard had to push his or her forces into the castle from a specific direction, it not only lent itself well to the gameplay, but also to the idea, theme and feel of a siege. This seems mighty obvious in hindsight, but we spent a couple of weeks on this design problem until we solved it by scribbling in MS Paint and arguing about it (which is typically our main design process). Still, having an asymmetrical game is bringing in all sorts of new challenges, for better or worse – I don’t doubt we’ll be facing a lot more in the near future.
From here, AWDI is entering the bulk of development. We plan to redevelop the prototype with what we’ve learned in order to use it as the base model of our main project, fix up some documentation, play an ungodly amount of Metal Gear Solid V and then get into development proper shortly before our final trimester. I’ll be posting updates and information on my blog as we go, so stay tuned! Thanks a lot for reading.