GSOC 2018 - Tower Defence

jellysnake

New Member
Contributor
Architecture
GUI
#1
I will be posting all relevant updates to this thread as the program goes on. This will potentially also include things that are mirrored to other places.

Summary of project:
Terasology has a lot of potential that goes beyond just being a sandbox voxel game. This project aims to highlight this by creating a brand new gameplay mode, Tower Defence.
Tower defense is a classic game genre and one that can highlight the modding and development potential of Terasology. It will aim to use features of Terasology's voxel engine such as block placement to provide a compelling and interesting game experience.
Student:
jellysnake (Quinn Roberts)
Mentors:
Oniatus, iojw, skaldarnar, vampcat, niksoc
GitHub:
http://github.com/Terasology/GooeyDefence
Slack:
#towerdefence
Blog:
N/A at present. Updates posted into this thread.
 

jellysnake

New Member
Contributor
Architecture
GUI
#2
Week one update
Due to university exams, I began working in the Community Bonding Period. The intention is to then to pause work whilst my exams are occurring. As such, this first update will most likely be larger than others, as it's going to cover multiple weeks.

Features
At present, the world generation is finished, with only minor aesthetic tweaks expected to occur. It generates a halfcircle dome and floor, placing a random distribution of blocks onto the floor, avoiding the entrances.
These entrances themselves are located on the rim of the dome, and are highlighted via a clear space around them and through a different colour block used for the dome at that point.


The next major item is the pathfinding. The main world system calculates paths from each of the entrances, to the shrine. A separate system displays these paths via a translucent block, placed one block higher than the path itself. In future this will be changed to use a more subtle and nicer method of showing the path, once the in game map has been created. The calculated path is also updated every time a block is placed or destroyed.

The next and final major item is to spawn in enemies and move them along the path. At present, the enemy model is a direct clone of the gooey from GooeysQuests. This will be replaced when additional enemies are introduced later in development. The enemies also need to be better integrated into the entire system and ideally display better visuals, for instance rotation to follow the path and animations.

Outstanding issues
One outstanding issue is how to deal with enemies partially along the path when the path changes. Currently there are two proposed options, backtrack the enemy until it reaches a point that is in both the old path and the new path, then continue from there along the new path. The second option is to recalculate a new path for each stranded gooey from their location to the goal.
Another issue is that the module being used for pathfinding is not yet in the official module lineup. This means it will either need to be added, or an alternative module used. Ideally the module will be added, but I will need to discuss that with Kaen (author of the Flexible Pathfinding module)


Future work
The listed work for next week is to begin work on the towers, once this is done I should technically have a complete skeleton and thus the module barely at a playable stage
 

jellysnake

New Member
Contributor
Architecture
GUI
#3
Week Two Update
This week I started to work on the Towers themselves. Firstly the towers need to build correctly, and then they need to fire at enemies correctly. This week focused on the former as well as designing some specifics of the towers functionality.
Tower Building
Towers are a loose collection of Tower Blocks. All tower blocks that touch one another are considered to be part of single tower. In order to upgrade or alter a tower blocks are removed and replaced with different or superior versions. Individual block settings such as how targets are selected are set per block in the tower.
There are four main types of bocks, Cores, Emitters, Effects and Plains.
The Core blocks provide power for the Emitters and Effects. The power from these blocks directly stacks. If Tier One Cores provide 50 Power, then two will provide 100 power.
The Emitters are the blocks that shoot at the enemies. They can attack enemies in a number of different ways; single target; splash damage around a target; passive AOE around the tower. An Emitter by itself will do no damage, comparable to shooting blanks, the damage and other effects comes from the Effect Blocks. Stacking multiple Emitters will result in each subsequent Emitter dealing slightly reduced damage.
Effects are the blocks that provide effects to the enemies, as the name suggests. These blocks can deal damage, apply status effects or a mixture of both. They also stack with other Effects albeit with reduced effectiveness.The result of Effect blocks are subject to two multipliers. A Damage multiplier and an Status multiplier. The former acts upon the damage dealt by the Effect, if any, and is calculated by the Emitters. The latter acts upon the status effects applied by the Effect, again if any and is calculated by the number of competing effect blocks. This means that mixing Effect blocks of different types is less effective than only using one type. For instance a tower with Ice and Poison will be less effective than a tower with Ice and an tower with Poison.
Each block can have individual settings, such as target selection (First target, Weakest target, etc) for emitters however these settings do not directly improve the block in question. Upgrades are implemented by wholly replacing the block with a superior version.

Towers are created by simply combining blocks together. Any Tower Blocks that are touching are deemed to be part of the same tower.
Outstanding Issues
One particular issue is dealing with saves. Currently this is done by searching for every tower block and manually rebuilding towers from that. However it would be ideal to simply use the data stored in the Tower Entities to avoid having to rebuild all these towers. This is also an issue in other areas, for instance enemies in transit also need to be dealt with. The intended solution was to use a central entity and save data onto it's component however this is proving to be inconsistent as the entity is not always available when the game is saved.
Future Work
The next step is to actually implement the above design into the tower, using a set of very simple blocks. The implementation should also allow for more types to be added in the future with minimal issues.
 

jellysnake

New Member
Contributor
Architecture
GUI
#4
Week update
It's been a while since the last update, so this will be a fairly big one. The end of this week marks the start of the content intensive period. After this the game will be at a substantially more playable state.

Enemy Pathing Tweaks
I added two main features to the enemy pathfinding systems, repathing and vertical movement.
As the player is placing and removing blocks, the path from entrance to goal will change. This is fine for enemies that are spawned after these changes are made, they just use the new path. The issue comes from enemies that are partway there when it changes. They have two options: use the new path, or follow a custom path for them.
If the enemies are located on the new path then they automatically use that. However, if they are not able to they will make their own path. If a block is placed/removed that causes their custom path to change then they perform the whole check again, attempting to use the main path and if not, using a custom path.

The second major change is that enemies are no longer limited to horizontal movement. They are capable of climbing over one block high obstacles. In order for an enemy to go around a wall, that wall will now need to be two blocks high. This applies to both climbing up as well as down. If the enemy is on a two block high wall, they will need to find a 1 bock drop in order to be able to get down.
This means that the player will have to be more vigilant in building their field. It also allows for more interesting designs, as the paths the gooeys can take can be shaped to go upwards.
Tower Structure
The second major bit of work that has happened is the implementation of all the Targeter blocks.
This may not seem like a very large element, however the tower systems behind the scene were fully replaced in order to accomadate new funcitonality and to make implementing towers as easy as possible.
Firstly, from a player perspective, targeters replace the emmiters defined in the prior post and effectors replace the effects. This is purely a name change however, they still perform the same function.
Second, targeters now shoot independently of each other. Each targeter also applies all effectors on the tower at that moment.

Behind the scenes quite a few things have changed. Targeters now have a multiplier that is used for moderating the strength of effectors. This is used to make targeters that effect a large amount of enemies do so weaker than a single target variant. This multiplier is fixed per component, with individual instances of unable to change it.
Targeters also have different attack modes now, they are: First, which attacks the enemy closest to the goal; Random, which attacks a random enemy; Weak, which attacks the weakest enemy; and Strong which attacks the most powerful. The targeter will continue attacking the same target until it is no longer able to, because it has died or left range.

Effectors now have multiple options for how they are applied as well as how long they last. They can opt to be applied Per Shot, where the effector will be applied every single time the targeter shoots; or Continuous, where the effector is only applied when a target is newly attacked. The other option is for how long the effect lasts. Instant, for effects that have no duration; Lasting, for effects that last the whole time the enemy is targeted; and Permanent, for effects that have a duration controlled by the effector.

Targeter Blocks
Here is the list of all the Targeter blocks that have been implemented, as well as a description of them:
Single
This one selects a single target within range
Chain
This targeter picks a single enemy within range and then chains from that to enemy closest to it. It repeats this a number of time, stopping when there are no more enemies within the chain range, or when the maximum number of enemies has been reached.
Aoe
Simply targets all enemies within range.
Splash
Like the Single, this chooses a single enemy, however it targets all enemies in a small aoe around that base enemy.
Sniper
This one has an extremely large range, and picks a single target within that range. However it also has a minimum distance, meaning it won't pick enemies that are too close to the tower.
Missile
A combination between the Sniper and the Splash. It targets all enemies in a small aoe of a distant target.

Future Work
The next work is to implement all the effectors planned. Following this two additional enemy types as well as the wallbreaker unit will be implemented. Then work will begin on the shop system and implementing smooth upgrading for the blocks.​
 

jellysnake

New Member
Contributor
Architecture
GUI
#5
Progress Update
There's been quite a bit of progress since the last update. More content in the form of Effectors & enemy types has been added, and new systems like upgrading adding more depth to the tower building. Additionally the introduction of more UI screens is making the gameplay more user friendly by reducing the number of commands and strange actions needed in order to use the template.
Effectors
I have implemented 5&1/2 new effector types. The system is currently using a custom effect system, although I will investigate the potential of reusing Alteration Effects in order to promote module reuse.
Damage
Simply deals an amount of damage each attack.
Poison
Deals an initial damage, and then continuous damage for the duration of the effect.
Fire
Ignites the target enemy. Burning enemies will extinguish after a few sections, however whilst they are burning they have a chance to ignite nearby enemies. This can cause the fire to spread over a large group of enemies from a single starting point.
Deals damage over time to all burning enemies.
Stun
Briefly halts an enemy. This causes the enemy to stop moving for the duration of the stun. Enemies are not always stunned, and have a chance to ignore it.
Slow
Slows the enemy by a given percent. This is useful for increasing the time available for the tower to kill the enemy. More reliable than the stun.
Visual
Highlights a targeted enemy by changing it's size. This effector only serves as a testing and will be removed before the project is completed.

Enemy Types
I have added another two enemy types. This gives three enemy types altogether, Fast, Standard and Strong. As the name implies, the fast enemies have increased speed but reduced health. The standard have a balance between health and speed, and the strong enemies have more health but less speed.
I will also implement the Path Destroyer enemy, which will create new paths for the enemies to utilise if the player blocks them all off.

Upgrading
Another important feature is the ability to improve the blocks in a tower. This is done via an upgrading system, which has been applied to all of the Targeters & Effectors, as well as the Core block. At the moment all upgrades have no cost implemented, and there is a simple linear 5 stage increase for each attribute listed. Here are all the upgrades possible at present
  • Targeter
    • Aoe
      • Range
      • Attack Speed
    • Chain
      • Range
      • Attack Speed
      • Chain Amount & Range
    • Missile
      • Range
      • Attack Speed
      • Splash Range
    • Single
      • Range
      • Attack Speed
    • Sniper
      • Range
      • Attack Speed
    • Splash
      • Range
      • Attack Speed
      • Splash Range
  • Effectors
    • Damage
      • Damage
    • Fire
      • Damage
      • Fire Duration
    • Ice
      • Slow Multiplier
    • Poison
      • Damage
      • Poison Damage
      • Poison Duration
    • Stun
      • Stun Duration
    • Visual
      • N/A
  • Core
    • Power
Any future content added will also be upgradable via this same system wherever possible. Additionally other modules such as Gookeeper feature the ability to upgrade items/blocks and as such this will be split out into it's own module possibly along with a more generic UI widget for displaying of components/upgrades.

Tower UI Screen
In order to apply the upgrades from the prior sections, and to see information about the tower, a UI screen was added. This screen contains a list of all the blocks in the tower, split between Effector, Targeter and Core. Upon selecting a block, information about that tower will be shown. At present this includes the name and description taken from the Display Name Component, the stats of the component to upgrade, and the upgrades available. For Targeters there is also an option to set the selection method used.
The screen also includes information about the tower in general. At present this only includes power produced and power used, although there are plans to also include stats of how many enemies this tower has killed.

Activate UI Screen
In order to ensure that the world is loaded before being activated and systems like Pathfinding run, a screen is shown to the player. When the screen is closed, the world is activated and begins. The screen also contains information for the player and has the potential to include settings
Shop UI Screen
In order to provide a natural way to obtain blocks without the use of cheat commands, a shop screen and system has been implemented.
This shop screen is added into the left half of the inventory screen, with the existing grid moved to the right. It provides a list of all purchasable blocks and items. When a ware is chosen, more information is shown with the option to purchase it. If the player has enough money in their wallet then the cost will be deducted and the item given to the player.
Next Goals
The next most immediate goal is to touch up the added UI screens, this includes things like displaying the players money on the shop screen. This is likely to be an ongoing process as more required fixes and tweaks are discovered through playing the game.
The other major goal is to begin to add informative visuals to other sections of the content. For instance, utilising the particle system to indicate when an enemy is burned, adding visual indications of a tower's range and when it is attacking.
 

jellysnake

New Member
Contributor
Architecture
GUI
#6
Progress update
With the close of this phase of work, the game mode is technically functional. However it lacks significant polish and balance. Additionally documentation for both players & developers needs to be finished.
Visual facelift
One of the major occurrences was the addition of particles to display useful information to the player. This includes a few components
The range indicator
In order help with tower placement, a sphere is now rendered when a targeter is selected.
Attack indicator
When a tower attacks, either a radial wave or a single shot is displayed to indicate the attack, depending on how the tower attacks.
Effect particles
The majority of effects have some sort of duration. To show this, each effector has a particle effect which it applies to the enemy. These vary from snowflakes for the ice effect, to embers & smoke for the fire effect.

Hud UI Elements
Another major addition is the hud ui elements. These aim to provide useful information to the player whilst they are actively playing the game.
Wave Indicator
This element adds a summary of which enemies will be spawned in the next wave. When a wave is underway it also shows the remaining time for that wave
Health bar
Mostly self explanatory, this converts the already existing health bar to display the health bar of the shrine.
Money amount
The player funds are displayed in the top right corner of the screen.
Waves
One other major element added is the spawning of enemies in waves. Waves can be configured through a prefab component. They are specified per entrance, via two lists of spawn delays and prefabs.
Entrance spawn lists are then grouped into waves, with a specified range they can appear at. By default this range has no minimum nor maximum, but either may be specified.
Waves are viewed either through the hud element, or the control screen. This is opened by interacting with the shrine via E. It also allows the player to start a wave, whereupon the prefabs will be spawned according to the wave information.
Game over handling
Finally, the case where enough enemies reach the shrine and the game is ended now has been handled.
The death screen has been altered to both display once the shrine health reaches zero, and to allow for resetting the game.
The respawn button and death info has been removed and replaced with a reset button and in future, stats on the game.
The reset button calls on the field to be cleared and the systems reset. This allows for the game to be replayed without having to create a new game.
Future work
Like mentioned in the start, this point marks the production of a technically complete product. However there are still a few edges to be smoothed off. Namely the game still needs to be balanced, and a few aesthetic & QoL fixes made. These include things like displaying the player money on the shop screen.
Concurrently to those, documentation for both players and developers needs to be produced. Ideally the player documentation will also be available as an in game resource.