Earlier this year, the browser game Cookie Clicker swept the internet. It's an absurdly simple game: you click a giant cookie to get cookies, and then spend those cookies to get more cookies via upgrades. You quickly reach an absurd number of cookies, but there is by design no grander goal. Your entire purpose is to make more cookies. This is a game that sounds monumentally stupid on paper, almost like a parody. And yet, it's been a huge legitimate success. Many people play it and derive enjoyment from doing so, despite (or more likely because of) how silly it is. It's easy to simply write this game off as a novelty or a fluke, something that gained popularity simply through audacity that cannot be replicated.
However, if you look beneath the surface there's actually something here worth studying. At its heart, Cookie Clicker is a game about resource management. Your goal is to maximize your production of cookies, but you can spend cookies now to make more cookies in the future, and you can choose whether to spend them quickly on cheap items, or save them for something that will have a greater effect. Lots of games feature more complex versions of this same interaction, usually involving an additional variable, such as damage (do I spend 100 sun for a peashooter now, or save 200 for a repeater later?) or some other consideration (do I use star power to survive the tricky solo or on an easier section I know I can keep a good score multiplier through?).
This basic idea has applications for Sunbots. Currently, our game features only one resource: sun energy. You collect sun energy from planets, and use it to expand the sun and fight its decay (avoiding one of our game's lose states and achieving its win state) but also use it to more easily maneuver your character. A more recent feature involves using it on the planets as well, charging them to allow them to produce more energy over time. This is where Cookie Clicker comes in. Where Cookie Clicker first gets fun is the first moment you produce an 'absurd' amount of cookies. Where this point lays is different for everyone, but around 1,000,000 is a good benchmark. Progress in Cookie Clicker starts out very slowly; one cookie per click, no automatic production. Your first improvement (for your average first-time player, anyway) will be a cursor, which produces 0.1 cookies per second. From this slow production, you can build up auto-clickers, getting your automated production up to the point where you no loner have to obsessively click yourself, before you reach critical mass and revel in how many cookies you are now producing. From humble beginnings, you have wealth, an embarrassment of cookies. This is the fundamental emotional underpinning of the Cookie Clicker experience, the feeling of going from rags to riches entirely through one's own work.
This is what can be applied, not just to Sunbots, but any game about maximizing and managing resources. Starting small, making growth start slowly, but increase faster over time until you have more resources than you know what to do with; this is the core of an inherently enjoyable resource system. Cookie Clicker exemplifies it so well because it consists of the entirety of gameplay. It is a distillation of a common design element, all the more potent for the lack of filler. By looking at the fun in Cookie Clicker, we can apply a similar mentality to our burgeoning resource system. In general, all games can benefit from knowing what their individual elements contribute in a vacuum and how they best work on their own, so they might also know why and for what purpose they might be utilizing said elements.
Thursday, October 24, 2013
Sunday, October 20, 2013
Decision Time
So far in my posts I've covered the progress on the rail platformer prototype. However, as I hinted in my last post this is not the concept our team is ultimately developing. Instead, we're pursuing an idea we're calling Sunbots. In this game, the player is a robot gathering energy from various planets in a solar system. Their goal is to deposit this energy into the sun, which is slowly dying. Since the game takes place in space, each planet has gravity which affects the player, and the challenge comes in utilizing these gravitational forces to effectively navigate the system.
We liked this idea better than the rail game because of its uniqueness. Very few games use gravity outside of a force to keep you on the ground; even Super Mario Galaxy mainly used it for set dressing rather than truly exploring it as a concept. However, this idea was also significantly more risky. Since complicated gravity systems basically don't exist in gaming (the main exception we found, Gravity Pods, was a puzzle game in the vein of Angry Birds rather than a game with a directly controlled avatar) there isn't a strong well of battle-tested ideas to pull from when working on this.
When we first prototyped Sunbots, we did so in a fully 3D environment. 3D is sort of a default for a lot of game design, but it seemed to make sense for this concept; a large part of the fun of it seemed to be in movement and exploration, both of which work well in 3D. However, we quickly ran into problems. The vast majority of 3D games are mainly controlled on a 2D plane. The player may move up or down, but often only through the terrain or temporarily via jumping. Most of your day to day movement is along the X and Z axes. Adding full 3D control makes things a lot more complicated, and this was acutely felt in our game's camera.
Plainly put, the camera didn't really work with the movement. Our game world, by necessity, had a fair amount of empty space, with respectable distances between planets. Unless you were right by a planet, it was very hard to tell in what direction you were moving. Since there was full 3D movement, you could be pulled in a LOT of different directions. You could be looking at one planet, thinking it was the one you were going to land on, only to be blindsided by a closer planet behind you that you've never even seen. We tried making the camera lock on to the closest planet so player would know where they were going, but all that did was limit the sense of freedom in the movement, and make it hard for the player to see anything around them. If we were going to move forward with this, the camera and movement systems were going to be a constant struggle. This was going to be a very hard challenge.
Oftentimes, when you come up to an impossible looking problem. it's a sign that you're asking the wrong question. We were trying to make our idea work in a 3D space. As it turned out, we didn't actually need 3D to capitalize on what made our concept special. The core of this idea was the inherent interesting nature of a full gravity system, and the fun that could be found in mastering such a system and exploring via it. All of this was improved when we shifted our focus to a 2D plane.
It became much easier for players to see where they were going and how they were getting there. With everything on the same plane, the camera didn't have to worry about its Y position, and simply had to exist above the player, moving with them. We could keep our wide planet spacing, and be sure the player would know the galaxy's layout, not having to worry about what direction they happened to be looking in. Once we removed a dimension, things began to click. Our prototype wasn't perfect at such an early stage, but we no longer had a massive unsolved question about the core concept's viability. With this change, we knew that what we wanted to do was possible, and worthwhile. We had our game.
We liked this idea better than the rail game because of its uniqueness. Very few games use gravity outside of a force to keep you on the ground; even Super Mario Galaxy mainly used it for set dressing rather than truly exploring it as a concept. However, this idea was also significantly more risky. Since complicated gravity systems basically don't exist in gaming (the main exception we found, Gravity Pods, was a puzzle game in the vein of Angry Birds rather than a game with a directly controlled avatar) there isn't a strong well of battle-tested ideas to pull from when working on this.
When we first prototyped Sunbots, we did so in a fully 3D environment. 3D is sort of a default for a lot of game design, but it seemed to make sense for this concept; a large part of the fun of it seemed to be in movement and exploration, both of which work well in 3D. However, we quickly ran into problems. The vast majority of 3D games are mainly controlled on a 2D plane. The player may move up or down, but often only through the terrain or temporarily via jumping. Most of your day to day movement is along the X and Z axes. Adding full 3D control makes things a lot more complicated, and this was acutely felt in our game's camera.
Plainly put, the camera didn't really work with the movement. Our game world, by necessity, had a fair amount of empty space, with respectable distances between planets. Unless you were right by a planet, it was very hard to tell in what direction you were moving. Since there was full 3D movement, you could be pulled in a LOT of different directions. You could be looking at one planet, thinking it was the one you were going to land on, only to be blindsided by a closer planet behind you that you've never even seen. We tried making the camera lock on to the closest planet so player would know where they were going, but all that did was limit the sense of freedom in the movement, and make it hard for the player to see anything around them. If we were going to move forward with this, the camera and movement systems were going to be a constant struggle. This was going to be a very hard challenge.
Oftentimes, when you come up to an impossible looking problem. it's a sign that you're asking the wrong question. We were trying to make our idea work in a 3D space. As it turned out, we didn't actually need 3D to capitalize on what made our concept special. The core of this idea was the inherent interesting nature of a full gravity system, and the fun that could be found in mastering such a system and exploring via it. All of this was improved when we shifted our focus to a 2D plane.
It became much easier for players to see where they were going and how they were getting there. With everything on the same plane, the camera didn't have to worry about its Y position, and simply had to exist above the player, moving with them. We could keep our wide planet spacing, and be sure the player would know the galaxy's layout, not having to worry about what direction they happened to be looking in. Once we removed a dimension, things began to click. Our prototype wasn't perfect at such an early stage, but we no longer had a massive unsolved question about the core concept's viability. With this change, we knew that what we wanted to do was possible, and worthwhile. We had our game.
Friday, October 4, 2013
Difficulty and the prototypes
When we let off last time, we had a few different iterations on a rail-shifting platformer mechanic. We had a version where the player could physically shift to parallel rails, and a version where the player could shift between two colored layers in the same physical space.
The point of a prototype at this early stage in development is to demonstrate a specific mechanic and explore its viability. You don't want to include extraneous systems or elements, for two reasons: they can distract from the core experience you made the prototype to test in the first place, and they can also be a resource hog. Part of a prototype's appeal is that it's quick and dirty, and if done right you can get a sense for what's worth investing significant time and resources into before you have already done so. Therefore, in the interest of simplicity I did not give any thought to the actual level layout presented in the prototype. I threw some blocks on the rails and figured that was good enough. After all, we're testing the mechanic, not the level design. Why spend time fussing with developing a polished play-space if you don't even know if it's for something worthwhile?
The results from the prototype's first round of outside testing were therefore surprising. Players consistently remarked that the prototype felt too easy, and that they felt like maybe it would be more fun in later levels. More than one player noticed that both versions of the prototype were completable using only one mechanic, i.e. only jumping or only shifting. Because the prototype did not require players to actually use all the key mechanics, initial testers were unable to discern how the mechanic actually felt to play.
So it was back to the drawing board. The testers needed challenges which required interesting uses of the key mechanics, so the next iteration delivered just that. There were challenges which required jumping, challenges which required shifting, challenges which quickly varied between the two, challenges which required both at the same time, heck, there was even a later version which combined both shifting ideas into one prototype, featuring challenges which required all introduced mechanics in quick succession. These prototypes were ultimately more successful. Players were able to fully experience the shifting mechanic, and provide valuable feedback because of it.
Of course, this level of challenge density still wasn't ideal. These later prototypes had the problem of being incredibly difficult; players could easily die dozens of times in a couple minutes. Overall skewing too difficult is better than skewing too easy; players may get frustrated, and you may not get the average tester through the entire prototype, but at least they get to experience the key mechanics in a game context, as opposed to a prototype where the key mechanic might as well not even exist. Ultimately, as a team we decided to pursue another game idea entirely (more on this next time!) meaning that this was the last iteration of the rail platformer. However, if it were to get more attention, the difficulty would probably be lowered somewhat, just to create an ideal environment for players to experience the key mechanics. When creating an effective prototype, it isn't enough to simply throw in the key mechanic; there are often key sub-systems or supporting elements that are necessary to show your intent. In this case, it was difficulty.
The point of a prototype at this early stage in development is to demonstrate a specific mechanic and explore its viability. You don't want to include extraneous systems or elements, for two reasons: they can distract from the core experience you made the prototype to test in the first place, and they can also be a resource hog. Part of a prototype's appeal is that it's quick and dirty, and if done right you can get a sense for what's worth investing significant time and resources into before you have already done so. Therefore, in the interest of simplicity I did not give any thought to the actual level layout presented in the prototype. I threw some blocks on the rails and figured that was good enough. After all, we're testing the mechanic, not the level design. Why spend time fussing with developing a polished play-space if you don't even know if it's for something worthwhile?
The results from the prototype's first round of outside testing were therefore surprising. Players consistently remarked that the prototype felt too easy, and that they felt like maybe it would be more fun in later levels. More than one player noticed that both versions of the prototype were completable using only one mechanic, i.e. only jumping or only shifting. Because the prototype did not require players to actually use all the key mechanics, initial testers were unable to discern how the mechanic actually felt to play.
So it was back to the drawing board. The testers needed challenges which required interesting uses of the key mechanics, so the next iteration delivered just that. There were challenges which required jumping, challenges which required shifting, challenges which quickly varied between the two, challenges which required both at the same time, heck, there was even a later version which combined both shifting ideas into one prototype, featuring challenges which required all introduced mechanics in quick succession. These prototypes were ultimately more successful. Players were able to fully experience the shifting mechanic, and provide valuable feedback because of it.
Of course, this level of challenge density still wasn't ideal. These later prototypes had the problem of being incredibly difficult; players could easily die dozens of times in a couple minutes. Overall skewing too difficult is better than skewing too easy; players may get frustrated, and you may not get the average tester through the entire prototype, but at least they get to experience the key mechanics in a game context, as opposed to a prototype where the key mechanic might as well not even exist. Ultimately, as a team we decided to pursue another game idea entirely (more on this next time!) meaning that this was the last iteration of the rail platformer. However, if it were to get more attention, the difficulty would probably be lowered somewhat, just to create an ideal environment for players to experience the key mechanics. When creating an effective prototype, it isn't enough to simply throw in the key mechanic; there are often key sub-systems or supporting elements that are necessary to show your intent. In this case, it was difficulty.
Subscribe to:
Comments (Atom)