Kwari
Multiplayer levels for Kwari
(Level design)
Page contents
- Summary
- Screenshots
- Design post-mortem
Summary
The multiplayer First Person Shooter 'Kwari' is the published game I worked on while at Micro Forte: my first game in the industry. The exchange of real money between players was incorporated into many of the game's systems from the ground up, in a way that had not been attempted before. This had an enormous influence on virtually every aspect of the game's design - including the level design. The layout, item placement and flow of each level were influenced by the special requirements the real money elements created. It was a very interesting project to work on.
At the time of writing, getting access to the game at short notice to take a few screenshots was a little impractical (special secure servers being a requirement), so below are a few screenshots I was able to scrounge up from around the Micro Forte studio. I took these shots towards the end of development on the game: mostly as a record of minor art asset errors that needed to be fixed.
These screenshots show my 'Drilling Machine' level - one of four total levels in the published game. I designed several other levels for the game, but the art was all outsourced - and the outsource company ran out of time to do the art for those levels. The game was developed in 14 months: a fairly brutal schedule for a game of this type.
The geometry seen in these shots is largely unchanged from my block map version of the level, but the texture work was performed by the outsourced artists contracted to this project.
Incidentally, I also did some writing for the Kwari project: notably an account of the game's back-story to be used on the official website and for other marketing purposes, plus some of the script for the player and announcer speech. I also made a few miscellaneous art assets (skybox textures, for example) used in the game.
See after the screenshots below for a design post-mortem on the level design aspects of the game.
Screenshots
Design post-mortem
Summary
This post-mortem focuses on the level design in Kwari - as I was a level designer on the project - but I will make a short summary of the main ideas behind the game here, to give appropriate context. This is not a post-mortem on the project as a whole, as that falls beyond the scope of my responsibilities on the project, and so is not strictly relevant to my portfolio.
Money affected everything. Kwari was designed as a multiplayer first-person shooter which was free to download, but to play the game against other people online, a player had to purchase in-game ammunition using real money. In addition, every hit a player scored on an opponent resulted in a small sum of money being transferred from the player hit to the player doing the shooting. Weapons and power-ups (such as health pick-ups) would also cost a small amount to pick up.
Each match in Kwari played out in normal 'deathmatch' fashion - every player for him/herself - up until a point near the end of each five minute match, when the 'Pill' pickup was spawned. An on-screen indicator appeared that showed the location of the Pill at all times, and the objective for each player was to collect the Pill and then hold onto it for as long as possible. The Pill was dropped if the player carrying it was killed, and another player could then pick it up. The incentive to hold the Pill was that the player holding it for the longest would win half the 'jackpot' (comprising the money all players paid during the match for picking up weapons and power-ups), and the player holding the Pill at the end of the match would win the other half. This could result in one person winning both halves of the jackpot.
Those are the main factors that made Kwari a unique game. The influence of real money on virtually all aspects of the game certainly threw up some unique challenges to the level design, and I'll comment on those here; along with the strategies we developed to solve those challenges.
Design considerations
On the surface, the core gameplay of Kwari has a lot in common with games like Quake 3 and the Unreal Tournament series: focused multiplayer FPS games. A player spawns into a match with a number of other players, everyone runs and jumps around in a 3D environment trying to shoot everyone else, while trying to avoid getting shot themselves. If a player is killed, they respawn at a randomly chosen location a short time later. A player starts with a single weapon when they spawn, but can pick up additional weapons at defined weapon spawn-points around the environment. Pick-ups that restore a player's health or provide some other benefit can also be collected at defined spawn-points.
In this type of game, levels are usually designed in in a particular way in reliance on these gameplay mechanics. Players are encouraged to move around a level (in part) by a kind of breadcrumb-trail lure mechanism: weapons and power-ups are placed to catch the player's eye and draw him/her from one part of the level to another. A player might choose to take a particular path because they will run over the top of a health pick-up along the way and reach a powerful weapon at the end of it. In Kwari, it was not quite this simple.
Since players had to pay real money to pick up weapons and power-ups in Kwari, we decided it was very important that players should - as much as possible - have a choice whether or not to pick any one item up. This led to a decidedly different item-placement strategy: pick-ups were placed off to the side of the ideal paths taken by players, rather than right in the middle of those paths. In another game this would be inefficient; requiring the player to go out of their way to collect pick-ups - but in Kwari it allowed the player to make a conscious decision about spending the money on the pick-up in question or not.
This made it a little more difficult to place pick-ups in optimal locations for catching the player's eye and drawing him/her through a doorway into another area (for example), but it was decided to be necessary.
Another common strategy in level design - and in particular, item placement - is related to the concept of risk versus reward. A particularly powerful weapon may be placed in a location that may be risky for a player to reach (say, in a location that is particularly exposed to fire from other players), for example. For Kwari, however, it was decided that since players had to pay to pick these weapons up, and they may have a favourite weapon or two, no one weapon should be more difficult to collect than another, ideally.
This limited our ability when designing levels to rely too heavily on this kind of risk versus reward style of pick-up placement (though there were still a few power-ups that could be used in this way), so we would have to make the levels engaging in other ways.
Still on the topic of pick-ups, there were no ammunition pick-ups in Kwari at all, since the player purchased ammunition with real money. This further limited our options in using pick-up placement to influence the paths players would take through a level. There was not the option for us to place a powerful weapon in one part of a level, and ammo for that weapon in another part of the level to encourage players to move about more.
Our brief for Kwari called for the game to be accessible for people that may not have played FPS games before, and we designed the levels with this in mind. This largely led to levels that contained a number of fairly open spaces and featured easy-to-learn layouts. Our reasoning here was that maze-like levels would be quite disorienting for new FPS players in the moment-to-moment short term, and also prove frustrating to learn the layout of in the medium-term.
This would be disastrous for Kwari - perhaps even more-so than other FPS games, since Kwari's business model depended on players sticking around long enough to reach the 'long-term'.
At the same time, however, we didn't want to drive away more 'hardcore' FPS gamers, so we tried to reach some middle-ground between the two extremes: levels that were simple to navigate and learn for someone new to FPS games, but still provided opportunities for more experienced players to utilise their skills in engaging ways.
What was successful
The levels we made (including my own, of course) were fun to play. This may go without saying, but we play-tested the levels a lot - over many months, and they were always enjoyable; we didn't seem to get sick of them. Mostly it was the other level designers and I play-testing them, but on Friday afternoons the whole team was strongly encouraged to the play the game as it stood at that point. On these occasions the studio somewhat took on the atmosphere of a LAN party: yelling, cursing, cheering, etc. Everyone enjoyed the game - and the levels specifically.
I tend to view this as an indication that the strategies we used to solve the design challenges mentioned above were successful.
Early on in the project we developed conventions for the dimensions of virtually everything that would make up the environments in our levels: for example each 'room' should be no smaller than 'this' size, ceilings should be at least 'that' high, stairs, a second storey should be exactly 'this' high above the ground floor, ramps and slopes should be on exactly 'this' angle, etc. This approach was a tremendous benefit in a number of ways: it made consistency of art and gameplay across different levels (and level designers) easier to achieve, it made possible the development of a set of 'universal' props that could be used across all levels (even those with disparate settings), other team members could safely make certain assumptions when performing their own roles without worrying too much about what they were doing conflicting with parts of levels, and I know that for me at least, it made it easier to divide things up mentally into component building blocks when designing a level.
It was almost like building with lego blocks in my mind, and streamlined the process for me. I went on recently to use the same strategy to (I believe) good effect in my DM-Courtyard level for Unreal Tournament 3.
What could be improved
Early on in the project, the focus in designing levels was almost completely on gameplay concerns, and only lightly on creating environments that believably represented their intended setting. The assumption at that early point was that to do otherwise would perhaps tread on the toes of the (outsourced) artists that would be crafting the visuals for the levels.
Over the course of the project, the balance shifted towards us (level designers) putting more and more detail into our block maps; to aid the artists in their roles, and to hopefully avoid the creation of art that would interfere with our intended (and play-tested) gameplay. This led to the loss of some time to re-doing levels or parts of levels a few times, and possibly could have been avoided with a more defined strategy for these things being in place earlier in the project.
Another issue was that there were some communication problems with the outsourced artists employed for the project. With the exception of a technical artist and two concept artists, all the artists on the Kwari project were based in India. There are perhaps a lot of reasons why communication may have sufferred; fairly different time zones, limited bandwidth making exhanging files between studios a slow process, potentially language issues, communication being filtered through Leads and related to others (notably on their side, but also ours to a lesser extent), among other reasons.
These communication problems created a few issues, the most problematic being the creation of art assets that negatively impacted on the established gameplay in our levels. That these art assets had to be fixed was time consuming in and of itself, but the often lengthy process of documenting these problems in order to give feedback to the artists so that they knew what to fix meant even more time was 'lost' to fixing problems.
It is tempting to simply say that most of these communication problems could be 'easily' solved by employing in-house artists rather than outsourced ones (it being much easier to stand next to someone and point at something and say "this is the problem here" than it is to describe a problem in words and screenshots). Of course this is not always possible, so there must be ways in which a working relationship with outsourced artists can be improved.
Whatever these solutions may be (it is a bit beyond the scope of this post-mortem to speculate on that sort of thing), having systems in place to ease communication between us and the outsourced artists would have drastically sped up production.
Conclusion
Considering some of the challenges faced in the Kwari project (a very tight development timeframe, my first project in the industry, and designing to a somewhat new and unique brief/business model, just to name a few), I believe my work on the project was quite successful. People enjoyed my levels, and I found the other team members (both the other level designers and the team as a whole) easy and enjoyable to work with.
It was certainly the most fun I've ever had on a job. :-)
[return to top]
(Level design)
Page contents
- Summary
- Screenshots
- Design post-mortem
Summary
The multiplayer First Person Shooter 'Kwari' is the published game I worked on while at Micro Forte: my first game in the industry. The exchange of real money between players was incorporated into many of the game's systems from the ground up, in a way that had not been attempted before. This had an enormous influence on virtually every aspect of the game's design - including the level design. The layout, item placement and flow of each level were influenced by the special requirements the real money elements created. It was a very interesting project to work on.
At the time of writing, getting access to the game at short notice to take a few screenshots was a little impractical (special secure servers being a requirement), so below are a few screenshots I was able to scrounge up from around the Micro Forte studio. I took these shots towards the end of development on the game: mostly as a record of minor art asset errors that needed to be fixed.
These screenshots show my 'Drilling Machine' level - one of four total levels in the published game. I designed several other levels for the game, but the art was all outsourced - and the outsource company ran out of time to do the art for those levels. The game was developed in 14 months: a fairly brutal schedule for a game of this type.
The geometry seen in these shots is largely unchanged from my block map version of the level, but the texture work was performed by the outsourced artists contracted to this project.
Incidentally, I also did some writing for the Kwari project: notably an account of the game's back-story to be used on the official website and for other marketing purposes, plus some of the script for the player and announcer speech. I also made a few miscellaneous art assets (skybox textures, for example) used in the game.
See after the screenshots below for a design post-mortem on the level design aspects of the game.
Screenshots
Design post-mortem
Summary
This post-mortem focuses on the level design in Kwari - as I was a level designer on the project - but I will make a short summary of the main ideas behind the game here, to give appropriate context. This is not a post-mortem on the project as a whole, as that falls beyond the scope of my responsibilities on the project, and so is not strictly relevant to my portfolio.
Money affected everything. Kwari was designed as a multiplayer first-person shooter which was free to download, but to play the game against other people online, a player had to purchase in-game ammunition using real money. In addition, every hit a player scored on an opponent resulted in a small sum of money being transferred from the player hit to the player doing the shooting. Weapons and power-ups (such as health pick-ups) would also cost a small amount to pick up.
Each match in Kwari played out in normal 'deathmatch' fashion - every player for him/herself - up until a point near the end of each five minute match, when the 'Pill' pickup was spawned. An on-screen indicator appeared that showed the location of the Pill at all times, and the objective for each player was to collect the Pill and then hold onto it for as long as possible. The Pill was dropped if the player carrying it was killed, and another player could then pick it up. The incentive to hold the Pill was that the player holding it for the longest would win half the 'jackpot' (comprising the money all players paid during the match for picking up weapons and power-ups), and the player holding the Pill at the end of the match would win the other half. This could result in one person winning both halves of the jackpot.
Those are the main factors that made Kwari a unique game. The influence of real money on virtually all aspects of the game certainly threw up some unique challenges to the level design, and I'll comment on those here; along with the strategies we developed to solve those challenges.
Design considerations
On the surface, the core gameplay of Kwari has a lot in common with games like Quake 3 and the Unreal Tournament series: focused multiplayer FPS games. A player spawns into a match with a number of other players, everyone runs and jumps around in a 3D environment trying to shoot everyone else, while trying to avoid getting shot themselves. If a player is killed, they respawn at a randomly chosen location a short time later. A player starts with a single weapon when they spawn, but can pick up additional weapons at defined weapon spawn-points around the environment. Pick-ups that restore a player's health or provide some other benefit can also be collected at defined spawn-points.
In this type of game, levels are usually designed in in a particular way in reliance on these gameplay mechanics. Players are encouraged to move around a level (in part) by a kind of breadcrumb-trail lure mechanism: weapons and power-ups are placed to catch the player's eye and draw him/her from one part of the level to another. A player might choose to take a particular path because they will run over the top of a health pick-up along the way and reach a powerful weapon at the end of it. In Kwari, it was not quite this simple.
Since players had to pay real money to pick up weapons and power-ups in Kwari, we decided it was very important that players should - as much as possible - have a choice whether or not to pick any one item up. This led to a decidedly different item-placement strategy: pick-ups were placed off to the side of the ideal paths taken by players, rather than right in the middle of those paths. In another game this would be inefficient; requiring the player to go out of their way to collect pick-ups - but in Kwari it allowed the player to make a conscious decision about spending the money on the pick-up in question or not.
This made it a little more difficult to place pick-ups in optimal locations for catching the player's eye and drawing him/her through a doorway into another area (for example), but it was decided to be necessary.
Another common strategy in level design - and in particular, item placement - is related to the concept of risk versus reward. A particularly powerful weapon may be placed in a location that may be risky for a player to reach (say, in a location that is particularly exposed to fire from other players), for example. For Kwari, however, it was decided that since players had to pay to pick these weapons up, and they may have a favourite weapon or two, no one weapon should be more difficult to collect than another, ideally.
This limited our ability when designing levels to rely too heavily on this kind of risk versus reward style of pick-up placement (though there were still a few power-ups that could be used in this way), so we would have to make the levels engaging in other ways.
Still on the topic of pick-ups, there were no ammunition pick-ups in Kwari at all, since the player purchased ammunition with real money. This further limited our options in using pick-up placement to influence the paths players would take through a level. There was not the option for us to place a powerful weapon in one part of a level, and ammo for that weapon in another part of the level to encourage players to move about more.
Our brief for Kwari called for the game to be accessible for people that may not have played FPS games before, and we designed the levels with this in mind. This largely led to levels that contained a number of fairly open spaces and featured easy-to-learn layouts. Our reasoning here was that maze-like levels would be quite disorienting for new FPS players in the moment-to-moment short term, and also prove frustrating to learn the layout of in the medium-term.
This would be disastrous for Kwari - perhaps even more-so than other FPS games, since Kwari's business model depended on players sticking around long enough to reach the 'long-term'.
At the same time, however, we didn't want to drive away more 'hardcore' FPS gamers, so we tried to reach some middle-ground between the two extremes: levels that were simple to navigate and learn for someone new to FPS games, but still provided opportunities for more experienced players to utilise their skills in engaging ways.
What was successful
The levels we made (including my own, of course) were fun to play. This may go without saying, but we play-tested the levels a lot - over many months, and they were always enjoyable; we didn't seem to get sick of them. Mostly it was the other level designers and I play-testing them, but on Friday afternoons the whole team was strongly encouraged to the play the game as it stood at that point. On these occasions the studio somewhat took on the atmosphere of a LAN party: yelling, cursing, cheering, etc. Everyone enjoyed the game - and the levels specifically.
I tend to view this as an indication that the strategies we used to solve the design challenges mentioned above were successful.
Early on in the project we developed conventions for the dimensions of virtually everything that would make up the environments in our levels: for example each 'room' should be no smaller than 'this' size, ceilings should be at least 'that' high, stairs, a second storey should be exactly 'this' high above the ground floor, ramps and slopes should be on exactly 'this' angle, etc. This approach was a tremendous benefit in a number of ways: it made consistency of art and gameplay across different levels (and level designers) easier to achieve, it made possible the development of a set of 'universal' props that could be used across all levels (even those with disparate settings), other team members could safely make certain assumptions when performing their own roles without worrying too much about what they were doing conflicting with parts of levels, and I know that for me at least, it made it easier to divide things up mentally into component building blocks when designing a level.
It was almost like building with lego blocks in my mind, and streamlined the process for me. I went on recently to use the same strategy to (I believe) good effect in my DM-Courtyard level for Unreal Tournament 3.
What could be improved
Early on in the project, the focus in designing levels was almost completely on gameplay concerns, and only lightly on creating environments that believably represented their intended setting. The assumption at that early point was that to do otherwise would perhaps tread on the toes of the (outsourced) artists that would be crafting the visuals for the levels.
Over the course of the project, the balance shifted towards us (level designers) putting more and more detail into our block maps; to aid the artists in their roles, and to hopefully avoid the creation of art that would interfere with our intended (and play-tested) gameplay. This led to the loss of some time to re-doing levels or parts of levels a few times, and possibly could have been avoided with a more defined strategy for these things being in place earlier in the project.
Another issue was that there were some communication problems with the outsourced artists employed for the project. With the exception of a technical artist and two concept artists, all the artists on the Kwari project were based in India. There are perhaps a lot of reasons why communication may have sufferred; fairly different time zones, limited bandwidth making exhanging files between studios a slow process, potentially language issues, communication being filtered through Leads and related to others (notably on their side, but also ours to a lesser extent), among other reasons.
These communication problems created a few issues, the most problematic being the creation of art assets that negatively impacted on the established gameplay in our levels. That these art assets had to be fixed was time consuming in and of itself, but the often lengthy process of documenting these problems in order to give feedback to the artists so that they knew what to fix meant even more time was 'lost' to fixing problems.
It is tempting to simply say that most of these communication problems could be 'easily' solved by employing in-house artists rather than outsourced ones (it being much easier to stand next to someone and point at something and say "this is the problem here" than it is to describe a problem in words and screenshots). Of course this is not always possible, so there must be ways in which a working relationship with outsourced artists can be improved.
Whatever these solutions may be (it is a bit beyond the scope of this post-mortem to speculate on that sort of thing), having systems in place to ease communication between us and the outsourced artists would have drastically sped up production.
Conclusion
Considering some of the challenges faced in the Kwari project (a very tight development timeframe, my first project in the industry, and designing to a somewhat new and unique brief/business model, just to name a few), I believe my work on the project was quite successful. People enjoyed my levels, and I found the other team members (both the other level designers and the team as a whole) easy and enjoyable to work with.
It was certainly the most fun I've ever had on a job. :-)
[return to top]
posted by Joseph | 1:38 PM
0 Comments:
Post a Comment
<< Home