GSoC 2019 - First Week
After an entire month of community bonding (which also included playing the game, setting up the development environment, and overloading the mentors with questions) it was finally time to start the official development period of (GSoC).
A plan depends as much upon execution as it does upon concept
Before starting the actual coding, there were two things to be done (for the record: there are always things to be done before you start coding). In this case, Terasology’s GSoC project structure includes a list of “Pre-GSoC action items” related to project management. From a macro perspective, the list items were:
- Setting up the communication and reporting mechanisms (Slack channel, Forum thread, blog, etc.);
- Arranging a weekly meeting with all mentors;
- Creating and populating the associated GitHub board; and
- Considering the API impact of the future code.
The first two items were painless, but the other two - oh, boy. After some time working in software development, one usually learns that development scheduling works better with enough evidence. Still, it is important to plan in advance what features you will be programming, how you intend to do it, what is your timeline, etc. And yet - it will change, probably (definitely). With that in mind, I created the initial tasks based on my GSoC proposal. Now, all that was left was considering the API impact. “All that was left”.
It begins, as most things begin, with a song
Another of those things that you eventually learn is that one spends much more time reading than actually writing code. This is especially true for the project at hand: we are messing with things under the hood, and that alone involves a lot of consideration. Also - the objective is to implement something that can be done in many different ways, from both the theory and the coding perspectives. That means reading a lot.
I tend to work well with (ever-changing) lists, so I created one to prioritize - well, the reading - considering both the project topic and context:
- Everything about how the current system works (always a good starting point);
- Articles related to Behavior Trees and their use in game development;
- Existing Behavior Tree implementations used in games (it is always nice to see what everybody is doing before trying to reinvent the wheel); and
- Alternatives to Behavior Trees for group-oriented behavior in games (it is also nice to know why people are not doing what you think is a good idea at the moment).
Terasology uses an Entity-component-system Architecture, which is an architectural pattern mostly used in games. This pattern promotes strict separation between logic and data, and it is composed by:
- Entities (used to identify each unique object in the world, including players and NPCs)
- Components (used to store all data related to an Entity, including features and behaviors)
- System (providing all logic behind a component or a combination of components)
After considering different alternatives (as in “long story short”), I finally decided to adopt a hivemind-like structure. Behavior Trees are used in Terasology to assign pre-defined behaviors to single Entities. The objective of this project is to develop a collective behavior mechanism for NPCs, which translates into “making a group of Entities behave as one”. The keyword here is group - before creating a collective reasoning mechanism, the grouping mechanism must be defined. We discussed a few ideas on Discord - for example, a group could be befined by a leader entity, which would also determine the behavior for the rest of the group - but this would lead to other problems (leadership transfer - in the case the leader dies, or superposing group behaviors - I will not go through the entire list here, but you are invited to access the #ai channel on Discord and follow the discussion).
Also following Terasology’s GSoC project structure, the students are encouraged to publish a weekly report following a specific template:
What have you achieved in the last week?
- Read a lot of articles related to BT (full biblio to be documented on the blog post)
- Checked existing code to see how other people were doing it
- Determined a general hivemind structure
- Housekeeping: updated Trello, created blog, structured planning, updated forum thread
- Overview: initial planning
What are you currently working on?
- Creating the collective behavior model
What problems are you currently facing?
Is anything blocking you from making progress?
List of PRs and opened/closed Issues
Something else (pictures of new content, code snippets, new wiki content, …)
- Blog address: https://casals.io
In the weekly meeting, we:
- Went over the initial planning
- Discussed the different models that could be used for grouping Entities