CRUSH
|
Full Demo Day at bottom of page
|
CRUSH
is a four player networked PC game that was developed by team of six over the
course of ten weeks. The game was created for our Software Systems Design and
Implementation class. The conflict of the game revolves around a science
fiction narrative in which various corporate factions fight over an asteroid
field's mineral resources. Placed in the far future, a lack of resources lead
to the in-game conflict, and we wanted to design the play of the game to
reflect this desperate, cut throat narrative. To achieve this, we created a
hybrid of capture the flag and diplomacy in which players can choose to extract
minerals from the center of the field, dog fight others for minerals, or even
steal them from opponents' bases. Without explicitly informing them of which
options were ideal, a vicious cycle of stealing and dogfights would sway back
and forth as different factions were viewed as threats at different times.
Someone who was too big of a threat would become victim to other factions
teaming up. In this way, many complex interactions could take place in an open
world setting, and the narrative was intrinsically built from these
interactions.
Designer/asset artist in a group of six. |
Design/Development
The key aspect of CRUSH that we wanted to convey through the gameplay was the brutal, dog-eat-dog nature of our near future-a future in which resources were highly contested and fought over tooth and nail, often via backstabbing and treachery. In addition to this, we had one other goal: fun. While seeming obvious, we wanted to make a game that was first and foremost fun to play rather than witty and clever. Simpliciy was the name of the game and we set out to achieve our goal. To do this we wanted to get to the playtest phase as soon as possible in order to fine tune play. Considering we only had 10 weeks to implement a game engine, create assets, test, tune and release our game for the demo, we made several tactical decisions.
First, the game would be in space, with spaceships. No fiddling with ground collisions or grinding our teeth about shoddy animations. Space solved several complexity issues which would allow us to playtest earlier than the other groups in the class. I was a strong advocate for this, knowing our limitations within the time span while also wanting to create something that was fun and beautiful. As sole asset artist, I played a strong role in this aesthetic and gameplay defining decision.
Having reached the full playtest phase well before the other groups, we began bringing in playtesters. Friends, labmates, and significant others were all dragged in to play our game. Through several iterations of this we were able to find out what was fun and what was not. What was difficult and what was frustrating. To our delight, even the very first playtesters were smiling and yelling at each other (goodnaturedly) over the cut-throat nature of the game, cursing at players who had betrayed them in the game. Focusing on these aspects, while spending plenty of time tuning controls to make them more intuitive (we learned much about what assumptions you make when you pick up a controller), we considered ways to promote our story further in the game play.
Several factors played into how this manifested in the game:
These were the elements that made our game both fun and brutal, and the subtleties that emerged from the system allowed players to gain mastery in a number of different strategies per their play style. In this regard I believe the game was highly successful.
Shortcomings
While the brutal nature of the game was important to us, I believe there are a number of ways in which it became problematic. Stealing from bases needed to be nerfed. In future iterations we would have applied more cooldowns to restrict how often one can steal from another player's base. The idea of some sort of sentry turrets was also proposed post-released by a member of our team. Another, related issue was the fact that it became too easy to gang up on players. While interesting in how it promoted sly, ruthless play, I believe it could have been curbed so as to not actually punish successful players as much as I believe it did. These are considerations which would have been taken into account in further iterations, and which I keep in mind in my current projects.
First, the game would be in space, with spaceships. No fiddling with ground collisions or grinding our teeth about shoddy animations. Space solved several complexity issues which would allow us to playtest earlier than the other groups in the class. I was a strong advocate for this, knowing our limitations within the time span while also wanting to create something that was fun and beautiful. As sole asset artist, I played a strong role in this aesthetic and gameplay defining decision.
Having reached the full playtest phase well before the other groups, we began bringing in playtesters. Friends, labmates, and significant others were all dragged in to play our game. Through several iterations of this we were able to find out what was fun and what was not. What was difficult and what was frustrating. To our delight, even the very first playtesters were smiling and yelling at each other (goodnaturedly) over the cut-throat nature of the game, cursing at players who had betrayed them in the game. Focusing on these aspects, while spending plenty of time tuning controls to make them more intuitive (we learned much about what assumptions you make when you pick up a controller), we considered ways to promote our story further in the game play.
Several factors played into how this manifested in the game:
- Spawning resources only at the center of the map - This was critical. The initial moments of the game were always a headlong race to the center, where the asteroids of the map were the most dense. Because only two resources spawned initially, at least two of the players would usually end up in a spinning dogfight over these resources.
- Allowing players to steal from others - encouraging it in fact. This was important to balance, but giving players an incentive to steal from each other rather than allowing them to speedily collect more resources than their opponent created a vicious environment where different players would develop different strategies in relation to this fact. Some would attempt this courier strategy, while others waited and preyed upon those. Others still would wait behind bases and siphon resources from them.
- Allowing stealing from bases - As mentioned above, this perpetuated systems already in place, but also allowed multiple players to steal from one player at a time.
- Making scores publicly visible and easy to affect - As one player began piling up resources, others would begin negotiating and egging their opponents on to take down the monopoly that was building up. The result of this was that certain players who threatened other too much would often end up with the least resources at the end of the game. Subtlety and subterfuge were key elements.
These were the elements that made our game both fun and brutal, and the subtleties that emerged from the system allowed players to gain mastery in a number of different strategies per their play style. In this regard I believe the game was highly successful.
Shortcomings
While the brutal nature of the game was important to us, I believe there are a number of ways in which it became problematic. Stealing from bases needed to be nerfed. In future iterations we would have applied more cooldowns to restrict how often one can steal from another player's base. The idea of some sort of sentry turrets was also proposed post-released by a member of our team. Another, related issue was the fact that it became too easy to gang up on players. While interesting in how it promoted sly, ruthless play, I believe it could have been curbed so as to not actually punish successful players as much as I believe it did. These are considerations which would have been taken into account in further iterations, and which I keep in mind in my current projects.
Assets
|
Art ConsiderationsAs sole asset artist on the project, I was responsible for creating the visual aesthetic of CRUSH. Immediately I knew I wanted to create something EVE-like, which was also a major inspiration for the concept of the game. The process was relatively straightforward, I kept on my asset deadlines, developing initial models and textures weekly, and refining them as we moved along. One of the biggest issues we had to surmount was the compression of model textures. Through working directly with the graphics programmers we developed a pipeline by which the size of images was reduced by 75% without compromising graphics quality. Work on the asteroids also played a significant role in ensuring the game ran smoothly, as even the most basic asteroids would quickly add up in polygons when gathered in a field. I developed a method using various noise generators to create high-fidelity, low-poly models of these. Combined with later improvements made by the Network team members, this allowed us to populate our game with large, dense asteroid fields that had people at the demo wondering how it had been accomplished.
|
|
|
CSE 125 Demo Day - UC San DiegoAs the culmination of the project, my team presented our game at a demo day along with the other projects from the Software Systems and Design Implementation class. Taking place in Atkinson Hall's auditorium, CRUSH was demoed in front of an audience of over 200. In this video, we discuss the making of the project from concept to conception, and demonstrate its features through a number of play-throughs with volunteers from the audience.
|