How do you make social NPCs? Here's a new approach.
Fundamentally, social is a matter of conversation. It's not back-and-forth: it's simultaneously offering a bit of your mind and looking to see how the other person is receiving it. You may simply offer bits of your mind over and over and over, with no "balance" of them offering pieces of their mind in exchange. All they are doing from the perspective of an outside is listening, but from the perspective of the talker they are offering feedback. They are offering their judgment and acceptance and incredulity and so on, all in line with the conversation.
So, to simulate social NPCs in a game, isn't it necessary to allow for this kind of conversation? The kind of conversation where you respond not by taking control of the conversation or having your line-item dialog tree option, but instead allowing the player and the NPC to understand each other's intentions via an ongoing passive response.
Here's an example. An friend comes up to you and says "My front window broke last night!" As this is being said, the player enters their response. It comes out as "oh?" or "whoa!" or "huh!" or "so?" or whatever. Then the friend goes on... but what they go on with depends on whether they think you care, what they think you want to hear. So they may go on with "... so, that was odd, yeah. How's life?" or they may go on with "I woke up and there was glass everywhere!" or they may go with "Maybe someone is throwing bricks at my house?!" It all depends on whether you seem to want to hear more.
There's a lot of stuff you need to do in order to build this into a game. You need to give it both clarity and texture. So the player understands that answering "oh?" and "whoa!" are going to have two different results, or at least result in two different perceptions of the player by the NPC. Moreover, the actual conversation needs to be flexible enough to adjust to the emotional or personal interest given. This can't realistically be done with a dialog tree - the explosion of options makes it impossible, especially if you use the rule where if you hit the same interjection button multiple times it makes you give the interjection more emphatically. Having four different options per line is bad enough, but having 8 or 16 would be impossible.
You can do it by writing several chains of dialog, though. For example, you might write a technical chain and an emotional chain. Each link on the chain is heavier than the last.
So if the NPC says "My front window broke last night!" you might indicate technical interest: "oh?" or you might indicate personal interest: "are you okay?" This would determine whether the next line is taken from the technical or emotional chain.
Moreover, if your interjections are more emphatic, it simply means to skip some of the links. The NPC feels comfortable presenting a heavier link because she knows you are interested enough that you won't consider it a burden or boring. So if you hit the technical interest button a bunch of times, you might interject "wow, that must have been a hell of a mess!" And rather than simply taking the next link on the technical chain ("there was glass everywhere"), she'd respond with a link a distance down the line, something like "well, cleaning it up was a sure annoying. That stuff can cut you!"
When you are feeding one chain, pulling down links for conversation, the other chain remains still. So if you express technical interest for a while, but then say "are you okay?" they won't skip to the 20th emotional link, they'll just move to the first one. However, you can stay on the technical chain by expressing more technical interest but still expressing some personal interest, which might end up pulling the emotional chain along without actually causing any of the links to be brought up in conversation. Or visa-versa.
The key to this is that both technical and personal chains have in-game reasons to pick them. A link that is brought up in conversation has an in-game effect. A technical link would improve the NPC's ability to resolve the situation faster and perhaps grant them skill experience or emotional stability. An emotional link would deepen your relationship with the NPC, but cause them to get emotional, upsetting their efficiency at in-game tasks or losing some skill experience or extending the duration of the situation.
The conversation isn't unlimited, either. Your relationship or their energy level or whatever determines the maximum number of lines they'll say. So you may want to leap ahead to the heavy links as soon as possible.
I would actually make the links visible on the screen for the player to see. That way you can put in broken or damaged links. Conversational bits that will abruptly end the conversation or cause offense or something. You need to avoid having them brought up, so you need to skip over them or spool past them while on the other line.
In this way, the conversation becomes an actual game, where you are talking to someone and it has flexible in-game results. It's not just a matter of +10% bargaining or whatever.
More complexly, this system could be built to allow the player to talk and the NPC to interject. This would be a matter where the NPC can see the broken/damaged links in the conversation and their interjections are partly based on personal preference and partly to give the player hints that there might be damage on a given chain in a certain number of links. So the player chooses which chains to advance how many notches, taking into consideration which links he thinks are broken and how much the NPC gives a shit.
It could also be adapted to allow for back-and-forth conversations, although this would require an actual conversation generation system.
Hm.
Friday, March 01, 2013
Sunday, February 24, 2013
Roller Coaster Games
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.
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.
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.
Subscribe to:
Posts (Atom)