Muffin Projects
boosty
Techlog #2. Experimental. Practical Example. Quests [en]
🕑 Added 2023-05-03 19:00:00 +0000 UTCLet's analyze a code example related to the quest system in the game.
id - a unique identifier. Specifically, I need it to be able to find the instance quickly if there is an urgent need.
name - the name displayed in the quest window for the player.
description - the description displayed there.
steps - a list of steps for the quest. In the game, you may have noticed that quests can have multiple steps.
reward - a list of rewards. By default, it is an empty list.
availability - a string with a boolean expression to check the availability of the quest.
I arrived at this solution not immediately, but when I encountered the need to make changes between updates. I had to fix names, quest availability, and rewards manually by finding the instance in the store module and rewriting the necessary fields. I decided that I didn't want to deal with this hassle, and the only value I wanted to remain permanently valid was its "done" flag. In other words, it indicates whether the quest is completed or not.
Let's go through the other methods of the class:
The class structure for quest steps looks almost identical. They are essentially smaller quests.
Here's how an instance is created:
You may notice a few other methods like set_variable and is_quest_done. These are small utility functions.
I couldn't come up with a smarter way than storing functions as strings for the reward and availability fields. The reason is that after completing a quest, I want a series of functions to be executed, which will provide rewards to my character, such as stat upgrades, completion of other quests, adding new steps, or anything else my imagination allows.
The eval function is a standard practice in almost every programming language. It converts your string into executable code. If I simply wrote the functions there, the list would contain the results of their execution, which would make no sense at all.
The same situation applies to availability. Why is it even necessary? Often, I want a quest to become available only after the player fulfills certain conditions. Once all conditions are satisfied, the player will finally receive the quest.
is_quest_done is a simple method to check whether the quest is currently in the player's active quests and if it has been completed. In the above code example, it is used so that when a player enters a new version of the game, they will immediately receive this quest if it is available to them because it wasn't even declared in earlier versions of the game.
What does label_translation[key_name] mean? The thing is, RenPy doesn't allow you to add translations using standard methods for strings declared within Python code. That's why I create a separate dictionary for translations of such strings.
It looks something like this:
It looks something like this:
![Techlog #2. Experimental. Practical Example. Quests [en]](https://img10.patrefans.com/storage/7/tz/ss/563145-019e8d9d-8dc1-736a-9c73-b8fcdcfdbb4a.png)
![Techlog #2. Experimental. Practical Example. Quests [en]](https://img10.patrefans.com/storage/1/gf/zm/563145-019e8d9d-8dc1-73ae-bcb5-0be590e02ab9.png)
![Techlog #2. Experimental. Practical Example. Quests [en]](https://img10.patrefans.com/storage/5/aw/hz/563145-019e8d9d-8dc2-7895-bb71-be2f3c2a26f4.png)
![Techlog #2. Experimental. Practical Example. Quests [en]](https://img10.patrefans.com/storage/12/ks/nc/563145-019e8d9d-8dc3-7ce6-bda8-c1a7c5baecf3.png)
![Techlog #2. Experimental. Practical Example. Quests [en]](https://img5.patrefans.com/storage/12/cc/pb/563145-019e8d9d-8dc6-7713-be8d-482b335ecaae.png)
![Techlog #2. Experimental. Practical Example. Quests [en]](https://img10.patrefans.com/storage/8/up/ud/563145-019e8d9d-8dc6-7e5a-ae02-60cf4909a28f.png)
![Techlog #2. Experimental. Practical Example. Quests [en]](https://img10.patrefans.com/storage/8/tl/af/563145-019e8d9d-8dc7-7193-b493-f7b34215292b.png)
![Nightmare O-G-A [ Nighmare anime ] from patreon](https://patrefans.com/kistorage/25816.jpg)
