For the final semester of University, we must develop a game within a medium-sized team of 13 people.
The team of programmers consists of four people and I'm responsible of the game's core and backend.
What I love about working behind the scenes is that I need to identify with other programmers and think of the best way for them to develop a game, not for me. Plus, almost each part of the game somehow has my signature on it, as it's heavily based on code I have written. I love this responsibility.
Now, without getting into too much detail on what the game is about, its main mechanic was inspired by Baba Is You: the player is able to change the environment, trigger events and, more generally, change the rules of the game itself.
The video below shows a very early implementation of a tutorial level, with "rule boxes" that, once aligned to form a syntactically correct sentence in English, will trigger the behavior the sentence describes (Gate is open).
Now, my primary goal was to make it really easy for all the other programmers (and me) to quickly script a reaction to an arbitrary rule for a game object, without code duplication and with as few constraints as possible.
Let's see how I've scripted the behavior of the gate above:
As can be seen, I simply had to inherit from the MutableEntity class and specify in the relative Is and UndoIs methods which words to react to and how.
The only constraint is that the game object that the script Gate is attached to, must be tagged as Gate in order to react to any rule that has the word "Gate" as a subject.
Please note: I know that lexemes should not be hardcoded strings in the script, this was just a small thing I quickly made to test the core.
I'm really happy about how simple it is to add reactions to any arbitrary rule the game designers will think of.
Let's now see how I've implemented it under the hood:
For this post, we can just ignore the Automaton and State classes, which simply implement the State Pattern from my beloved Gang of Four. I'll talk about that part in another post.
Now, MutableEntity is an abstract class that provides 6 default virtual methods: our game rules will only use three verbs ("is", "has", "can"), so the class provides 3 methods for applying each verb and 3 methods to undo each verb.
These methods, in their default implementation, simply log some text.
Each game entity that reacts to rules, must have its own specific script that inherits from MutableEntity.
A careful reader might have two particular questions in mind:
1. Why did you choose to make it an abstract class if there's no actual abstract method? Because those methods are dummies and I want to force programmers to implement their own methods.
2. Yes, but why not simply making it an interface, if it's eventually mandatory to implement concrete versions of the methods?
Because game entities don't have to specify reactions for every possible verb, but only the verb(s) they're interested in. For example, the gate only reacts to "is open", so it would be pointless (and annoying!) to always have to implement 6 concrete methods for each game entity.
As a last observation, it is true that a programmer is potentially allowed to inherit from MutableEntity without specifying any method override: this is true, but my job is to make life easier for programmers, not to cure stupidity.
I'll cover the implementation of the actual rule system in another post, as I prefer to avoid overloading each post with information and keeping them a somehow pleasant read. I hope.
Comentários