Muffin Projects

Techlog #1. Experimental. Basic concepts. Classes [en]

Added 2023-04-28 16:00:00 +0000 UTC

Disclaimer: The blog author uses Python only as a hobby for game development. They are not familiar with all the intricacies of implementing internal mechanisms. They might even appreciate it if you could help them with some questions!

Since the previous poll chose the category of basic concepts, I will talk about the most commonly used construction in my project - Classes. I will try to explain everything in simple language and provide game examples without diving into technical details.

Classes in any programming language are structured mostly the same, but what do they represent as a whole?
A class is an excellent way to describe an entity in your game, whether it's a Quest, Item, Character, etc.

Here's an example of the syntax in a RenPy project:

This is how a class for the Quest entity looks in my project, which I use for quests in the game. Before writing Python code inside a file with the .rpy extension, you need to wrap it in "init python:".

Then comes the actual class declaration.

Inside the parentheses, it says (object) - there's no need to delve into the details; it's how classes are created in Python 3.

def __init__(self, parameter_list) - this is what we specify when initializing an instance of the class in the game. For example:

As you may have noticed, in this example, when creating an instance, I didn't add a couple of fields - reward, and availability. That's because I set default values for these fields in the class initialization.
This means they are not required to be specified, but if you wish, you can specify them.

- Why does it this way?

- To avoid writing unnecessary properties a thousand times, which are often the same everywhere.

If you want a field in the class that will be the same for all instances 100% of the time, simply don't write it in parentheses and specify it in the block itself, as shown with the "done" field.

However, in this specific example, it's more complicated. Let me know if you want to read about the mechanics of quests in my game.

A quest should have the property of being completable. In other words, its "done" property should be able to change its value upon our command.
Inside the class, we can define a method/function.

The "finish" method changes the value of our quest instance to True, marking it as completed, and displays a notification using the built-in method renpy.notify() (a black bar with text on the left).

The rest would require a separate post on the mechanics of quests in the game.

Apart from __init__, classes have many other built-in methods.
One useful one to mention is __getitem__.

In the screenshot, there's an example of a class with character stats. For example, to be able to access them directly from the stats object, I need to declare this method so that later in the code, I can perform checks simply by writing:

Another useful feature is the @property decorator for methods.

If you want to obtain the calculated result of certain fields inside an instance of the class, you can declare it as follows:

This example is from the Time class in our game for managing time. It simply checks whether the current day is a weekend as a result of the calculation.

Naturally, there is much more information regarding classes. However, I believe we should keep the text shorter to fit the format. Please leave comments about the format of this blog! It's essential to know what can be improved, etc.

Next up is a blog about the time mechanics in the game, and then we'll see based on the situation.