Answer the question
In order to leave comments, you need to log in
How to learn to design game logic?
Actually
, a philosophical question arose during work.
I have been picking django for a year now (this is not particularly important, the same can be done on laravel and other frameworks) I am slowly writing a text game, sometimes I ask technical implementation problems, they answer me, thanks to all the participants.
I wrote various jokes (the hero's inventory, things falling out, all sorts of different small buns) and got to the implementation of tasks, and then the donkey.
Suppose my storyline has 73 main quests and 34 side quests (of course, the rewards for the quests are different: gold, silver, equipment items, potions and other nonsense)
Previously, I asked a question about the implementation of tasks and how to store such logic in the database (tasks with different types of rewards, etc.) I was offered to store different types of tasks in separate tables (initially I leaned towards serialization and other similar methods), in the end I decided to do as advised
Actually question
There are 73 tasks mentioned above and 34 side tasks (some of them can be done along the way, some as the previous ones are closed, etc.)
Several implementation options appeared in my head from a technical point of view
1) stick 1000 if elif
2) store names, id completed in array and each time a new task is accepted, pull out completed ones - this, in theory, will reduce the number of conditional structures
As a result, I don’t understand how to do it right, whether my implementation methods are optimal or they are generally nonsense
. Just implementing my methods, the code will turn into a living hell, which, not only that someone else can’t make out, but I’m already on the trail. I'll hold my head for the day
Answer the question
In order to leave comments, you need to log in
Each task has its own graph.
Common nodes between these graphs (if any), cross triggers (also, if necessary) are determined.
The main "runner" on the graph (there may be several!) has:
1. id of the main/current task and
2. id of the node on the graph of this task (the next expected control point of the progress of the current task).
These 2 parameters - you always store as the current state of the player in relation to tasks.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question