GSOC 2019 Final Report

Summary

After more than 12 weeks of development, it is time to close this summer of code 2019 project! Over 30 total pull requests have been made over the course of the project, with 58 commits & approximately 8000 lines of code added to the Metal Renegades repository alone! It has been an incredibly busy few months.

This project involved taking a new gameplay module proposal posted on the forum here, and implement the technical backbone of the world, so that the core gameplay can be built on top of it. This ended up primarily consisting of AI characters, but also included other aspects, such as player needs, and getting rid of some underlying technical issues.

This repository has been worked on in collaboration with Wabadump in their GSOC project. We both happened to make proposals in the same area, so we cut out as much overlap as possible & both worked on different sections of the module. In some areas the proposal tasks were slightly altered due to it already being completed by the other, but this didn’t cause any major troubles.

In comparison to the proposal

In my original project proposal, six core tasks were presented. These proposed tasks were all completed in some way. However, since many of these tasks were open-ended, some of them were completed to a greater extent than others:
  1. World Generation: I had greatly overestimated the amount of time required to complete this; scheduling the first four weeks to complete this. In addition, this was one point of intersection with Wabadump’s project, and since their project started earlier, this task was already completed before I even made my first commit! I only made one change in this area, adding ore generation.
  2. Settlement Generation: Much like world generation, the time commitment here was greatly underestimated, as this was completed by Wabadump as part of their project fairly quickly. Again, only one change was made by me in this regard, adding a well building to city generation.
  3. NPC AI: This task easily took up a large majority of the project. The main proposed feature here was the needs-based behavior system, which has been entirely completed (in the biggest pull request of the project). However, two additional pieces were unable to be completed, due to previously existing technical issues with the systems involved:
    1. Pathfinding: Attempting to get pathfinding working sucked up a lot of time in the project. Lots of progress has been made (and lots of pull requests too), but pathfinding is unfortunately not fully functional yet. This was largely due to the old pathfinding behavior nodes depending on an older pathfinding implementation, and crashes/errors caused by serializing pathfinding objects.
    2. AI Persistence: An opportunity was never presented to test the stability of characters while far away from them, since character movement wasn’t stable enough to provide a consistent testing environment.
  4. NPC to Player Interaction: Like tasks 1 & 2, this task overlapped with Wabadump’s project, basic quests & dialog was integrated around the late end of GSOC as part of their project, leaving me more time to work on the NPC AI.
  5. Faction System: This was completed in the last month of the project as scheduled. Faction spawning & aggression has been implemented. However, one final leg of this task is yet to be completed; the dynamic faction alignment of the player.
  6. Player Needs: This task was completed very similarly to the faction system. It was completed later in the project, with hunger & thirst integrations into the module. The last leg of this task, the rest need, is yet to be completed.

Project Achievements

Dynamic Citizens

The largest task completed in this project was the addition of new AI characters in three types, with behaviors based on their individual needs. Each character acts according to their own behavior tree, which is run on each character individually. The trees are built out of various nodes; some to operate as flow control (loops, selectors, sequences, etc.), and some to perform actions (move_to, set_speed, etc.) The goal here was to have each character operate according to their own needs, navigating around the world, gathering items, to make the city look living and active for the player.

The behaviors were developed in distinct pieces, and later combined into the final behavior:

Basic behaviors 

  • Inside the Terasology/Behaviors repository, a few behavior trees were already created. The first step was to make sample characters using these basic behaviors:
    • ‘scaredCritter’ - The character runs away when they see the player
    • ‘hostileCritter’ - The character attacks when they see the player
    • ‘friendlyCritter’ - The character follows the player around
    • ‘stray’ - The character randomly moves around in their immediate area
The friendly gooey and the scared gooey
  • With these characters a new spawning system was devised. Each city building would spawn characters over time, with an eventual max capacity.

Time-Based Behaviors 

  • A common aspect of a city is that it becomes quieter when nighttime approaches. None of the currently available behaviors allowed to detect world time, so I had to create my own!
  • Now, the four previously available characters would return to their spawn buildings at night. In addition, a new nocturnal character was added, which would start moving with ‘stray’ at night.
The nocturnal gooey, cruising around at night

Need-Based Behaviors 

  • Each of the characters possess four needs, whose values decrease linearly over time:
    • Hunger - restored by visiting the nearest marketplace building
    • Thirst - restored by visiting the nearest well
    • Social - restored by visiting the nearest citizen
    • Rest - restored by visiting their home and resting in the centre
  • At this point, the city now naturally looks more like a city, with each character naturally acting to fulfill their own needs.
A citizen gathering water at the nearest well

Faction-Based Behaviors 

  • The final piece of all the behaviors. Each citizen is given a faction alignment on spawn, either good, neutral, or bad. When a good & bad gooey meet each other, they will run and attack each other with the ‘hostile’ behavior.

A ‘good’ citizen charging a ‘bad’ citizen
  • These four elements are all combined into the final citizen AI, in order of priority. Each character first checks for enemies nearby, and attack if any is found. Otherwise, the character checks if any needs must be fulfilled, then they will fulfill those needs. Then, they check if it’s nighttime, and if so, return home. If all these checks pass, the character will simply stray on the spot. With many characters running these behaviors, the city looks living & dynamic.

Player Needs

  • In the same way that the individual characters have needs, the player has needs that they must fulfill too, by interacting with the world and the characters in it. Two player needs were added; hunger and thirst:
  • Hunger - Right now, this need is satisfied by eating the meat from deer outside the city. The player is provided with a weapon, and meat is collected upon the deer’s death.
A deer outside the city

  • Thirst - A water cup item has been added, which can be collected by interacting with the wells that spawn around the city; much like the citizens do.
A well that spawns inside the city

Bug Fixes

  • In performing a variety of tasks in this project, a few bugs have been uncovered and/or solved in already existing modules. These bugs include, but are not limited to:

Character Stuttering

  • This was one of the major issues found & investigated in multiple places in the project. At the very beginning of the project, a problem was found with the ‘stray’ behavior that led to very unnatural movement. Every time that a character would “choose” a new spot to travel to, every other character would choose a new spot in synchronization with the first one, leading to a situation as seen below:
  • Later on in the project, I investigated a variety of issues that occur when a character lagged, the results of which were posted in this issue. In summary, when the frame rate of the game dropped, problems with physics hitboxes & server character prediction caused a collection of very noticeable errors.
A citizen floating up into the air, for.. some… reason...

Dynamic Cities Building Placement

  • Buildings are generated in cities in two main ways. Using a code-based building generator, as most buildings were spawned, or using a predefined building template. The latter of these two resulted in very strange placement results, such as buildings in the sky or in the ground in seemingly random order. The cause of this issue was determined & fixed almost halfway into the project; a very major fix visually.
Building spawning before & after the fix
  • In fixing this first issue, another issue was discovered. When buildings are placed, they aren’t placed directly, but rather placed inside of a buffer. This buffer holds the blocks until a block placing cycle is run, to prevent excessive lag. While the game was paused, blocks were placed into the buffer. As soon as the game unpaused, the buffer would rapidly unload, causing a lot of lag. Like the previous issue, the cause of this was determined & fixed.

Pathfinding

  • One major point of the AI characters task was to integrate pathfinding; so a character could move across a long distance without getting lost. This turned out to be much more difficult than anticipated, due to a series of issues with the existing pathfinding system that occured when integrating it with behaviors.
    • The provided behaviors for pathfinding inside Terasology/Behaviors depended on an old version of pathfinding, so some updates were required to make them compatible again.
    • The ‘Path’ object vital to pathfinding could not be saved properly to a character, due to problems with how the class was related to the ‘ArrayList’ class. This also had to be adjusted.
    • For the behaviors here, pathfinding that could follow a moving target was required, which means the pathfinding must be able to be interrupted in the middle. The existing nodes did not allow for that, so a new set of nodes had to be made to accommodate.
    • Around the end of the project, serialization changes were made to the engine. When these changes were merged, more saving failures were noted with ‘Path’, due to a circular reference within the ‘WalkableBlock’ object used in a path. This problem was determined and fixed.
    • Finally, when integrating pathfinding into Metal Renegades, the navigation graph seems to fail. No paths are detected here, despite using the same nodes as a test character which operates perfectly.
  • As a result of all these issues, pathfinding is still non-functional at the end up the project, and has sucked up many hours in fixes. However, major strides have been made towards seeing it work, and the end is in sight!

A deer navigating around a corner to follow the player

So, what now?

Overall, I consider the project a success. In the main tasks, all of them were completed to an acceptable extent, with only a few spots remaining to finish up. We now have a ‘living’ city & world to build the core gameplay elements of Metal Renegades upon, which was the core goal of the proposal to begin with.

There are still a large number of unreached stretch tasks in the proposal. These tasks are very broad, so I plan to turn these into issues on the repository and/or turn them into bite-sized tasks for GCI students to take on. As for Metal Renegades itself, all the people involved now need to determine the future creative/gameplay direction for the game, as much of the technical backbone has been laid down.

I am very thankful for the mentors of the Terasology Foundation, who made this GSOC program a great experience for me. I’ve learned more about the programming trade in this program than in any other time before, and it has given me great insight to what professional programming really is like. The skills and lessons I’ve learned here I will remember and use for a long time to come. Thank you for this experience, and I hope to do great things with you all in the future!

Pull Requests & Issues

Pull requests in italics were not merged in GSOC

In Terasology/MetalRenegades

In other repositories

Comments

Post a Comment

Popular posts from this blog

Week 7 - Simplying Needs & Saving a Path

Simpler Needs Last week, the need-based behaviors pull request was created. This quickly grew into the largest pull request of the project, with almost 1500 additional lines. This became very hard to manage & review (sorry mentors), so I had to shorten it down/generally make the code look better. This was accomplished in two different ways: For all needs, there was a different target action & fulfillment action for each. I changed the code to merge these common sections together into common target selection & need fulfillment actions; greatly reducing the complexity and size of the pull request. The need based pull request was technically in two parts; the addition of new characters, and the addition of the need-based behaviors. I made a second pull request and separated these two pieces to be reviewed in two different spots. This cut about 500 lines from the pull request alone. With these two changes, the need-based behaviors pull request is finally ready for rev
Read more

GSOC 2020 Final Report

Image
Summary At the end of 12 weeks of development, my GSOC 2020 project Metal Renegades: Refining Gameplay is finally complete. Over the course of this summer, over 40 pull requests have been made against 13 different modules in Terasology. These merged pull requests together contain more than 5000 line changes. The original goal of this project was to improve the gameplay of the Metal Renegades module based on top of the technical backbone work done last year. This goal was achieved over the summer by adding new gameplay features to the module, refining already existing features, and fixing bugs that negatively impact the core experience. Major Project Achievements City Water Wells Last year, thirst was added to the module. If the player doesn't keep their thirst bar above zero, they will slowly lose health and eventually die. This thirst was previously fulfilled by using wells inside the city, which would in
Read more