Every time I play a 3D sonic game and randomly get hung up on a ledge and flung off into space, I wonder whether it's possible to create a good 3D roller-coaster game. Ditch all the parts of the games that aren't about speed and flow. This also isn't a game about dealing with endless random obstacles: it's a game about traveling through levels at high speeds and having fun finding new routes and doing better runs.
The modern Sonic games have a couple of fun camera tricks that can make roller coaster games really interesting. The games are fundamentally 2D, but the game keeps changing which 2D: is it a horizontal 2D like the old sonic, or a top-down 2D like a race car game? Sometimes it wanders into 1D or 3D, and we'll cover those too, but the meat of the gameplay is in 2D.
In the sidescrolling 2D, the challenge is to race along hitting jump and dash as the need arises. While Sonic includes various platform puzzles, we'll do away with them. They're flabby leftovers and the worst part of the 2D game. Instead, we'll focus entirely on the idea of managing ground acceleration, vertical maneuver, and horizontal air dash.
You can raise your speed by running on the ground. This isn't always possible - you might be faced with a pit or some spikes or something. If you wish to accelerate faster, to higher top speeds, you can use dash fuel while on the ground to run much faster. If the level was just a single line of hills, it'd be entirely a matter of running along the ground and using dash.
But it's not just on a surface. There are a lot of reasons you'll need to go vertical. Some of these reasons are built into the level in the form of springs or ramps. Other times, you'll press jump - useful for avoiding ground obstacles, collecting coins in the air, and changing layers. While you're in the air you may be able to shift left and right, but that doesn't really matter much except to optimize coin collection. In Sonic you can also homing-jump, but I'm not going to include this. Instead, the real maneuvering option in the air is that pressing dash makes you move horizontally, allowing you to pop into small horizontal gaps, slam into enemies, and so on.
From the perspective of a roller coaster, this sidescrolling section is about optimizing foot speed, optimizing coin collection, and triggering air events by either high-speed jumping or air dashing.
Every ten to thirty seconds, the game then swings into "car" 2D mode, where you run forward while the camera looks down from behind, giving you a clear look ahead. In Sonic, this sometimes barges into proper 3D as Sonic's speed slows, so we'll want to not allow that. Our goal is speed.
Classically, Sonics tripped up on this because the controls don't scale correctly. This hit a fever pitch with the "Mach Speed Segments" that were literally uncontrollable. The modern Sonic games avoid this by reverting to a rail system. Sometimes this is literal rails, other times it's more like lanes in a highway. You don't want to turn sonic left or right: you just want to make him drift across the lanes. Even in the sections which are not actually lane-controls, the player still acts like they are lane-controlled, since he doesn't want to make any serious turns. He just wants to be a little righter or lefter than he currently is.
We can use this same philosophy: the course of the "road" is what matters. You control your position left and right on the road. This has a lot of similarities with the sidescrolling sections: you can run on the ground to increase speed, dash on the ground to radically increase speed. You control your left/right orientation in much the same way that jumping would control your sidescrolling orientation: to collect coins, avoid trouble, and take different routes. The air dash is replaced by the side dash, which simply allows you to change to the center of the lane to one side instantly. We can also put in "exits", which are sharp offturns you can only take by side dashing into them as you're running along.
Now you can jump in these sections. Classically, the jump is just a way to avoid death as the road breaks. IE, it allows you to skip some hazards without changing lanes, and sometimes those hazards are in all the lanes, so you'll have to jump. Occasionally a jump is a way to enter a linear trigger section, which we'll talk about shortly. Both of these are fine: they add spice without threatening to slow the game down. A lot of these segments also have homing-dash chains, which are great.
In sidescrolling mode, homing dash is a muddy distraction, a weaker version of the horizontal dash. The horizontal dash in these sections allows the exact side view to be used properly and precisely. On the other hand, in the "lane" sections, the camera is behind you and you're not sure precisely how far ahead things are, especially when they aren't sitting on the road in the marked lanes. In this case, the homing dash makes up for a core weakness in the camera. So when you jump and hit dash, you'll homing dash rather than doing an air-horizontal dash.
The camera isn't simply bad, though. The lane camera reveals far more of the future than the side camera does with a far better presence. With the side camera, you have to choose whether you have a hard time seeing the things nearby because the camera is zoomed out, or whether you can't see things far away because the camera is zoomed in. Either way, you have to design the max speeds and the jumping challenges to this shorter distance, often resorting to using linear dash sections or putting markers on the level of what is coming ahead (such as Sonic's "fall hazard" markers and "press O you doof!" markers).
The last kind of challenge is similar to a lane challenge, but it's a "skydiving" challenge. The idea is to control your position as you fall through a tube-shaped zone of space. Sometimes dashing is useful to smash through lightweight barriers. Either way, this area is strictly an optimization challenge and a breather. It's never used as a full gameplay section with multiple paths or careful timing events.
Bosses are a fun topic, but a boss is normally an excuse to use one of the other challenge types, frequently including the low-speed or moderate-speed challenges I'm not considering. Some bosses do use the high-speed challenges, especially the lane challenges, and these can be a lot of fun. But they aren't really a distinct challenge type, just a way to frame the challenges we've already considered.
I think that is the majority of the high-speed challenges in Sonic. There are a variety of low- and medium-speed challenges that we'll just go ahead and discard. They aren't fast enough.
There are, however, some non-challenge elements to talk about. One of these are the linear dash sections. These are chains where things just pong-pong-pong you along. They're fast and fun. Often they have some element of interaction - never so much that you're likely to fail, but enough that you'll feel involved. For example, you land in a cannon and then it fires when you press X. There's no reason to wait - pressing X is just to get the player involved. Similarly, a chain of floating enemies where you hit each with a homing dash. While you can theoretically miss, you're not generally intended to. It's not intended to be a challenge, it's intended to be a way to get the player involved in a linear section.
One of the things that Sonic attempted to introduce along these lines was the "stunt" system. When you're launched into the air, press directions to do stunts and then land properly by pressing buttons. It's not really very interesting, although you could argue that variety alone makes it worthwhile - if you're trying to get the player involved, variety might be useful.
In addition to the linear dash sections are the transition sections, where the camera changes from lane to side or visa-versa. This usually happens over a second or two of "non-play". Sometimes this non-play section is a linear dash. Other times, it's a "run out" on a rail grind or open road section. Either way, the player is generally not allowed to screw up his control during this small section, because otherwise he would screw up his controls.
I think these could form the basis for a roller coaster game.
You'd also need good framing. A good feeling of progress and theme and world presence. Replaying levels is a big part of the fun - finding other paths and doing better. So it's not recommended it be random levels.
Hm. The camera switching and linear dash sections really are the heart of this game type, I think. I wonder whether you could build other kinds of games with the same philosophy. Like a match-3 gem-destroy game that sometimes spools the gems out into a Space Invaders marching flotilla thing... hm.
Sunday, February 24, 2013
Saturday, February 16, 2013
Clean Combat
In the past few months I've been playing a lot of team-based games. Some multiplayer, some singleplayer. Some fantasy, some sci fi. Some this, some that.
I've learned a lot, come up with some ideas and theories.
One of the things I've really taken to considering is how much the stuff in any given tactical game is not about dealing damage.
For example, in a game like Final Fantasy Tactics, only a small portion of your actions are about dealing damage, avoiding damage, or repairing damage. Most of the actions you take are boosting stats, maneuvering for range advantage, debuffing, screwing with the turn order, using items... even when you are dealing damage, it's invariably from one of about eighty different damage-dealing skills you have. So even on rounds where you deal damage, you're still spending a lot of the player's time on things other than actually choosing to deal damage - the player instead spends their time choosing between variant ways and approaches.
On the other hand, in the new XCOM game, at least in its early stages, the game is almost entirely spent on either dealing damage or avoiding damage. Sometimes this is quite complex - for example, scouting only a bit ahead and only with your first acting unit, so that when the enemies magically teleport into your field of view, you have the queue of soldiers to blow them to bits all in a chain.
You could say that in the new XCOM game, most of your considerations are about the timing and queuing of damage and anti-damage, rather than about variations and random crap. It's a very clean design.
One of the things that helps it be so clean is that, like a MOBA, you don't really have unique characters. There's only five or so distinct classes, and they're always the same no matter what face you put in front of them. The only difference between this assault soldier and that assault soldier is in the simple level-up choices you make. There's no complex stats to compute, no complex equipment choices to make, and no real multiclass complexity to manage. This means you can quickly learn the ways in which each class differs when it comes to damage queuing and timing.
I was thinking: I really like this approach. I don't necessarily like every detail of how XCOM implemented it, but I do like the core idea. The combat is not about having a white mage and a rogue and a strike mage and so on. It's about creating the timing and queueing of damage and anti-damage.
This is actually rather similar to Radiant Historia, one of the best games for the DS. The main mechanic there was also about queuing up turns and damage, although it was a completely different kind of game than XCOM. In Radiant Historia, your characters would attack a 3x3 grid of enemies. Your attacks frequently hit more than one space, or moved anyone occupying a space. Queuing was important: not only could you chain each character's attack in with the next, but you could also reorder the turns so that your characters could go many times in a row.
These are both great ideas. The core thought is that the player should be thinking about the timing and queuing of damage, rather than being concerned about stats or precise range or elemental affinities or buffs or whatever.
So... I guess I'll go design a game like that. IT SOUNDS FUN. IT IS FUN. LET'S DESIGN SOME GAMES LIKE THAT. AND MAYBE DRINK A LITTLE LESS COFFEE.
I've learned a lot, come up with some ideas and theories.
One of the things I've really taken to considering is how much the stuff in any given tactical game is not about dealing damage.
For example, in a game like Final Fantasy Tactics, only a small portion of your actions are about dealing damage, avoiding damage, or repairing damage. Most of the actions you take are boosting stats, maneuvering for range advantage, debuffing, screwing with the turn order, using items... even when you are dealing damage, it's invariably from one of about eighty different damage-dealing skills you have. So even on rounds where you deal damage, you're still spending a lot of the player's time on things other than actually choosing to deal damage - the player instead spends their time choosing between variant ways and approaches.
On the other hand, in the new XCOM game, at least in its early stages, the game is almost entirely spent on either dealing damage or avoiding damage. Sometimes this is quite complex - for example, scouting only a bit ahead and only with your first acting unit, so that when the enemies magically teleport into your field of view, you have the queue of soldiers to blow them to bits all in a chain.
You could say that in the new XCOM game, most of your considerations are about the timing and queuing of damage and anti-damage, rather than about variations and random crap. It's a very clean design.
One of the things that helps it be so clean is that, like a MOBA, you don't really have unique characters. There's only five or so distinct classes, and they're always the same no matter what face you put in front of them. The only difference between this assault soldier and that assault soldier is in the simple level-up choices you make. There's no complex stats to compute, no complex equipment choices to make, and no real multiclass complexity to manage. This means you can quickly learn the ways in which each class differs when it comes to damage queuing and timing.
I was thinking: I really like this approach. I don't necessarily like every detail of how XCOM implemented it, but I do like the core idea. The combat is not about having a white mage and a rogue and a strike mage and so on. It's about creating the timing and queueing of damage and anti-damage.
This is actually rather similar to Radiant Historia, one of the best games for the DS. The main mechanic there was also about queuing up turns and damage, although it was a completely different kind of game than XCOM. In Radiant Historia, your characters would attack a 3x3 grid of enemies. Your attacks frequently hit more than one space, or moved anyone occupying a space. Queuing was important: not only could you chain each character's attack in with the next, but you could also reorder the turns so that your characters could go many times in a row.
These are both great ideas. The core thought is that the player should be thinking about the timing and queuing of damage, rather than being concerned about stats or precise range or elemental affinities or buffs or whatever.
So... I guess I'll go design a game like that. IT SOUNDS FUN. IT IS FUN. LET'S DESIGN SOME GAMES LIKE THAT. AND MAYBE DRINK A LITTLE LESS COFFEE.
Thursday, February 14, 2013
Crafting Party Members
I have a soft spot for games where you build your party members. For example, the Final Fantasy Tactics games and all similar games usually allow you to recruit arbitrary characters to fill your party out. Many Dragon Quest games also allow you to build characters.
There are a few downsides to this, but let's stick to just two:
1) There is a very uncomfortable relationship between created NPCs and scripted NPCs. Scripted NPCs tend to be more powerful and have unique abilities, meaning that the characters the player spends the most effort creating are also the weakest. That's bad. Also, from the other direction: scripted characters tend to not change visuals to match class changes, so it's hard to remember what role the scripted characters play.
Games where you can create NPCs would benefit from not having scripted party allies. This can be done by either having no plot-entangled party members (such as some Dragon Quest games) or by making the plot elements attach to arbitrary NPCs you've created instead of actually linking to a scripted character.
2) NPC creation is usually pretty painful. It either features some kind of extremely generic creation screen (class, name, gender) or an awkwardly over-detailed randomly rolled set of stats (oh, should I reroll so that my AIM is 81 instead of 79?)
If I want to feel attachment to these characters, rather than that method, I propose a "talent" system. Instead of randomly rolling ten different stats, randomly choose three tiered talents and two visual perks. Talents would be things like "beefy" or "cunning" or "ice-element aligned". Visual perks would be things like "messy red hair", "glasses", "long face", "curly beard"...
This combination means that you'll be able to remember the character more easily and not lose track of their specialties in a mess of ever-changing numbers. When the character changes job classes, they don't magically lose all their unique visual elements. Instead, they simply change outfits but remain with the same palette and fundamental visual characteristics, allowing you to remember who someone is even after they change jobs.
There are a few downsides to this, but let's stick to just two:
1) There is a very uncomfortable relationship between created NPCs and scripted NPCs. Scripted NPCs tend to be more powerful and have unique abilities, meaning that the characters the player spends the most effort creating are also the weakest. That's bad. Also, from the other direction: scripted characters tend to not change visuals to match class changes, so it's hard to remember what role the scripted characters play.
Games where you can create NPCs would benefit from not having scripted party allies. This can be done by either having no plot-entangled party members (such as some Dragon Quest games) or by making the plot elements attach to arbitrary NPCs you've created instead of actually linking to a scripted character.
2) NPC creation is usually pretty painful. It either features some kind of extremely generic creation screen (class, name, gender) or an awkwardly over-detailed randomly rolled set of stats (oh, should I reroll so that my AIM is 81 instead of 79?)
If I want to feel attachment to these characters, rather than that method, I propose a "talent" system. Instead of randomly rolling ten different stats, randomly choose three tiered talents and two visual perks. Talents would be things like "beefy" or "cunning" or "ice-element aligned". Visual perks would be things like "messy red hair", "glasses", "long face", "curly beard"...
This combination means that you'll be able to remember the character more easily and not lose track of their specialties in a mess of ever-changing numbers. When the character changes job classes, they don't magically lose all their unique visual elements. Instead, they simply change outfits but remain with the same palette and fundamental visual characteristics, allowing you to remember who someone is even after they change jobs.
Pangame Multiplayer
There's a steadily rising amount of buzz about the concept of recording your gameplay footage automatically, so you can share it instantly if you think "oh that was cool!" This is already common in fighting games, but it's popping up in various other places. Evidently, it's going to be an automatic feature of the PS4, at least.
I really think it's a great idea, but not for the idea of sharing your plays in video form. No, I think it's great because it enables pangame multiplayer.
Let's say I design a number of semi-casual semi-social games. In the first one you play a hero who wanders the land killing monsters and collecting loot. The second one is a word-forming game like Boggle. The third is a Farmville-esque game.
Each of these games stands on their own well enough, with some social gaming hooks as such games tend to have. However, each game also automatically records the last thirty seconds of your gameplay. And participates in the "pangame API".
The "pangame API" is a game-agnostic event stream. Each game can connect to any other participant(s) and stream events to them. For example, if you make a word combo in your Boggle clone, you send out a 'success!' event with the point value attached. The other game catches it and interprets it. If the other game is also the Boggle clone, then you might increase their timer or, if competitive, lock down a few of their letters.
But if another game is the other participant, it also catches the event just fine. The Farmville game interprets the success as a burst of productivity on your cows. The wandering hero interprets it as an HP-restore or, if competitive, a new monster entering the fray.
By laying down a foundation of basic multiplayer events, you can allow two players playing completely different games to still cooperate or compete. Whether the two people are sitting in the same living room, Skyping across states, or even have never met, they are gaming together. Of course, it's no fun to just randomly see things pop up and not have any clue what's going on with the other player, so that's where the auto-recorded video comes into play.
When the Boggle player finds a good word, it sends out the points event, yes. But it also sends out an audiovideo "blurb" that lets the other player see what's going on. There can also be a number of small "touch" events that don't change game state, but keep the two players connected via video. This kind of awareness is important in any kind of multiplayer game.
The API can be a lot more complex than that. Each game has the standard events, yes, but each game also has a number of call-and-response challenges.
For example, the Boggle game could get a message from the hero game: "My player is in dire trouble, your player needs to accomplish a medium-difficulty task to save him!" The Boggle game goes "medium difficulty, hmmm, okay: my player! Save the other guy by forming a word starting with 'K'!" And the Boggle game ALSO goes: "Hey hero game, here's a video stream of me challenging my player to do that!"
The hero game never knows what challenge the Boggle game has issued its player. To the hero game, it doesn't matter what game the other player is playing. Just that the quest was accepted and if it was accomplished. It doesn't understand what the video contains - the video is a message to the player to let the player know what's going on in the other game. The hero game doesn't really know or care.
On the other end of the spectrum, the Farmville game might say "hey, you, friend game over there! I have some resource trading stored up. Offer some resources for resources, would you?" And the Boggle game would go "Hey, my player: every letter you use in the next word will be sent over to your buddy and replaced with a random GOLD letter."
Or the hero game could go "I cleared out this level with this event trail yesterday. You want to do a ghost race against it?"
Obviously, there are concerns with spoofing or game balance, but there are always issues with such things. Fundamentally, I think this would be a great way to let players cooperate even when they aren't interested in playing the same game at the same time on the same type of device.
I really think it's a great idea, but not for the idea of sharing your plays in video form. No, I think it's great because it enables pangame multiplayer.
Let's say I design a number of semi-casual semi-social games. In the first one you play a hero who wanders the land killing monsters and collecting loot. The second one is a word-forming game like Boggle. The third is a Farmville-esque game.
Each of these games stands on their own well enough, with some social gaming hooks as such games tend to have. However, each game also automatically records the last thirty seconds of your gameplay. And participates in the "pangame API".
The "pangame API" is a game-agnostic event stream. Each game can connect to any other participant(s) and stream events to them. For example, if you make a word combo in your Boggle clone, you send out a 'success!' event with the point value attached. The other game catches it and interprets it. If the other game is also the Boggle clone, then you might increase their timer or, if competitive, lock down a few of their letters.
But if another game is the other participant, it also catches the event just fine. The Farmville game interprets the success as a burst of productivity on your cows. The wandering hero interprets it as an HP-restore or, if competitive, a new monster entering the fray.
By laying down a foundation of basic multiplayer events, you can allow two players playing completely different games to still cooperate or compete. Whether the two people are sitting in the same living room, Skyping across states, or even have never met, they are gaming together. Of course, it's no fun to just randomly see things pop up and not have any clue what's going on with the other player, so that's where the auto-recorded video comes into play.
When the Boggle player finds a good word, it sends out the points event, yes. But it also sends out an audiovideo "blurb" that lets the other player see what's going on. There can also be a number of small "touch" events that don't change game state, but keep the two players connected via video. This kind of awareness is important in any kind of multiplayer game.
The API can be a lot more complex than that. Each game has the standard events, yes, but each game also has a number of call-and-response challenges.
For example, the Boggle game could get a message from the hero game: "My player is in dire trouble, your player needs to accomplish a medium-difficulty task to save him!" The Boggle game goes "medium difficulty, hmmm, okay: my player! Save the other guy by forming a word starting with 'K'!" And the Boggle game ALSO goes: "Hey hero game, here's a video stream of me challenging my player to do that!"
The hero game never knows what challenge the Boggle game has issued its player. To the hero game, it doesn't matter what game the other player is playing. Just that the quest was accepted and if it was accomplished. It doesn't understand what the video contains - the video is a message to the player to let the player know what's going on in the other game. The hero game doesn't really know or care.
On the other end of the spectrum, the Farmville game might say "hey, you, friend game over there! I have some resource trading stored up. Offer some resources for resources, would you?" And the Boggle game would go "Hey, my player: every letter you use in the next word will be sent over to your buddy and replaced with a random GOLD letter."
Or the hero game could go "I cleared out this level with this event trail yesterday. You want to do a ghost race against it?"
Obviously, there are concerns with spoofing or game balance, but there are always issues with such things. Fundamentally, I think this would be a great way to let players cooperate even when they aren't interested in playing the same game at the same time on the same type of device.
Wednesday, February 13, 2013
DLC and Downloadable Games
I'm kind of old-fashioned: I really like having physical copies of the games I play. This is probably because of how I play games: I'll go back after a few months and look through all the games I bought and see whether any of them strike me as replayable. I also used to like lending games out to my friends, although that's not as common these days. Either way, a big stack of cartridges and CDs is a literal game library.
All of that may just be an excuse, though. I own more downloadable games than disk games, but it's the disk games I keep going back to.
Fundamentally, I play games in a bubble. Any part of the gaming experience which pops the bubble, well, pops the bubble.
I knew I was going to hate DRM - so I don't buy games with DRM. But I expected to be able to adapt to DLC, always-connected play, trophies, and downloadable games in general. But it's just not happening. Every year I get more annoyed by these practices. They make it impossible to play a game in a bubble. I'm riding a horse around looking for a dragon to kill and the game is going "SONY HEY INTERNET SONY DRM DLC TROPHY TROPHY MICROSOFT ON-LINE COMPETITIVE SONY DRM DLC DLC COULD YOU SPARE SOME CASH DLC DLC?"
Yeah, pretty much ruins the experience.
Downloadable games can form a bubble pretty well - as well as a console game, I guess. But they rarely do. Usually they are filled to the brim with distractables. Even if they do manage to make me forget GAME GAME MONEY GAME DLC DLC, there's still the matter of remembering they exist.
I kind of thought about turning this on its head. What can we do to strengthen the bubble?
What if we distribute a game on a thumb drive? It's just some ordinary kind of open-world game, like an RPG or a Minecraft clone. Lots of customization and exploration.
The game only runs while the thumb drive is in the computer. It offers you the option of connecting to the internet and other players, but that option is relatively shallow: you can get true multiplay only over a LAN. You only need one thumb drive to let any number of LAN players play together.
Conversely, you can connect multiple thumb drives to one computer to merge their worlds, or to multiple computer on the LAN to create easy pan-world bridges...
The idea is that the very act of having a physical dongle creates a bubble. The game itself doesn't have to be single-player or offline. It just has to revolve around the dongle. Everything else is outside the bubble.
I dunno if it's any good, as ideas go. I'm pretty sick right now. But the long and short of it is that I just can't immerse myself in games that talk about the internet, about DLC, about trophies... it just distracts me all the time.
All of that may just be an excuse, though. I own more downloadable games than disk games, but it's the disk games I keep going back to.
Fundamentally, I play games in a bubble. Any part of the gaming experience which pops the bubble, well, pops the bubble.
I knew I was going to hate DRM - so I don't buy games with DRM. But I expected to be able to adapt to DLC, always-connected play, trophies, and downloadable games in general. But it's just not happening. Every year I get more annoyed by these practices. They make it impossible to play a game in a bubble. I'm riding a horse around looking for a dragon to kill and the game is going "SONY HEY INTERNET SONY DRM DLC TROPHY TROPHY MICROSOFT ON-LINE COMPETITIVE SONY DRM DLC DLC COULD YOU SPARE SOME CASH DLC DLC?"
Yeah, pretty much ruins the experience.
Downloadable games can form a bubble pretty well - as well as a console game, I guess. But they rarely do. Usually they are filled to the brim with distractables. Even if they do manage to make me forget GAME GAME MONEY GAME DLC DLC, there's still the matter of remembering they exist.
I kind of thought about turning this on its head. What can we do to strengthen the bubble?
What if we distribute a game on a thumb drive? It's just some ordinary kind of open-world game, like an RPG or a Minecraft clone. Lots of customization and exploration.
The game only runs while the thumb drive is in the computer. It offers you the option of connecting to the internet and other players, but that option is relatively shallow: you can get true multiplay only over a LAN. You only need one thumb drive to let any number of LAN players play together.
Conversely, you can connect multiple thumb drives to one computer to merge their worlds, or to multiple computer on the LAN to create easy pan-world bridges...
The idea is that the very act of having a physical dongle creates a bubble. The game itself doesn't have to be single-player or offline. It just has to revolve around the dongle. Everything else is outside the bubble.
I dunno if it's any good, as ideas go. I'm pretty sick right now. But the long and short of it is that I just can't immerse myself in games that talk about the internet, about DLC, about trophies... it just distracts me all the time.
Thursday, February 07, 2013
Tough Cookies!
So, I've been thinking about the MOBA scene. More specifically, I've been thinking about League of Legends.
It may come as a surprise to... nobody... that League of Legends is not my cup of tea. I don't much like competitive games, and I don't generally have the time to dedicate to actually playing a real-time multiplayer game.
But League of Legends has a dedicated core of fans that really love it, and some fairly brilliant little gameplay bits. In short - like it or not, League of Legends is a good game.
Could you do the same kind of thing in a cooperative game?
Let's start with the cooperative battle.
Let's start by flat-out lifting the combat system. Except that there is no enemy team. Instead, the heroes fight against an automated threat.
A lot of players instinctively recoil at that statement. The big draw of a MOBA is the fact that you fight other players. But, hey, I didn't say anything about not fighting other players. I said "automated", not "stock".
Let's go ahead and presume that the missions are created by other players. The players can place the opponents. Let's just run through a quick example of the basic idea.
You have to defeat the end boss (the final lair) to win. There are several paths that lead to that lair, but along those paths are lesser lairs you must enter first. Once you enter a lesser lair, you awaken the monster inside. You can get past, now, but there's a heavyweight non-generic monster making trouble. Even if you kill the monster, it will eventually respawn as long as the match continues.
Fundamentally, the matches are likely to still remain very much like a MOBA match, although the pacing is completely different. The part of the enemy team is played by an ever-increasing roster of heavyweight monsters.
There are a few advantages to this system. First, it's robust about griefing and substandard player action. That is, the enemy can't screw you over by disconnecting or whatever. The whole mission is laid out ahead of time on the server, so the only people actually playing it are all allies. Your allies could still grief you, but that's a different category of problem.
Second, it cuts the player synchronicity requirement in half. You no longer need 10 players to play a match - only 5. Still, you can actually go the opposite way. Since you don't need balanced sides, you could play an allied team with 12 players in a kind of "raid" format. It allows for a wider variety of easier-to-start matches.
Third, it creates a new kind of gameplay: creating quests. A lot of players enjoy creating. It's compelling to express yourself by placing various monsters and challenges. It's doubly fun if you can watch the replays of people trying to tackle your map. Sure, there's always a risk of dongs being drawn, but compared to the general chat in a MOBA, that's a pale shadow of a problem. In addition to being a compelling form of gameplay, it's highly asynchronous (you can do it on your own, even offline) and also a great source of revenue (buy special challenge elements in the cash shop).
Now, this would have to work via a balancing/ranking system. So the player who makes the quest has to put some kind of ranking guesstimate on it. Players who challenge at a given rank will pull randomly from quests near that rank. Every time the players fail, the quest's rank goes up and the players' ranks go down. And visa-versa. The player who made the map gets some kind of kickback every time players challenge his quest, but only so long as the quest's rank remains near his original estimate. If the quest turns out to be much easier or harder than he thought, the quest remains in rotation at the new difficulty level, but he no longer gets any gold. This should keep rank griefing/farming to a minimum.
Another big element of popular MOBAs is the persistent part of the game.
Part of your persistent world is which heroes you have unlocked.
Some of the persistent stuff comes from tweaking your combat loadout. Although each hero is always the same, players will tweak their abilities slightly with different global/generic capabilities. Part of your persistent world is which abilities you have unlocked. In this case, that would also involve which quest construction elements you have available to place.
Part of your persistent world is your rank and history inside of the combat system. In this case, that would also include constructed quests.
In a cooperative game, it would be wise to add in some connectivity in the persistent game, making it vaguely social. Guilds and so on are common, but in this case something more tangible would probably be wise.
I would probably make a kind of simple "kingdom" game, where you have various lands you can tweak via a casual play interface. You know the sort - upgrade by clicking after two days, or click each hour for gold. Change whether that field is growing daisies, horses, or farmland, etc. Your kingdom could be a big part of what general upgrades are available to you. Also, you can customize some features of your kingdom (such as your ruler, crown, flag, maybe castle interior, etc) to express yourself, and those customizations may also be affected by your kingdom's resources.
You can make your kingdom larger by winning in quests. Higher-ranked quests give you a lot more kingdom land than lower-ranked quests - more than linear. So you want to fight in the upper tiers if you want more kingdom.
A lot of players aren't going to care about the kingdom stuff, which is fine. You can become either an ally or citizen of another nation. As a citizen of another nation, you don't have lands of your own. Instead, you have a manor house in the leader's nation. Lands you earn by fighting are given to the overall nation, and they are governed by the ruler and any governors he appoints. All you need to do is fight to your heart's content. The general abilities and/or heroes which would rely on your nation's development instead rely on the overall nation's development.
If a kingdom has citizens, you'll see the player avatars bumming around in the castle all the time.
I think there's some opportunities here. It sounds like a fun game.
It may come as a surprise to... nobody... that League of Legends is not my cup of tea. I don't much like competitive games, and I don't generally have the time to dedicate to actually playing a real-time multiplayer game.
But League of Legends has a dedicated core of fans that really love it, and some fairly brilliant little gameplay bits. In short - like it or not, League of Legends is a good game.
Could you do the same kind of thing in a cooperative game?
Let's start with the cooperative battle.
Let's start by flat-out lifting the combat system. Except that there is no enemy team. Instead, the heroes fight against an automated threat.
A lot of players instinctively recoil at that statement. The big draw of a MOBA is the fact that you fight other players. But, hey, I didn't say anything about not fighting other players. I said "automated", not "stock".
Let's go ahead and presume that the missions are created by other players. The players can place the opponents. Let's just run through a quick example of the basic idea.
You have to defeat the end boss (the final lair) to win. There are several paths that lead to that lair, but along those paths are lesser lairs you must enter first. Once you enter a lesser lair, you awaken the monster inside. You can get past, now, but there's a heavyweight non-generic monster making trouble. Even if you kill the monster, it will eventually respawn as long as the match continues.
Fundamentally, the matches are likely to still remain very much like a MOBA match, although the pacing is completely different. The part of the enemy team is played by an ever-increasing roster of heavyweight monsters.
There are a few advantages to this system. First, it's robust about griefing and substandard player action. That is, the enemy can't screw you over by disconnecting or whatever. The whole mission is laid out ahead of time on the server, so the only people actually playing it are all allies. Your allies could still grief you, but that's a different category of problem.
Second, it cuts the player synchronicity requirement in half. You no longer need 10 players to play a match - only 5. Still, you can actually go the opposite way. Since you don't need balanced sides, you could play an allied team with 12 players in a kind of "raid" format. It allows for a wider variety of easier-to-start matches.
Third, it creates a new kind of gameplay: creating quests. A lot of players enjoy creating. It's compelling to express yourself by placing various monsters and challenges. It's doubly fun if you can watch the replays of people trying to tackle your map. Sure, there's always a risk of dongs being drawn, but compared to the general chat in a MOBA, that's a pale shadow of a problem. In addition to being a compelling form of gameplay, it's highly asynchronous (you can do it on your own, even offline) and also a great source of revenue (buy special challenge elements in the cash shop).
Now, this would have to work via a balancing/ranking system. So the player who makes the quest has to put some kind of ranking guesstimate on it. Players who challenge at a given rank will pull randomly from quests near that rank. Every time the players fail, the quest's rank goes up and the players' ranks go down. And visa-versa. The player who made the map gets some kind of kickback every time players challenge his quest, but only so long as the quest's rank remains near his original estimate. If the quest turns out to be much easier or harder than he thought, the quest remains in rotation at the new difficulty level, but he no longer gets any gold. This should keep rank griefing/farming to a minimum.
Another big element of popular MOBAs is the persistent part of the game.
Part of your persistent world is which heroes you have unlocked.
Some of the persistent stuff comes from tweaking your combat loadout. Although each hero is always the same, players will tweak their abilities slightly with different global/generic capabilities. Part of your persistent world is which abilities you have unlocked. In this case, that would also involve which quest construction elements you have available to place.
Part of your persistent world is your rank and history inside of the combat system. In this case, that would also include constructed quests.
In a cooperative game, it would be wise to add in some connectivity in the persistent game, making it vaguely social. Guilds and so on are common, but in this case something more tangible would probably be wise.
I would probably make a kind of simple "kingdom" game, where you have various lands you can tweak via a casual play interface. You know the sort - upgrade by clicking after two days, or click each hour for gold. Change whether that field is growing daisies, horses, or farmland, etc. Your kingdom could be a big part of what general upgrades are available to you. Also, you can customize some features of your kingdom (such as your ruler, crown, flag, maybe castle interior, etc) to express yourself, and those customizations may also be affected by your kingdom's resources.
You can make your kingdom larger by winning in quests. Higher-ranked quests give you a lot more kingdom land than lower-ranked quests - more than linear. So you want to fight in the upper tiers if you want more kingdom.
A lot of players aren't going to care about the kingdom stuff, which is fine. You can become either an ally or citizen of another nation. As a citizen of another nation, you don't have lands of your own. Instead, you have a manor house in the leader's nation. Lands you earn by fighting are given to the overall nation, and they are governed by the ruler and any governors he appoints. All you need to do is fight to your heart's content. The general abilities and/or heroes which would rely on your nation's development instead rely on the overall nation's development.
If a kingdom has citizens, you'll see the player avatars bumming around in the castle all the time.
I think there's some opportunities here. It sounds like a fun game.
Tuesday, February 05, 2013
Dead Isn't
Everyone's talking about Dead Space 3 now. Most of them are pretty much saying what I would probably say if I played it: "it's not scary". "the constant money-shop pestering is annoying", "well, it's fun when they stop with the bullshit."
I won't be buying it. I wasn't pleased with Dead Space 2 - it was formulaic and boring to me. I tried to think about why.
The general theory about scary games is that the main character needs to have no real power. You get scared because you can't really win - you can just claw your way towards desperate survival.
I'm not sure I buy that theory 100%, because System Shock 2 was scary as hell. So was one of the Aliens vs Predators games, although I can never remember which is which given their Capcom-esque naming conventions. In both games you play heavily armored space marines capable of taking down any enemy you face. Even the bosses are usually brought down by simply shooting them a lot. But they're pretty scary.
Dead Space was kinda scary. Dead Space 2 was scary for about an hour, maybe. Crew Cut Beefy White Guy #102,911,158 cuts his way through the two games pretty much the same way, so why is one scarier and the other not? Why are neither as scary as Aliens vs Predators Ultra Turbo Gold Edition? Hell, why is House of the Dead 2 (Suffer like G did?) scarier than Dead Space 2?
I think it's my immersion in the threat. That is me, the player. How threatening the world feels to me.
In both System Shock 2 and AvP, the threatening world was really tangible. It was extremely rare for either game to feel "cheap". Every threat you ran into felt like it belonged. Of course there's a mech in there. Fuck, the room is labeled "mech storage". None of the threats are popped into existence solely as a transparent challenge to the player. You are in this hellish world, and it is tangible. It works like the world would work.
On the other hand, Dead Space 2 (and 3) both suffer from serious monster-closet disease, where enemies basically just randomly run into rooms to give the player a challenge. There's not really any reason why the monsters constantly attack the decontamination chambers. There's no reason for them to come crawling out of the walls right at this moment. They just do it because it's their job to scare the player. It's a haunted house ride instead of a horror game.
Of course, the challenges making sense are not the only thing that makes games scary. There's also how often you die. And that number should be extreeeeeeeemely close to "once".
Dying is a constant threat in Dead Space 2. On the other hand, in truly scary games, it's actually pretty easy to beat any one encounter. The question is how many resources you come out of it with. If three dogs jump in through the window, you probably have enough time to blow them all away... but how many bullets did you waste? Is it maybe better to try and use a shitty weapon to save good ammo? Maybe even the knife - but then you might actually die!
Dying in a scary game should be close to taboo, because dying means getting to try the same damn thing again and again and again. It's not scary to die when you respawn at a checkpoint. It's scary to reach the end boss with only a few bullets left.
Dead Space 2 features a huge number of cheap deaths - presumably because they want you to see the implausible death animations they've created. More than once I died after completing an objective, and it reset me back to an old checkpoint. This isn't scary. It's fucking annoying.
Death isn't scary in a video game. It's annoying. Saving your progress when you have only a few bullets left is scary.
I won't be buying it. I wasn't pleased with Dead Space 2 - it was formulaic and boring to me. I tried to think about why.
The general theory about scary games is that the main character needs to have no real power. You get scared because you can't really win - you can just claw your way towards desperate survival.
I'm not sure I buy that theory 100%, because System Shock 2 was scary as hell. So was one of the Aliens vs Predators games, although I can never remember which is which given their Capcom-esque naming conventions. In both games you play heavily armored space marines capable of taking down any enemy you face. Even the bosses are usually brought down by simply shooting them a lot. But they're pretty scary.
Dead Space was kinda scary. Dead Space 2 was scary for about an hour, maybe. Crew Cut Beefy White Guy #102,911,158 cuts his way through the two games pretty much the same way, so why is one scarier and the other not? Why are neither as scary as Aliens vs Predators Ultra Turbo Gold Edition? Hell, why is House of the Dead 2 (Suffer like G did?) scarier than Dead Space 2?
I think it's my immersion in the threat. That is me, the player. How threatening the world feels to me.
In both System Shock 2 and AvP, the threatening world was really tangible. It was extremely rare for either game to feel "cheap". Every threat you ran into felt like it belonged. Of course there's a mech in there. Fuck, the room is labeled "mech storage". None of the threats are popped into existence solely as a transparent challenge to the player. You are in this hellish world, and it is tangible. It works like the world would work.
On the other hand, Dead Space 2 (and 3) both suffer from serious monster-closet disease, where enemies basically just randomly run into rooms to give the player a challenge. There's not really any reason why the monsters constantly attack the decontamination chambers. There's no reason for them to come crawling out of the walls right at this moment. They just do it because it's their job to scare the player. It's a haunted house ride instead of a horror game.
Of course, the challenges making sense are not the only thing that makes games scary. There's also how often you die. And that number should be extreeeeeeeemely close to "once".
Dying is a constant threat in Dead Space 2. On the other hand, in truly scary games, it's actually pretty easy to beat any one encounter. The question is how many resources you come out of it with. If three dogs jump in through the window, you probably have enough time to blow them all away... but how many bullets did you waste? Is it maybe better to try and use a shitty weapon to save good ammo? Maybe even the knife - but then you might actually die!
Dying in a scary game should be close to taboo, because dying means getting to try the same damn thing again and again and again. It's not scary to die when you respawn at a checkpoint. It's scary to reach the end boss with only a few bullets left.
Dead Space 2 features a huge number of cheap deaths - presumably because they want you to see the implausible death animations they've created. More than once I died after completing an objective, and it reset me back to an old checkpoint. This isn't scary. It's fucking annoying.
Death isn't scary in a video game. It's annoying. Saving your progress when you have only a few bullets left is scary.
Friday, February 01, 2013
Action Games: Alternate Play
Since starting in Unity, I've been analyzing action games a lot. Action games are not something I've had a lot of experience designing.
I've starting to form a complicated opinion on action games and the nature of avatars. I've refined the term "action gameplay" to specifically mean any action taken while in a world with noticeable time pressure. So, yeah, shooting an approaching enemy is an action mechanic. But so is throwing a switch or jumping a crevasse, as long as those things happen in a situation where time pressure exists - such as if you're being shot at.
Right now, I'm working on the idea that the avatar is the critical component in classifying an action game. So, with that in mind, there are a few "classes" of action game mechanic.
Direct-action mechanics are one where your avatar has an obvious action they can take and it has an obvious, shallow effect. For example, shooting someone, leaping a chasm, opening a floodgate, etc. In general, these are actions where replacing your avatar with a talking rabbit plush toy would make them obviously not work.
Complex-action mechanics are ones where the game does a lot of your avatar-directing for you, or you have another tier of management on your character. For example, the ability to switch between several weapons, managing inventory, context commands more complicated than "use", dialog trees, and so on. If you replace your avatar with a talking rabbit plush toy and think "well, it makes just as much sense either way", then it's probably a complex-action mechanic.
Indirect-action mechanics are ones where the avatar doesn't act directly. His position and activities don't really matter. This is things like ordering soldiers around, cooking food, hacking computers, timing-based dance minigames...
Here's an example. You play an adventurer pushing your way through an alien city. You want to pick up that clay pot.
Direct-action version: you walk over and pick it up. You are now carrying a clay pot in your hands. Your hands are full of clay pot.
Complex-action version: you walk over and add the clay pot to your inventory.
Indirect-action version: you click on the pot and add it to your inventory regardless of where in the room the avatar is.
Here another example: you want to kill a bad guy with your magic blammies.
Direct-action version: aim at the bad guy and click. The spell shoots from you to him.
Complex-action version: click on the bad guy and select a spell, or visa-versa. The spell shoots from you to him.
Indirect-action version: click on the bad guy, and he is affected by the spell regardless of where you're standing.
This can get kind of fuzzy. For example, maybe you're playing a lane-shooter. The very act of targeting someone automatically moves your avatar to line up with them. Is that complex or indirect? I would argue complex, but the point is that these are just basic ideas, not laws. Similarly, most games have a combination of these kinds of mechanics: most shooter games are direct-action games with an inventory, at the very least.
Anyway, I'm just puttering around with these theories because I'm trying to think of good direct-action mechanics that aren't violent. I've come up with a few, but I'd love to hear more.
I've starting to form a complicated opinion on action games and the nature of avatars. I've refined the term "action gameplay" to specifically mean any action taken while in a world with noticeable time pressure. So, yeah, shooting an approaching enemy is an action mechanic. But so is throwing a switch or jumping a crevasse, as long as those things happen in a situation where time pressure exists - such as if you're being shot at.
Right now, I'm working on the idea that the avatar is the critical component in classifying an action game. So, with that in mind, there are a few "classes" of action game mechanic.
Direct-action mechanics are one where your avatar has an obvious action they can take and it has an obvious, shallow effect. For example, shooting someone, leaping a chasm, opening a floodgate, etc. In general, these are actions where replacing your avatar with a talking rabbit plush toy would make them obviously not work.
Complex-action mechanics are ones where the game does a lot of your avatar-directing for you, or you have another tier of management on your character. For example, the ability to switch between several weapons, managing inventory, context commands more complicated than "use", dialog trees, and so on. If you replace your avatar with a talking rabbit plush toy and think "well, it makes just as much sense either way", then it's probably a complex-action mechanic.
Indirect-action mechanics are ones where the avatar doesn't act directly. His position and activities don't really matter. This is things like ordering soldiers around, cooking food, hacking computers, timing-based dance minigames...
Here's an example. You play an adventurer pushing your way through an alien city. You want to pick up that clay pot.
Direct-action version: you walk over and pick it up. You are now carrying a clay pot in your hands. Your hands are full of clay pot.
Complex-action version: you walk over and add the clay pot to your inventory.
Indirect-action version: you click on the pot and add it to your inventory regardless of where in the room the avatar is.
Here another example: you want to kill a bad guy with your magic blammies.
Direct-action version: aim at the bad guy and click. The spell shoots from you to him.
Complex-action version: click on the bad guy and select a spell, or visa-versa. The spell shoots from you to him.
Indirect-action version: click on the bad guy, and he is affected by the spell regardless of where you're standing.
This can get kind of fuzzy. For example, maybe you're playing a lane-shooter. The very act of targeting someone automatically moves your avatar to line up with them. Is that complex or indirect? I would argue complex, but the point is that these are just basic ideas, not laws. Similarly, most games have a combination of these kinds of mechanics: most shooter games are direct-action games with an inventory, at the very least.
Anyway, I'm just puttering around with these theories because I'm trying to think of good direct-action mechanics that aren't violent. I've come up with a few, but I'd love to hear more.
Subscribe to:
Posts (Atom)