Interface or Abstract Classes?

Author: Matthew Steinhardt

 The Problem

While designing the tower system for our game, it was immediately apparent that many of the towers would share similar functionality. This meant that if our code framework was not done correctly, it could lead to lots of duplicate code or an overly restrictive base that would not allow for flexible development later on. 
When looking at how our towers function, they can be broken down into two main groups: Offensive Towers and Utility Towers. Offensive towers have the unique functionality of finding enemy targets and attacking them in some way. However, the "attack" method could vary widely. Is it a direct "lock-on"? Is it projectile based? A wide cone-attack? Conversely, Utility towers are much broader in the sense that they don't need enemy targets to necessarily work. Furthermore, their functionality could include nearby towers or not. 

The Solution

The solution I came up with was to use a general abstract base class called "PlaceableTower" which all other towers (Offensive and Utility) would extend off of. In this class, I implemented some core logic that I thought all towers would need. For example, the logic to determine placement, show a preview while "building", and taking care of the cost/currency system linkage. For the most part, all of this logic is consistent across all towers. However, all of the functions are overridable, meaning a particularly custom tower could still change this base-level logic if needed. 

I considered making interfaces for Offensive towers and Utility towers, respectively. However, I decided against it due to the fact that there was still some functionality that all Offensive/Utility towers might share which would be better suited in another base class. For example, the logic for acquiring all potential targets for an Offensive tower is generally the same. As such, it would be easy to override it, like the Placeable tower, if needed. Otherwise, all offensive towers can simply share this logic. 

The final part to the tower system was to separate the actual attacking logic from the towers themselves and lean on our "weapons" system that was created for the player's gun(s). Simply put, a tower simply needs to know how to find a target and call the weapon's "attack" function. Hopefully, this will make it easier for us to iterate on different types of towers with different types of ways of attacking elementals. 

Comments

Post a Comment

Popular posts from this blog

UI Polish

Image
 Author: Yashwant Patel The main thing that our game was missing in the last week was polish on certain things. One of the largest thing that we were missing was replacing the placeholder with final UI assets. This would make the game feel more complete and the player would appreciate the game with a finished UI. Since I was working on UI I had an advantage, because I didn't have to go around searching for UI packs since finding assets that you exactly want can be hard. Instead I mostly made everything from scratch with the exception of some elements that I got from freepik.com  and modified them to what we needed. The main challenge I faced with the UI was getting everything how I liked. I didn't really use Unreal's tools for UI before in terms of properly structuring the hierarchy for UI elements and properly wrapping everything to have it behave how you want it to, so this took a day to get used to. Another thing that needed to be done was reprogram the UI since the old ...
Read more

AI Navigation Problems - Yashwant Patel

Image
Problem In Island Defenders we want our AI to go down a lane to reach the core. Ideally the AI should navigate through the lane in a way where they don't cut corners to try and optimize the path they take in order to reach the Island Core. The path finding algorithm is implemented in a way to have the AI reach the destination using the quickest path while keeping obstacles in mind. For most games this would make for good AI, since you want AI to take the most efficient path. In our case we want the AI to always be in the center of the lane even if that path is not the most optimal. This wouldn't affect the user's gameplay physically, but it would seem like an odd behavior to have AI cutting corners in a game like this. For example, if you have a racing game and the AI cuts through the middle of the map in order to go from one point to another it wouldn't make sense. Even though that is the most optimal path in terms of pathfinding it's not the correct path. This is ...
Read more

Round End Cutscene Implementation

Image
 Author: Yashwant Patel Problem: Before the very first round and in between each round the player has access to the upgrade system where they can spend the currency they earn to purchase upgrades. Currently the player has no idea about the upgrades since they aren't told about them. One thing that can help mitigate this problem is to have a "cutscene" at the end of each round that shows a ship arriving with supplies (upgrades). This would help mitigate the main problem and it also solves the mystery of where the upgrades are arriving from. The objective is clear, but how should it be executed? Could use Unreal's level sequencer to make an animation and then render it and play the video once the round ends. Another way would be to have a "dynamic cutscene". Sounds fancy, but what does this mean? Essentially it means that each round end cutscene would be unique. How can that be accomplished and why attempt it in the first place? The main problem with setting u...
Read more