Island Defenders

 Author: Yashwant Patel Problem: For our water elementals (small, medium, large and boss) they all had one model. Wasn't really a model, but particle. This was fine in the prototyping phase, but for the final version of the game it would make the game feel and look bland. For players it wouldn't feel satisfying to look at the same model for different enemies and having an enemy that doesn't have animations doesn't feel great either.  The change that would address all these problems would be to add models for each of the elementals, but where to find them?   Solution: We scoured different 3d model sites (including UE marketplace) for free models, but this didn't work out. Then I came across a way to rip models from WoW and import them into the engine. This seemed like a great idea and the models worked pretty well with animations and our custom materials, but as the professor pointed out this would violate Blizzard's terms of usage.  So we finally decide to use t...

 Implementing A Flyweight System in Blueprints The Problem: How to Properly Implement? The first task was to figure out what types of tools were at my disposal to make a flyweight system in Unreal using blueprints. I was very lost when starting out, so I started with how I would make such a pattern in C++. This would include making a custom static structure that would be shared between all instances of the tower class. Furthermore, at each child, I could derive a custom flyweight object for each type. First, I looked into whether Blueprints supported static variables and unfortunately, I didn't find a satisfying answer there.  My next idea was to find a blueprint that would persist throughout the entire level and simply jam all those tower values in there. This definitely wasn't an "elegant" solution, and it had additional potential problems as well. Each tower would need to be added to this central blueprint and custom functions to retrieve their specific data would ...

 Author: Christopher Solomon     One of the systems that I implemented this past week is the spawn system. Prior to its implementation, nothing would happen if the player ran out of HP. I worked to make sure that the player would die if they lost their HP and then be respawned a few seconds later. There were a few issues I had to solve to get the system working however. One such thing was that the player could enter build mode after they died during the respawning period. I solved this problem by disabling input from the player controller after death and restored input after they respawned. Another problem that occurred was that sometimes the player would not respawn if their respawn point was colliding with another object. I fixed this by making sure that the player's position will be shifted but they will always respawn in such cases.

 By Matthew Steinhardt Approaching the Task (The Problem) The repair tower was a unique structure in that it was the first implementation of a tower that specifically targeted other towers nearby. It also needed to interface with the health system, assessing (efficiently) which towers needed healing and dispensing it on a regularly timed interval. In addition, per our design document, the tower syphons its own  health into hurt towers around it. This effectively makes the tower a "temporary" one that simply restores nearby towers for cheaper than what it would cost to remake them. The Implementation (The Solution) With the requirements in mind, I set out to create the tower. It was nice having a base class with much of the logic already taken care of. I set up a timer that executed a "repair" function every X seconds where X is the interval in between repair ticks. The repair function loops through a list of nearby towers and checks to see if the tower needs repairi...

 Author: Yashwant Patel Problem: For the current week one of our focuses was implementing more towers. One of the towers we designed shoots a rocket along the closest path that it has been placed. As with anything there are multiple ways of implementing the rocket movement, but two of the main ways that were thought of right away are navmesh and spline movement. Navmesh is usually the go to solution for any AI like units, but as discussed before this is a bit overkill for our needs, so why not just use the splines already in place to move our rocket along it? The spline movement component currently only moves an Actor in the forward direction whereas the rocket would need to move in the opposite direction, so that will need to be implemented. Also, the movement of the Actor is controlled via a distance variable that is increment every frame depending on the speed variable and delta time, but it doesn't directly correlate with the length of the spline, so how would we calculate at w...

 Author: Matthew Steinhardt The Problem It was about time we started looking into some special effects for our towers. Since the only functioning one at the time of tackling this was the flamethrower, I looked into make a neat fire effect. Unfortunately, I have zero experience making special effects in Unreal Engine, so I took to Google to search for some tutorials. There were... a lot! Trying to wade through them all to find quality information was daunting. Furthermore, a lot of information appeared to be locked behind paywalls.  I eventually landed on a particularly promising tutorial that used Unreal's new Niagara Fluids System. However, this system is still in a beta stage, which makes it a little risky to use for our project. Regardless, I thought it would be a good learning experience if nothing else. The Solution I ended up going through the tutorial a few times as the effect didn't come out nearly as well as it looked in the tutorial. However, I have finally made a re...

Author: Christopher Solomon                   This past week I was tasked with creating the Large Water Elemental, one of the enemies the player faces in our game. For the most part, implementing it was quite simple. After all, it has many similarities with the other elementals that we have already implemented within the game. The main feature of the large elemental that sets it apart from the others is its ability to shoot projectiles at players who come near. It was while I was creating the blueprint for this projectile that I came across my problem: the projectile would not move at all!                 When this problem occurred, I was quite confused since I had implemented a projectile movement component in the blueprint and inputted the correct settings. My first thought was that perhaps the homing system that was used was ...

 Author: Patrick Kelly     The problem I ran into recently was changing a user interface element from a hard-coded single-use blueprint widget into a multiple-use blueprint widget. This was due to my observation of other games struggling to provide simple instructions or tool tips to the user to guide them through the game. We had a widget that prompted the user to press a key to do an action, but in order to re-use this element, we would have had to duplicate and re-code this widget for other actions.     The solution to this problem was creating a data table that stored the action name and prompts for each widget prompt. With this, I could use this data table to initialize the prompt widget that would only last from its instantiation to the keypress that would remove it. From this, the widget prompt could now be changed in one widget blueprint and changed for each prompt that was creating differing instances. E to interact would be called differently that R to...

 Author: Yashwant Patel Problem: Island Defenders is a tower defense game and like many tower defense game it can get dry if there is nothing unique about the game. Our approach to fix this issue was to not only let the player build towers, but also let the player have a controlled unit that they can move around and shoot enemies with. This would hopefully increase player engagement and make the game less dry. A major part of giving the player control of a unit is movement and our movement system was very barebones. The player could move and jump, but there was a problem with the movement that would cause the player to twitch. Also, the player didn't have any air control, so they wouldn't be able to maneuver in the air. While the twitching doesn't directly affect the gameplay or the player, it is jarring and annoying to look at. The lack of air control made the floaty jump feel awkward.  As you can see the player twitches when moving and trying to move left or right. This a...