Back to General and Gameplay Programming

How do I design this kind of feature?

SYJourney · 2016-05-12T19:51:51

There is this kind of design problem that I seem to encounter with every game I try to make. Basically, I will try to take into account some feature that just doesn't seem to fit into how I coded so far. Most often it's an item or special ability that a player can use. For example, I want different items which can do the following: - Transport the player to a different level - Increase some stat of the player - A key which opens a door if you are standing in front of it - Change the player's sprite The question is where in my code do I put all this stuff? The kind of design I'd actually want is something like this: class ItemEffect { public: virtual void use() const = 0; } class WarpItemEffect : public ItemEffect { WarpItemEffect(int target_level_id); void use() const override; } class KeyItemEffect : public ItemEffect { KeyItemEffect(KeyType key_type); void use() const override; } So suppose I have some "Item" class. When I create a new instance of the class I will then simply plug in the subclass of ItemEffect I need. To me as an amateur this seems pretty good so far. But there's an obvious problem. If we take the key example, I most likely will need the "Player", to know which direction he is facing, then I need the "Level", to check if there is a door in front of him, and then I need to open the "Door". All these are things which I cannot just code within my "use" method. If I tried implementing it I'd most likely end up with something like this: void KeyItemEffect::use(const IPlayer& player, ILevel& level) { Direction direction = player.getDirection(); Position position = player.getPosition(); IDoor* door = level.findDoor(position, direction); if (door) door->unlock(key_type); } So what's happened is that half of the code which actually does something is now in the other classes. I guess that for Level::findDoor(), I can probably find other uses but the main problem is: If I continue this, I will end up with more and more methods in "Level" (or other classes) which just execute services specific to ItemEffects. So how can I design this so that it makes sense?

General and Gameplay Programming Programming

Started by SYJourney May 04, 2016 09:52 PM

9 comments, last by SYJourney 7 years, 11 months ago

SYJourney

230

Author

May 12, 2016 07:51 PM

Thanks for the advice. After reviewing all of it, here's a rough sketch of what I'm using now:

Item effects such as in the OP and similiar sequences of events will be scripted. For the scripts I use my own syntax which translates to how I handle messages in game. The way I will create the scripts is by using a GUI where you can drag and drop more abstract tasks into a structure, edit their properties etc.

In the c++ code I have an interface 'ITask' which declares an 'update' and an 'is_done' method. Every component in my game that receives these tasks has a container which calls update on all it's tasks and removes them once they are done. This way I can treat all actions as happening over a certain period of time. Actions which occur once just always return true for 'is_done'. Then I also have some special implementations of 'ITask' which are composed of other tasks. For example 'TaskSequence' which is a queue of tasks, updates it's front task and is done when the queue is empty. Or 'TaskBranch' which evaluates an 'ICondition' once and then delegates to it's sub-'ITask' mapped to the result. So essentially the core of my design is that all of these are 'ITask's, so I can combine asynchronous/synchronous processing, branching logic (and whatever else I can come up with) arbitrarily.

How do I design this kind of feature?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

How do I design this kind of feature?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines