How do you handle tasks

[Rick]

I'm just curious if people have a well organized way of handling some tasks that happen in a game.

 

For example, let's say you have an RPG fighting game. When you attack someone with an ability (let's say fireball) you need to:

 

1) Reduce player mana

2) Put the ability on CD (possibly)

3) Play the animation to shoot the fireball

4) When the fireball hits the target destroy the fireball

5) Play hit animation on the target

6) Calculate the damage and apply it

 

 

In this case it's all in sequence. In the case of a simple sword attack the hit animation and and damage calculation might happen at a certain point in the animation being played to make things more exact.

 

My question is does anyone have a more formal generic task system they use to do all this or are they just kind of loose with coding these things directly into an action, player, whatever class.

 

I'm toying around with the idea of having Action classes that do specific things with the parameters passed to them, and bundling them up in a Task which will do the Actions added to it in sequence.

 

I feel like this can help bundle things neatly but curious as to what others do or would do.

[ESP]

Number 2, put on cd?

[Rick]

Sorry, cd = cooldown.

[Road Kill Kenny]

Number 2, put on cd?

 

cd = cooldown

[ChrisMAN]

I use events / pub-sub for most everything. You have to be careful about cleanup though.

[Josh]

1) Reduce player mana

this->mana -= 5

2) Put the ability on CD (possibly)

this->fireballoktime = Millisecs() + 3000// time when it's okay to use this again

3) Play the animation to shoot the fireball

this->currentanimation = 3 //animation gets adjusted somewhere else

 

4) When the fireball hits the target destroy the fireball

5) Play hit animation on the target

6) Calculate the damage and apply it

 

The fireball should be its own self-contained class, that has nothing to do with the player. This is what I would do, in a collision callback:

function Collision(entity0,entity1,position, normal, speed)
{

Fireball* fireball = (Fireball*)entity0->GetUserData()
Player* player = (Player*)entity1->GetUserData()
player->health -= 5
player->currentanimationsequence = 3//or whatever it is
delete entity0
}

 

Of course you would want to check the collision type and make sure entity1 is a player and has a non-NULL userdata value.

[Road Kill Kenny]

The fireball should be its own self-contained class, that has nothing to do with the player. This is what I would do:

function Collision(entity0,entity1,position, normal, speed)
{

Fireball* fireball = (Fireball*)entity0->GetUserData()
Player* player = (Player*)entity1->GetUserData()
player->health -= 5
player->currentanimationsequence = 3//or whatever it is
delete entity0
}

 

Of course you would want to check the collision type and make sure entity1 is a player and has a non-NULL userdata value.

 

Yes totally agree here. Any projectile should be it's own thing in this kind of settings

[Furbolg]

I would use

 

- Global Eventsystem

( left mouse click => generate event "attack" -> animationsystem::playanimation, bulletsystem::create ..... )

 

- Bullet/Projectilesystem

( like Joshs post )

 

- Auras

( when the enemy can be frozen/burning (damage over time) or other stuff just define a "aura" and apply it to the object )

 

- Animation/Sequencesystem

( like the system Engineer Ken uploaded (maybe a bit more extended) in cooperation with eventsystem )

 

 

This is only my idea/approach, maybe it works also for your project.

[Pixel Perfect]

The projectiles used in my spell casting system are instances of a projectile class, everything from the creation to the destruction of the visible projectile and associated effects is controlled by the class:

 

http://youtu.be/yA60NJ4PeUc

[Rick]

I was hoping for cooler systems . I find when doing things the "brute force" way things end up "messy" and a certain class ends up way bigger than I care for.

[Road Kill Kenny]

I was hoping for cooler systems . I find when doing things the "brute force" way things end up "messy" and a certain class ends up way bigger than I care for.

 

Well it's a bit complex to explain fully in a topic post cuz there are a lot of systems involved in this process.

 

For my game I actually made a class called the Entity Exchange which manged and moderated interactions between the entity types in the game. Part of the reason for this was to keep it all centralized in one place so it didn't get too clustered up.. and another reason was for future proofing sake if I wanted to change my system to be online or multiplayer so that interactions can be moderated to avoid cheating & make the server in charge.

 

It doesn't exactly make it a faster approach but it kept it all in once place so that it was clean and simple to understand if anything went wrong. Each player, npc or other important entity was registered to the EntityExchange with a specific ID. If something wanted to do damage to something else it would have to request the Entity Exchange to do the damage. The player would calculate the outgoing damage and send it to the EntityExchange with a reference to the ID. The Entity Exchange would then check if the damage was warranted (only if necessary) and then it would send the damage to the target entity (usually an NPC). The target entity would receive the damage and then calculate the incoming damage / actual damage... (i.e. the outgoing damage altered by mitigation factors such as armor) and then the damage would be applied.

 

I gave an example with damage, However, my system was able to affect any stat that an NPC had as well as, passing buffs, debuffs, damage, healing (which was just negative damage), giving items, using items etc. etc. etc. It was all moderated and managed by one central hub.

 

I cbf explaining this before but since you were hoping for something different I thought this might be interesting.

 

I don't even know if this is a good way to do it. But I really don't care because it worked... and worked well. If there was ever a problem you knew exactly where to go to find it. In the EntityExchange.

[Roland]

Well it's a bit complex to explain fully in a topic post cuz there are a lot of systems involved in this process.

...

...

 

As usual you are full of good ideas

[Rick]

Yeah, there you go. That's more like what I was looking for. I'm interested in systems, not health++. Thanks for sharing your system.

[Furbolg]

Some people use a "Entity Exchange", others an EventSystem and others hardcoding.

 

Its a question about what you prefer. There is not a "must have" system. Maybe you can take a look at an Entity Component System.

[Rick]

@Furbolg I understand that, but there are often other systems that maybe we haven't thought about before and can learn from each other and so I enjoy talking more system design than the normal "When is LE3 coming!!!!" topics that are dominating the forums. Trying to get the creative juices and ideas flowing.

[Pixel Perfect]

... I enjoy talking more system design than the normal "When is LE3 coming!!!!" topics that are dominating the forums. Trying to get the creative juices and ideas flowing.

+1

[Furbolg]

@Furbolg I understand that, but there are often other systems that maybe we haven't thought about before and can learn from each other and so I enjoy talking more system design than the normal "When is LE3 coming!!!!" topics that are dominating the forums. Trying to get the creative juices and ideas flowing.

 

Yea i know, and its no offense. Just meaning do it instead of "try doing it perfect" (and never finish)

 

This community is so helpful and great, surely we learning from eachother.

 

 

ps. "When is LE3 coming ???? STFU and take my money !!!

[Pixel Perfect]

... Just meaning do it instead of "try doing it perfect" (and never finish)

That also is good advice! The game player is generally completely oblivious to what code is running underneath it. As long as it works it's achieved it's purpose.

 

Sure its nice to have elegant code etc and it certainly pays to make it as maintainable as possible but there is a real danger of getting too 'hung up' on the technicalities and over complicating systems for the sake of it.

[Rick]

I find myself thinking about these design things inbetween or on the side of making a game. It's sort of like baseball. During practice I might try different kinds of pitches but during a game I stick with the pitches I know, but over time because of this practice I'm doing I'll soon know and use a pitch I practiced in a game.

 

So given this practicing time, that's where I like trying to make it "pretty" and "neat" in isolation and not part of a game

 

 

I had a game I was working on where I created a queueing task system like The Sims. I'd have a Tasks class which held Actions. Actions were like MoveTo, Speak, ChopWood, and they would be done in sequence. The biggest reason for doing something like this was because of the time it takes to do the action. They are not actions that can be done instantly. They need to be done over time and so the game loop has to keep going while this is happening. Without some kind of system like this I find the code ends up getting pretty messy and hard to maintain trying to manually handling all these states.

[Pixel Perfect]

Well I guess traditionally those types of things tend to be handled by Finite State Machines or Behaviour Trees simply because they have been designed to do exactly this and make it easier to handle the logic. Not that is necessarily easy even with these tools, it depends on the complexity you are building!

 

But yeah, its good to explore different ideas and systems. There is little substitute for real experience, its a great teacher!

[Rick]

Yeah, Behaviour Trees can sort of handle this but they generally are used for AI to make decisions. The things I describe above aren't making "decisions", they are doing what the player wants to do. The player made the decision already, and now the actions just need to play out and should not make decisions on their own as they are playing out. Slightly different than what Behaviour Trees are generally used for.

 

I think the Task system I decribed can be looked at as sort of a State Machine that chains the states together to be played out in sequence which sort of blends State Machine and Behaviour Tree ideas together. The chaining part being Behaviour Tree and the executing each state being State Machine.

[Pixel Perfect]

Well yes, but I assume your object knows how to do what it needs to do, so once the AI directs it to do so it does so. If the state is 'Chop Wood' then that inevitably leads to the playing of the Chop Wood animation, sound effect etc and anything else that is associated with that until such times as the state changes. How you choose to package that up is up to you I guess. The FSM for instance facilitates this by allowing you to code actions within the state with transitions in and out of it. It's not just about making 'AI' decision as to which state it is in as about ensuring it does whatever you need it to do within the state. If your game objects are designed well that could be as easy as a series of calls to other objects.

[Rick]

Well yes, but I assume your object knows how to do what it needs to do

 

No, the objects (if meaning like actors, trees, weapons, etc) don't know how to do the tasks, they just know about the task classes. Classes for each task knows how to do the task on said object. The more actions you have the more your object code starts getting big and messy if the logic of doing said actions are directly in these object classes.

 

So I would make an Action/Task child called MoveTo, which takes the object to work on and the destination to move to, and it's update method gets called over every frame and actually does the Action on said object. I like this style because technically speaking ANY object can do these tasks without having to be part of a hierarchy as in most cases to inherit the task functionality if it's directly in said object. You could put a MoveTo() function inside a MoveableObject, which is parent to Actor, etc, but now you are tied to this hierarchy for functionality, where in my example the hierarchy is more for data instead of functionality. It breaks functionality down to classes to avoid having to mess around with hierarchy restructuring that often happens. Now I know this breaks some idea behind OOP, but it adds benefits that I find very attractive escpecially in game dev.

 

Adding a factory design to these actions can then make things very dynamic where any object can perform said task via a string representation of the action. You can also make a plug-in system for new actions because they are their own classes are not tied so close to a hierarchy of existing objects.

 

I believe this system opens the door for a very flexible game dev experience and would be great in an actual game engine where people can just define actions in isolation. The only thing needed is a data contract between what actions need data wise from the objects they do their action on.

 

I love talking about this stuff btw

[Pixel Perfect]

Yeah, its always interesting to see peoples approaches and discuss these things.

 

No, the objects (if meaning like actors, trees, weapons, etc) don't know how to do the tasks, they just know about the task classes. Classes for each task knows how to do the task on said object. The more actions you have the more your object code starts getting big and messy if the logic of doing said actions are directly in these object classes.

Well with FSMs the states are classes in their own right and this is where the actions are defined. The NPC knows how to do things by virtue of the FMS states its assigned, its not hard coded in the NPC class!

 

The end effect is the same, the AI determines what Action should take place and then some mechanism tales over and invokes whatever is required. In my case the NPC's FMS calls the animator to run the animation, the sound manager to run the sound, the path manager to move the NPC. In your case you construct some Action/Task object that essentially does the same by the sounds of it.

 

Two different ways of looking at the same thing as far as I can see.

[Pixel Perfect]

Out of interest Rick, how would your action system handle say an 'Attack' action which may be implemented differently depending on the character it's being assigned. With your system being abstracted from the actors how do you handle this?