LukasIrzl

What makes a combat system for fighting games?

Recommended Posts

LukasIrzl    207

Hi there,

it's been a while since my last post. I was creating a bunch of games but there was always something missing. Something which makes the game (maybe unique)... After a few tries I decided to start a side project for a combat system which should be used for fighting games.

I did a lot of research and programming to finally get something that makes actually fun to play. Well... it is only a prototype and I do not want to share it (yet). Now I decided to share my ideas of the basics of a combat system for fighting games.

Don't get me wrong... This is only my way of doing stuff and I want as many feedback as possible and maybe it will help people with their games.

I will provide a few code snippets. It will be some sort of OOP pseudo code and may have typos.

Content

1. Introduction

2. Ways of dealing damage

1. Introduction

What makes a combat system a combat system?

I guess it could be easy to explain. You need ways of dealing damage and ways of avoiding damage. At least you need something for the player to know how to beat the opponent or the game. As i mentioned before, I will focus on fighting games. As it has ever been there is some sort of health and different ways to reduce health. Most of the times you actually have possibilities to avoid getting damage. 

I will focus on these points later on.

2. Ways of dealing damage

How do we deal damage by the way?

A common way to do so, is by pressing one or more buttons at one time in order to perform an attack. An attack is an animation with a few phases. In my opinion, an attack consists of at least four phases.

1. Perception

2. Action

3. Sustain

4. Release

Here is an example animation I made for showing all phases with four frames:

attack_frames.png.eedca8526ccd73023c2e59fa84233518.png

Every one of those has its own reason. One tipp for our designers out there is to have at least one image per phase. Now we should take a closer look at the phases itself.

2.1. Perception

The perception phase should include everything to the point, the damage is done. Lets say, it is some sort of preparing the actual attack.

Example: Before you would punch something, you would get in position before doing the actual action, right?

Important note: the longer the perception phase is, the more time the opponent has to prepare a counter or think about ways to avoid the attack. Like having light and heavy attacks. The heavy attacks mostly have longer perception phases than the light ones. This means, that the damage dealt is likely greater compared to the light attacks. You would like to avoid getting hit by the heavy ones, right?

2.2. Action

The action phase is the actual phase where damage is dealt. Depending on the attack type itself the phase will last longer or shorter. Using my previous example, heavy attacks might have a longer action phase than light attacks. In my opinion, the action phase should be as short as possible.

One great way to get the most out of the attack animation itself is by using smears. They are often used for showing motion. There's ton of reference material for that. I like using decent smears with a small tip at the starting point and a wide end point (where the damage should be dealt). This depends on the artist and the attack.

2.3. Sustain

At first sight, the sustain phase may be irrelevant. It is directly after the attack. My way of showing the sustain phase is by using the same image for the action phase just without any motion going on. The sustain phase should be some sort of a stun time. The images during the sustain phase should show no movement - kind of a rigid state.

Why is this phase so important?

It adds a nice feel to the attack animation. Additionally, if you want to include combos to your game, this is the phase, where the next attack should be chained. This means, while the character is in this phase of the attack, the player could press another attack button to do the next attack. The next attack will start at the perception phase.

2.4. Release

The release phase is the last phase of the attack. This phase is used to reset the animation to the usual stance (like idle stance).

2.5. Dealing damage

Dealing damage should be only possible during the action phase.

How do we know, if we land a hit? I like using hit-boxes and damage-boxes.

2.5.1. Hit-boxes

A hit box is an invisible box the character has. It shows it's vulnerable spot. By saying "Hit-box" we do not mean a box itself. It could be any shape (even multiple boxes together - like head, torso, arms, ...). 

You should always know the coordinates of your hit-box(es).

Here is an example of a hit-box for my character:

hit_box.png.c9c1a2444b1deb175ee414b268d0bf86.png

I am using Game Maker Studio, which is automatically creating a collision box for every sprite. If you change the sprite from Idle to Move, you may have a different hit-box. Depending on how you deal with the collisions, you may want to have a static hit-box.

Hit-boxes could look something like this:

class HitBox {
	/*
    offsetX = the left position of you hit-box relative to the players x coordinate
    offsetY = the top position of you hit-box relative to the players y coordinate
    width = the width of the hit-box
    height = the height of the hit-box
    */
	int offsetX, offsetY, width, height;
    
    /*
    Having the players coordinates is important.
    You will have to update to player coordinates every frame.
    */
    int playerX, playerY;
    
    //initialize the hit-box
    HitBox(offsetX, offsetY, width, height) {
    	this.offsetX = offsetX;
    	this.offsetY = offsetY;
    	this.width = width;
    	this.height = height;
    }
    
    //Update (will be called every frame)
    void update(playerX, playerY) {
    	//you can also update the player coordinates by using setter methods
    	this.playerX = playerX;
    	this.playerY = playerY;
    }
    
    //Getter and Setter
    ...
    
    //Helper methods
    int getLeft() {
    	return playerX + offsetX;
    }
    int getRight() {
    	return playerX + offsetX + width;
    }
    int getTop() {
    	return playerY + offsetY;
    }
    int getBottom() {
    	return playerY + offsetY + height;
    }
}

When using multiple hit-boxes it would be a nice idea to have a list (or array) of boxes.

Now one great thing to implement is a collision function like this:

//check if a point is within the hit-box
boolean isColliding(x, y) {
	return x > getLeft() && x < getRight() && y > getTop() && y < getBottom();
}

//check if a box is within the hit-box
boolean isColliding(left, right, top, bottom) {
	return (right > getLeft() || left < getRight()) && (bottom > getTop() || top < getBottom());
}

2.5.2. Damage-boxes

Damage-boxes are, like hit-boxes, not necessarily a box. They could be any shape, even a single point. I use damage-boxes to know, where damage is done. 

Here is an example of a damage-box:

damage_box.png.509207b6809c9fe7f7dfdd1bb1caaf67.png

The damage box does look exactly like the hit-box.

The hit-box differs a bit to the actual damage-box. A damage-box can have absolute x and y coordinates, because there is (most of the times) no need to update the position of the damage-box.

If there is a need to update the damage-box, you can do it through the setter methods.

class DamageBox {
	/*
    x = absolute x coordinate (if you do not want to update the coordinates of the damage-box)
    y = absolute y coordinate (if you do not want to update the coordinates of the damage-box)
    width = the width of the damage-box
    height = the height of the damage-box
    */
	int x, y, width, height;
    
    /*
    The damage the box will do after colliding
    */
    int damage;
    
    //initialize the damage-box
    DamageBox(x, y, width, height, damage) {
    	this.x = x;
    	this.y = y;
    	this.width = width;
    	this.height = height;
        this.damage = damage;
    }
    
    
    //Getter and Setter
    ...
    
    //Helper methods
    int getLeft() {
    	return x;
    }
    int getRight() {
    	return x + width;
    }
    int getTop() {
    	return y;
    }
    int getBottom() {
    	return y + height;
    }
}

2.5.3. Check for collision

If damage-boxes and hit-boxes collide, we know, the enemy receives damage.

Here is one example of a hit:

check_collision.png.951b28f084237338e7493a6d88e7bbde.png

Now we want to check, if the damage box collides with a hit-box.

Within the damage-box we can insert an update() method to check every frame for the collision.

void update() {
	//get all actors you want to damage
	actors = ...; //use a variable or have a global method (it is up to you, to get the actors)
	//iterate through all actors
	foreach(actor in actors) {
		//lets assume, they only have one hit-box
		hitBox = actor.getHitBox();
		//check for collision
		if(hitBox.isColliding(getLeft(), getRight(), getTop(), getBottom()) {
			//do damage to actor
			actor.life -= damage;
		}
	}
}

To get all actors, you could make a variable which holds every actor or you can use a method you can call everywhere which returns all actors. (Depends on how your game is set up and on the engine / language you use).

The damage box will be created as soon as the action phase starts. Of course you will have to destroy the damage-box after the action phase, to not endlessly deal damage.

2.6. Impacts

Now that we know, when to deal the damage, we should take a few considerations about how to show it. There are a few basic elements for us to use to make the impact feel like an impact.

2.6.1. Shake the screen

I guess, I am one of the biggest fans of shaking the screen. Every time there is some sort of impact (jumping, getting hit, missiles hit ground, ...) I use to shake the screen a little bit. In my opinion, this makes a difference to the gameplay. As usual, this may vary depending on the type of attack or even the type of game.

2.6.2. Stop the game

This may sound weird, but one great method for impacts is to stop the game for a few frames. The player doesn't actually know it because of the short time, but it makes a difference. Just give it a try.

2.6.3. Stun animation

Of course, if we got hit by a fist, we will not stand in our idle state, right? Stun animations are a great way to show the player, that we landed a hit.

There is only one problem. Lets say, the player is a small and fast guy. Our enemy is some sort of a big and heavy guy. Will the first punch itch our enemy? I guess not. But maybe the 10th one will.

I like to use some damage build up system. It describes, how many damage a character can get before getting stunned. The damage will build up by every time the character will get hit. After time, the built up damage reduces, which means, after a long time without getting hit, the built up shall be 0 again.

 2.6.4. Effects

Most games use impact animations to show the player, that he actually hit the enemy. This could be blood, sparkles, whatever may look good. Most engines offer particle systems, which makes the implementation very easy. You could use sprites as well.

2.7. Conclusion

By using the four phases, you can create animations ideal for a fighting game. You can prepare to avoid getting hit, you do damage, you can chain attacks and you have a smooth transition to the usual stance.

Keep in mind, the character can get hit at phases 1, 3 and 4. This may lead to cancel the attack and go into a stun phase (which i will cover later).

A simple way to check for damage is by using hit-boxes and damage-boxes.

3. Ways of avoiding damage

Now we are able to deal damage. There is still something missing. Something that makes the game more interesting... Somehow we want to avoid taking damage, right?

There are endless ways of avoiding damage and I will now cover the most important ones.

3.1. Blocking

Blocking is one of the most used ways to avoid damage (at least partially). As the enemy starts to attack (perception phase) we know, which attack he is going to use. Now we should use some sort of block to reduce the damage taken.

Blocking depends on the direction the player is looking. Take a look at this example:

blocking.png.f57db1edd381112e8700690eefa9d49e.png

If the enemy does an attack from the right side, we should not get damage. On the other side, if the enemy hits the character in the back, we should get damage.

A simple way to check for damage is by comparing the x coordinates.

Now you should think about how long the character is able to block. Should he be able to block infinitely? You can add some sort of block damage build up - amount of damage within a specific time the character can block (like the damage build up). If the damage was to high, the character gets into a stunning phase or something like that.

3.2. Dodging

Every Dark Souls player should be familiar with the term dodging. Now what is dodging?

Dodging is some sort of mechanism to quickly get away from the current location in order to avoid a collision with the damage box (like rolling, teleportation, ...) Sometimes the character is also invulnerable while dodging. I also prefer making the character shortly invulnerable, especially when creating a 2D game, because of the limited moving directions.

3.3. Shields

Shields may be another good way to avoid taking damage. Just to make it clear. I do not mean a physical shield like Link has in the Legend of Zelda (this would be some sort of blocking). I mean some sort of shield you do have in shooters. Some may refill within a specific time, others may not. They could be always there or the player has to press a button to use them. This depends on your preferences. While a shield is active, the character should not get any damage.

Keep in mind. You do not want to make the character unbeatable. By using shields which are always active (maybe even with fast regeneration), high maximum damage build up / block damage build up you may end up with an almost invulnerable character.

3.4. Jump / duck

These alternatives are - in my opinion - a form of dodging. The difference between dodging and jumping / ducking is, that you do not move your position quickly. In case of ducking, you just set another hit-box (a smaller one of course). While during a jump, you are moving slowly (depends on your game).

The biggest difference in my opinion is, jumping or ducking should have no invulnerable frames.

 

 

I hope you enjoyed reading and maybe it is useful to you. Later on, I want to update the post more and more (maybe with your help).

If you have any questions or feedback for me, feel free to answer this topic.

 

Until next time,

Lukas

Edited by LukasIrzl

Share this post


Link to post
Share on other sites
JoshGrams    8

That sounds like a reasonable explanation of the collision and animation aspects, but you left out one very important point: fighting games are pretty much always built around a circular rock-paper-scissors aspect so that every attack has a counter and it is a mind game to anticipate what your opponent will do next.  The usual set is punch-block-throw (block stops a punch, throw ignores blocks, punch beats a throw), but you could presumably do other things, adding in more than three options, or having a different three actions.

David Sirlin (http://www.sirlin.net/) has a bunch of writing about the design of fighting game systems and balance.  You have probably seen his work, but if not, you should definitely check it out. Edit: He even implemented the punch-block-throw cycle as a turn-based card game called Yomi where both players select a move from their hands and lay it face down, then reveal them simultaneously.  It has combos, more and less powerful moves, the whole deal.  It's interesting to see that you can have the mind game without the reaction time parts.  IIRC you can try it for free with limited character choices both as printable PDF cards and in the online version.

Edit: Also (and this is minor) I think the tone of your piece could use a little work. It's not bad, but it feels a little amateurish with the vibe of "I experimented and thought things up and here are my ideas" when everything in it is pretty standard fighting-game mechanics. I couldn't find it in a quick search, but there's an article on the internet somewhere that covers almost exactly this same ground, using debug screenshots from one of the Street Fighter games (I think?) as examples. So some acknowledgement that you've done your homework and aren't just reinventing the wheel would make it feel more solid.

And the anticipation/windup frames add a delay between the button press and the actual action, so in games with network play it also serves the purpose of helping deal with network delay and reducing the chance that the game has to be like "Well...we showed you kicking him, but actually he punched you in the face three frames ago, we just didn't know it yet, so...sorry!".

Edited by JoshGrams
Added several more thoughts. Maybe should have been another post, but I'm assuming double-posting is bad?

Share this post


Link to post
Share on other sites
LukasIrzl    207

Thank you.

You are absolutely right. I did spend a little to few time for this aspect. In my opinion it is very important to think of counter attacks and assume what the opponent is going to do. The "mind game" as you called it. I will definitely spend a "chapter" on it.

Actually, I have never seen his work but I will check it out for sure. Maybe I will get ideas from him to implement and to write about.

Up to this point, I truly covered only the standard fighting-game mechanics and my thoughts about them. Later, I want to cover more aspects like gameplay, rock-paper-scissors aspect (which is in my opinion some sort of gameplay), and more which comes to my mind.

I will try to rework the tone of my piece. :)

In my opinion this thread should help me completing my combat system and help others with theirs. That's why I want to keep it as general as possible. (I hope it works ;))

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Similar Content

    • By gdarchive
      In physics, Balance is that point where a specific distribution comes to a standstill. In a balanced composition, all elements are determined in such a way that no change seems possible. The piece must give the feel of steadiness, otherwise, it will just seem off. 
      Rudolf Arnheim, in his Art and Visual Perception book, stands that there are 3 elements to balance: shape, direction, and location. He also says that in the case of imbalance “the artistic piece becomes incomprehensible […] the stillness of the work becomes a handicap”. And that’s what gives that frustrating sensation of frozen time.

      In this simple example, you can see all this. Having the sphere off center gives the sensation of unrest. The sphere seems to be being pulled to the corner almost. It’s if like an invisible force is pulling it from the center. These pulls are what Arnheim calls Perceptual Forces. And with the sphere in the center of the walls, you have the sense of balance, where all the forces pulling from the sides and corners of the square are equal. 
      Returning to physics, we can say that when talking about Balance the first thing that pops into our heads is Weight. And that’s what it is all about, what we think. Because, as I said before, perception is just the brain processing images. So, if when we talk about balancing something we think of weight it definitely has to have something to do with it in art, right? Exactly.
      Arnheim talks about knowledge and weight in balance referring to the fact that anyone who sees a picture of a scale with a hammer on one side and a feather in the other knows that the first one is heavier. If the scales are perfectly balanced it will just seem off. But balance does not always require symmetry, as we might tend to think. Isn’t equilibrium that brings balance. If the scales tilt to the “correct” side (the hammer) perceptual balance would have been achieved.
      In Art, as in physics, the weight of an element increases in relation to its distance from the center. 

      So an object in the center can be balanced by objects to the sides, and objects on one side of the frame must be balanced with objects in the opposite location. But this doesn’t mean that the objects must be the same (symmetry and equilibrium), for there are properties that give objects weight besides their actual apparent weight.
      SIZE. The larger the object, the heavier.

      COLOR. Red is heavier than blue. Also, bright colors are heavier than dark ones.


      ISOLATION. An isolated object seems heavier than the same object accompanied by smaller ones all around it. Arnheim puts the moon and stars as an example here.


      SHAPE. Experimentation has shown that different shapes affect the way we perceive weight. Elongated, taller, figures seem heavier than short ones (even though they both have the same area size). 

      To expand on this matter I recommend you to go back to the books I will reference in the sources down bellow. Even though these are really simple examples, I plan to move on with this theory applied to environment art. 
      The whole take on Balance gives all the world building process a solid base stone. Embracing these principles will help you understand and better plan object placement in your scene to avoid the feared feel of steadiness Arnheim warned us about.
      There is still a bit more to explain about Balance so I will be expanding a bit more on this matter in future posts.
       
      Thumbnail art:  Madame Cezanne in a Yellow Chair, c.1891 - Paul Cezanne
      Sources:  
      Arnheim, Rudolf (ed.) Art and Visual Perception. A psycology of the creative eye. University of California. 1954.
      Bang, Molly. (ed) Picture This. (1991)
      Baker, David B. (ed.). The Oxford Handbook of the Psychology. Oxford University Press (Oxford Library of Psychology), 2012. 
    • By Jacob Laurits Besenbacher Kjeldsen
       
      Intro - "The challenges of dynamic system design"
      Custom Quest evolved during development, from a minor quest system used for our own needs in our own game production Quest Accepted, to something entirely more dynamic and customizable, now finally released, these are our thoughts on quest design and developing standalone subsystems. 
      Splitting what is a major production for a small indie team, into smaller installments such as a quest system was a good idea we thought, this way we can get some releases out there and fuel the development of our game. But building a system that works for yourself is one thing, building a unity plugin that will let other developers create quests, missions, and objectives, you would never have thought of is something else entirely.
      The first thing we had to realize was that when building a quest system, the task is not to design great quests, the task is to enable the users to create great quests.
      That still meant we had to find out what good quest design is and what a quest really is.
      Our task was to create a system where the user is free to create creative engaging and rewarding mission experiences for their players.
      What is a quest? - "Cut to the core"
      First off, we need to know what a quest really is.
      A quest is the pursuit, search, expedition, task or assignment a person(s) does in order to find, gain or obtain something.
      In games, quests and missions function in many different ways depending on the genre.
      A single game can contain a multitude of different types of quests put together in just as many ways. In an MMO, for instance, quests are vehicles for the story and the player's progression. In many cases they are formulaic and simple, some can even be repeated, there are hundreds of them and everyone can do them. In other games quests are for single player campaigns only, here they shape each level giving the player a sense of purpose.
      Quests can span the whole game or just be a minor optional task on the way, there are so many design philosophies and creative quest designs that we had to narrow it down and really cut to the core of what is needed for good quest design.
      What all quests have in common is the task, the criteria for successful completion of the quest, and the reward, the goal of the quest, what the player gets out of doing what we ask of him.
      Quests cover an incredible variety of tasks so it was important for us to base our decisions on thorough research. In our research, we found that there are three layers to quest design.
      The type, the pattern and the superstructure.
      Quest types exist within quest patterns and quest patterns exist within the quest superstructure.
      We found that there are 8 basic types of quests these are the various tasks/criteria the player must do in order to complete the specific quest.
      There are 12 quest patterns. These are ways designers can use their quests, connect multiple quests set them up in engaging ways or teach players how to interact with and get the most out of the game world creating variety and engaging the player.
      Enveloping the patterns is the quest superstructure, the overall structure of quests in the game, we found that there are two main ways of structuring your quests.
      Historically quest have a quest giver, an NPC or object that informs the player about the quest, what they need to do, the story behind it and perhaps even what their reward will be should they complete the quest.
      Quest types - "Do this, do that"
      The core task each quest consists of, the criteria for completing part of or all of a single quest. These are the actions we want Custom Quest to be able to handle.
      Kill
      Probably the most basic quest type, the task is to kill something in the game, for example; kill 10 goblins. Gather
      Again very simple, the task is to gather x things in the game world, collecting berries or the like. Escort
      The player must escort or follow a person or object from point A to B while keeping it safe. FedX
      The player is the delivery boy, they must deliver an item to a person or point. Defend
      The player has to defend a location from oncoming enemies, often for a set number of waves or time. Profit
      The player must have a certain amount of resources to complete the quest, contrary to gather quests these resources are resources the player would otherwise be able to use himself. Activate
      The player's task is to activate/interact with one or more objects in the game world or talk to a number of NPC’s. In some cases, this must be done in a certain order for a puzzle effect. Search
      Search an area, discover an area of the game world. This is useful for introducing areas of the map to the player and giving them a sense of accomplishment right off the bat, showing them a new quest hub or the like. Quest Patterns - "An engaging experience"
      Tasks are one thing, and in many games, that might be plenty but we wanted custom quest to let the users create chains of quests, specialize them and set them up in ways that draw the player into the experience, there are many ways to go about this.
       
      Arrowhead
      The most basic quest pattern, the quest chain starts out broad and easy, the player has to kill some low-level cronies. The next quest is narrower, the player must kill fewer but tougher enemies, lets say the boss' bodyguards. The last quest is the boss fight, the player has killed the gang and can now kill the boss. This quest pattern is very straightforward and works well, giving rewards either at every stage or only when the boss is dead.  
      Side stub 
      A side stub is an optional part of the overlapping quest. Lets say quest A leads to quest C but there is an option to complete a side objective B, which makes completing C easier or it changes the reward, for example. The player must escape prison, the side stub is “free the other prisoners” in this example escaping with all the prisoners is voluntary but it might make it easier to overpower the guards or the prisoners might reward the player when he gets them out. The side stub differs from a generic side quest in that it is tied to the main quest directly.  
      Continuous side-quests
      These are side-quests that evolve throughout the game, one unlocks the next, but they are also affected by external requirements such as story progress. This pattern is often found with party members in RPG games, where the player must befriend the party member to unlock their story quests.  
       
      Deadline
      As the name implies these quests are time sensitive. The task can be of any type, the important thing is that the quest fails if time runs out. This could also be used for a quest with a side quest where the side quest is timed for extra rewards but the main objective is not.  
       
      Deja-vu quests
      This kind of quest pattern gives the player a quest they have done or seen before. In some cases, this “new” quest will have a twist or something that sets it apart. It can also be the same sort of quest that exists in different areas of the game world, perhaps there is more than one goblin camp? or perhaps the player has to pick berries daily.  
       
      Delayed impact
      Delayed consequences of a previous decision. Often used in games where the story is important and the players’ choices matter. These quests are tied together without the player knowing. Let's say the player is set the optional task of giving a beggar some gold to feed himself. The player gives the beggar a few gold and is on his way. The next time he meets the beggar the beggar has become rich and rewards the player for his kindness with ten times what he gave.  
      One of many
      The player is presented with a number of quests, they have to choose which one to complete, they can only choose one. The others will not be available.  
       
      Hidden quests
      Hidden tasks that aren’t obviously quests at first glance or are hidden away for only the most intrepid players to find. This could be an item the player picks up with an inscription in it if the player then finds the person the inscription is about he can get a reward for delivering it. A good quest pattern for puzzles, these kinds of quests can really make the game world come alive and feel a lot more engaging, allowing the player to uncover secrets, Easter eggs and discover all of the world created for them   
      Moral dilemma
      Punish the bread thief who stole to feed his family? often used in games that have a good/ evil alignment level for the players, these kinds of quests make the player make a choice about what kind of character they want to play, they get to choose if their character is good or evil.  
       
      Side quests
      Optional quests, these quests are often found in level based games where the overall quest must be completed to get to the next level, the player can optionally do some extra tasks to get more points. The important part is that these are optional but they give the player a reward for, getting everything they can out of the game.  
       
      Tournament
      Tournament style quests, a series of quests that get harder as the player progresses. An example could be a gladiatorial arena if the player defeats five enemies one after the other he gets rewarded as the champion of the arena, but if for example, he fails at the third, the whole tournament is failed and he has to start all over from quest 1.  
       
      Vehicle missions
      Despite the name these quests are not confined to being about cars, these are simply quests where the players control scheme changes to complete the quest(s). An example could be; changing from running around in the game world to driving a tank to destroy a fort.  
      Quest superstructure - "The whole package"
      With quest superstructures, we are venturing into general game design. The superstructure is how the player is allowed to complete quests in the game world. It's basically a question of whether the game is “open world” or a linear experience.
       
      The diamond structure 
      The open world model, think games like The Elder Scrolls V: Skyrim, the player is introduced to the game through a quest, but after that, they can go wherever and do whatever quests they want. There are tons of quests of the above types and patterns, the player is free to pick and choose which to do, giving the player the illusion of freedom within the game world (the diamond). However, the game still ends by completing a quest that is locked and always a requirement to complete the game. This can, of course, be varied by different choices the player has made throughout the game or even have multiple endings. Quests can be concentrated into quest hubs, i.e. towns with lots to do or the like, but they don't have to be completed in a linear fashion  
       
       
      Linear hub structure
      This structure consists of a number of required “bridge” quests that need to be completed in order to unlock the next area or “hub”, each hub can have any number of quests, this could be a town full of people in trouble, each with their own quests and quest chains to complete, when they are all done, the player moves on to the next hub through another bridge quest. Limiting the quest size of the hubs will make the quest structure feel more linear and thereby the game linear, and creating larger more open hubs can make the player feel freer.  
       
      Outcome - "So many options!"
      The development of custom quest has been the quest to allow game developers to create quests and missions that use these types. However, no matter how well we have researched, some one will come up with a new and creative way of doing quests.
       
      The solution for us was to make the system more customizable. Letting users convert their quest prefabs to quest scripts that automatically inherits the core functionality, so the user can freely add their own additional functionality on top of the existing core
      Asset development as fuel - "A learning experience"
      Developing this way, splitting the production into sub systems that can function on their own and even be used by others is not something that should be taken lightly, but if you can build something lasting, something others can find value in using, then the final product will be all the better for it. Custom Quest started as a project we thought could be completed in a couple of months, it ended up taking 7.
      In part this is because we realised that if we were going to release the system, we might as well do it right, that meant creating a system that was customizable and robust, a system that can be added to the users game and not the other way around, a system we could be proud of.
      The experience of developing for other developers is quite different to developing a game. One that has made us much stronger as programmers and as a company, it forced us to think in new ways, in order to create a dynamic and customizable solution. Custom quest has evolved from an asset we could use in Quest Accepted, into a tool others can use to create a unique game experience. All in all, the experience has been a good one and Random Dragon is stronger for it, I would, however, recommend thinking about your plugin and extra time before you start developing.
       
       
      Sources:
      www.pcgamesn.com -"We know you aren't stupid" - a quest design master class from CD Projekt RED
      http://www.pcgamesn.com/the-witcher-3-wild-hunt/the-witcher-quest-design-cd-projekt-masterclass
      http://www.gamasutra.com/ - Game Design Essentials: 20 RPGs - http://www.gamasutra.com/view/feature/4066/game_design_essentials_20_rpgs.php?print=1
      Extra credits - Quest Design I - Why Many MMOs Rely on Repetitive Grind Quests https://www.youtube.com/watch?v=otAkP5VjIv8&t=219s
      Extra credits - Quest Design II - How to Create Interesting MMO and RPG Quests https://www.youtube.com/watch?v=ur6GQp5mCYs
      Center for Games and Playable Media - Situating Quests: Design Patterns for Quest and Level Design in Role-Playing Games - http://sokath.com/main/files/1/smith-icids11.pdf
      Center for Games and Playable Media - RPG Design patterns https://rpgpatterns.soe.ucsc.edu/doku.php?id=patterns:questindex
       
      Special thanks to Allan Schnoor, Kenneth Lodahl and Kristian Wulff for feedback, constructive criticism and background materials.
    • By francoisdiy
      This is the only way to obtain a copy of Francois DIY.
    • By codeliftsleep
      I'm building an American football simulation(think football manager), and am wondering about the best way of implementing AI based on various inputs which are weighted based on the personality of the NPC...I have a version of Raymond Cattell's16PF model built into the game to be able to use their various personality traits to help guide decisions.
      I am going to use this extensively so I need this to be both flexible and able to handle many different scenarios.
      For instance, a GM has to be able to decide whether he wants to resign a veteran player for big dollars or try and replace them through the draft. They need to be able to have a coherent system for not only making a decision in a vacuum as a single decision but also making a decision as part of a "plan" as to how to build the team...For instance it makes no sense for a GM to make decisions that don't align with each other in terms of the big picture. I want to be able to have the decisions take in a wide range of variables/personality traits to come up with a decision. 
       
      There is no NPC per se...There isn't going to be any animations connected to this, no shooting, following, etc...just decisions which trigger actions. In a situation like a draft, there is one team "on the clock" and 31 other teams behind the scenes working on trying to decide if they want to try and trade up, trade down, etc which can change based on things like who just got picked, the drop off between the highest graded player at their position/group and the next highest graded player in that position/next group, if a player lasts past a certain point, etc...
      There needs to be all of these things going on simultaneous for all the teams, obviously the team on the clock is goifn to have to decide whether it wants to make a pick or take any of the offers to move down in the draft from other teams that might want to move up, etc..
      So I am planning on making use of something called Behavior Bricks by Padaone Games( bb.padaonegames.com )which is a Behavior Tree but in conversations with others who have worked on AI in major projects like this(EA sports) they said to combine this with a State Machine.
      My question is would I be able to do this using just Behavior Bricks or would I need to build the state machine separately?  Is there something else already created for this type of purpose that I could take advantage of?
  • Popular Now