"Tailwind Tropics is a stylized, 3D, round-based team party game where you collect, construct and combat each other in order to claim the title of “Island Masters”! Scour the tropical islands in search of materials to use in construction of your team's battleship and then duke it out on the open seas! You battle for the sake of battle and play against friends, enemies and frenemies. Tailwind tropics is a true showcase of the long standing feud between the Puckish Pandas and Raccoon Rascals and their crazy competitions." This game was developed over 10 weeks as part of my studies at Stockholm University and served as an introduction to multiplayer game development. Through this project, I significantly expanded my knowledge of Unreal Engine 5 while gaining a deeper understanding of the complexities involved in multiplayer implementation. I became familiar with key concepts such as NetMode, Replication, RPCs, Steam integration, and more, which provided valuable insights into the challenges and intricacies of developing multiplayer experiences. Software Used:

This is a project I've worked on over the summer with two other students to learn and get better at Unreal and C++ in general. It's a rail-shooter game where you play as a crow, hence the fitting title. The team working on the project consisted of one Game designer and two programmers, me included. Software Used:

I’m going to start off with splines, they are probably the main component of our game and is the part that dictates the movement of not only the player but the enemies as well. The Player For the player it felt like a given to have it constrained to a spline considering we intended it to follow a specified path in the level. Although attaching the player to spline directly wouldn’t allow much movement, we instead made a “root actor” that acted like a middle man. This root allowed the “2D plane” with the movement constraints to follow the spline path instead and enabled the player to move inside those constraints. All we had to do now was attach a camera with a spring arm for smooth camera-movement to the root and ta-da, we had a moving player! The Enemies When it came to the enemies we decided to have them attached to a spline for mainly one reason, customizability. It meant we could place it however we wanted it to and have greater overall control over the player experience. Because I already had the spline movement implemented in the player's spline I decided to have the enemies make use of the same spline just with an enum switch on the character type to separate some functionalities. As an afterthought I think it would’ve been wiser to split up the actor into two different ones, just to keep it simple in the end. I already had an interface for the speed part of the spline, so I could just attach an enemy to the spline directly and let it fly along. Seems simple, but what about groups of enemies? It quickly became apparent that it would become a real headache to put together enemy groups with separate splines, and game performance could really become an issue in the end as well. The goal then became to allow the spline to carry groups of enemies. I decided to make use of the constructionScript of the spline to allow a visual representation of the groups while you worked on them. I made editable variables such as “GroupSize” and “DistanceBetweenEnemies” which in turn spawned in basic shapes to represent the transforms at which the actual enemies would spawn at during play. These shapes would spawn in a square-plane shape and the Game designer could then freely move them around in the editor to change the shape of the group. I later also added the functionality of saving/loading the enemy positions to make it easier to edit positions and later revert, or just as a failsafe. General In the end I ended up with a great deal of customizability on my spline. Not only those variables I mentioned before but I also allowed the Game designer to override the data of the entity being attached for it to allow even more flexibility in the future. Here’s the end result of all the editable properties with a bunch of metadata to make it easier to use:

What’s the goal of enemies in our game? They act like a moving target. Give points when shot at. Can hurt the player. All seems quite simple enough, the moving part is mainly done using the spline discussed before and to give them more lifelike behavior I’ve also added a bit of randomness to the animations as well allowing the enemies to face the player at all times. The enemies give points when shot at as well as points upon dying, I’ll get more in depth how that works later on during “Game Framework” but from the enemy’s perspective it’s just sending away the points via an event dispatcher. It does give me an opportunity to show the class hierarchy of enemies which is quite simple but it allows me to very easily add new enemies as well as change the behaviour of things without having to do so over multiple classes. Here’s a very simplified overview of the hierarchy where I’ve not included things such as structs, interfaces and functions. It’s just to give an idea of my overall structure of things: When it came to hurting the player I made use of Unreals built in tool apply/take damage, this came in handy for triggering subsequent events. I created a weapon class that could be used by both the player and the enemies, once again to allow greater flexibility later down the road if we want to swap things around and change out weapons more easily. Each weapon held a struct with a bunch of variables that you could change, such as DamagePerShot, FireRate, ProjectileSpeed and what type of projectile to use. The projectiles was a different class I created to also allow flexibility. This class mainly contained information about the look of the projectile and impact but also held the logic for impacting with the player, enemies and terrain. Both of these classes were made as a base class that I could inherit from to create more weapons and projectiles later on.

When I started creating the widgets I found it quite simple to just drag & drop and create events for each button. Once I started making larger menus with settings and so on I realised that it easily gets quite complex. And once the menus were in place I realised that we need controller support, also not an easy task when the widget isn’t as simple as one vertical box. I wanted custom functionality for my buttons to allow animations and focus events, so I made my own button widget. I exposed variables such as the text and text colour to make the buttons slightly customizable from the widget making use of them. I also made animations for it when hovered/unhovered as well as when focused and on lost focus. A custom On Clicked event dispatcher allowed me to know what button was pressed which simplified the use of the widget when implementing the click functionalities. It made it work just like Unreals "default" button, which was great! To allow controller support I override “OnFocusRecieved” on my button to allow an event dispatcher informing the menu which button is currently being focused. In the menu I then override the “OnKeyDown” to allow desired button inputs to run the “HandleButtonClick” with the CurrentlyFocusedButton. This approach allows me to add controller support without really interfering with the normal mouse support at all, which is a great plus. ​ All this goes mainly for my main menu, pause menu as well as the summary screen which all contain quite a lot of buttons and functionality. How I grab all of the data for my widgets, such as “Enemies Killed” will be explained below in “Game Framework”. Main Menu Pause Menu

This project taught me a lot about game framework and I feel like it really helped me get a good understanding of the whole game structure as a result. I’ll start off by explaining my Game Instance class which I mainly used to handle the save/load functionality as well as store a few variables. I found this was a great place to house my logic for SaveGame as it’s a persistent class and is globally accessible. As for the save functionality, our game really didn’t need different save slots, it just needed to store the highest score and rank earned for each level. I made a very simple SaveGame class to store my data, and it looks like this: And then to save and load the data from the Game Instance with just a function call I made these functions: This allowed me to easily grab data as well as save whenever needed. With the SaveGame class I made I could also very easily add more variables to save in future if needed. As for the Game State class I decided to keep all of my stats in this class, the reason for it is mainly because it’s not persistent between levels and variables such as number of enemies changes depending on level. The stats I kept track off were: TotalNumberOfEnemies NumberOfEnemiesKilled TotalScore MaximumScore PercentageOfScoreEarned NumberOfTimesHit TotalDeductedScore StarRank In BeginPlay for each enemy they called an event in the Game State to register themself, this event took the points they were worth and added it together to get the MaximumScore variable setup and ready. The registration also binded the events for OnEnemyKilled and OnEnemyHit to use during runtime to add score to the TotalScore. I chose this approach instead of “FindAllActorsOfClass()” partly because of performance reasons but also because it allowed me to have better control over the gameflow. With my approach I can spawn in more enemies during runtime and have them count toward the stats instead of relying on everything spawning in at start. The player did the same and registered itself in the Game State at beginPlay to bind the event OnPLayerHit, this allowed me to keep track of variables such as TotalDeductedScore and NumberOfTimesHit. To display these stats during runtime via things like the score tracker or the game summary screen the Game State class made calls to events in the Player HUD class which handled the interaction with the separate Widget elements. This decision was mainly made to decouple the code a bit more.