S
S
Sanya Hihi Haha2020-05-20 10:50:43
Game development
Sanya Hihi Haha, 2020-05-20 10:50:43

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

1 answer(s)
X
xmoonlight, 2020-05-20
@ValarMayar

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 question

Ask a Question

731 491 924 answers to any question