UFO
Multiplayer Tank Game
MOVEMENT
The UFO is able to move around and shoot. The bullets know who shot it and who it hit. Upon hitting something, the bullets get destroyed. The scripts for movement and data are two different scripts, so that all UFOs move the same way but the designer can set things like shot speed, movement speed, and turn speed.
AI
The AI use the exact same pawn as the player, but are controlled by an AI controller instead of a player controller. There are 4 different AI personalities, Brave, Scared, Watcher, and Patrol. The Brave always chases and fights the player. The Scared always runs away. The Watcher waits for the player, chases them, and flees when their health is low. The Patrol loops through patrol points until it finds the player. All AI use obstacle avoidance, hearing, and sight to try and find the player.
RANDOMIZED LEVEL AND POWER UPS
The level has 3 random options. Map of the day generates a random map seed based on the year, month, and day to ensure each day has a new seed. Random chooses a completely random seed. Custom allows you to type in a custom 4 number seed, so that you can replay a map you liked. The level is built from a group of tiles that can be arranged in different ways to form the maps. Each tile contains what AI, power ups, and Player Spawns will be there and their positions. The different power ups include shot speed up, hp up, and speed up. Different weapon power ups include the sinwave shell, the RC shell, and the normal shell. The sinwave zigzags back and forth when shot. The RC gives the player temporary control of the shell.
MULTIPLAYER
Each player's score, lives, and hp are displayed separately. you can set the controls to be WASD or Arrow Keys. When a player dies, they respawn after a certain amount of time. If they run out of lives, they get a game over. When both player's have a game over, the game can be reset. The high score is saved to player preferences and displayed on the main menu.
UFO
UFO
UATanks Milestone 1
UATanks Milestone 2
UATanks Milestone 3
UATanks Milestone 4
POST MORTEM
What Went Right:
I had planned for the game to use multiple different bullets from the start. This worked out really well because when everything was working I had a framework set up, so making new bullets didn't break how everything else worked. This made it really easy to just add a script and change some variables to pump out new bullets. This also worked for the player pawn as well. The use of a separate pawn, controller, and data made it really easy to reuse scripts. For one of my bullets, all I had to do was attach a tank motor, tank data, and shell data and add a couple extra lines of code to give me a bullet that the player can control. Lastly, the tiles having their own scene worked out really well. If I wanted to work on level design, I can work in the scene that just has the level without all of the other assets being in the way. This also means that if I had a team, one person can work on level design and one person can work on building other assets of the game at the same time.
What Went Wrong:
Time management was a huge issue this semester. I had 4 major projects running at the same time, along with C++ 2 assignments. This made it hard to put extra time into any project, because it would take away from another. Finding a minimum viable product for each project was a skill I rapidly developed because of this. I sacrificed areas that could have been more polished or included more artwork in my game to make sure that everything that needed to work worked and was ready by the time it was due. Another thing that went wrong was trying to meet specific requirements in the grading rubrics. I would look ahead to see what functionality I needed and do it, and then when I would record my video I would see that it was supposed to be done using a specific line of code that I didn't use. This happened for the AI personalities. I had set up a system using one script with multiple enums and variables that could be set up in different ways to create unique AI personalities in the editor, rather than one enum that switches it between 4 static personalities. One thing I had trouble with was the camera. The camera ran into issues when the player died, when the player used the RC bullet, when the player didn't exist on the menu, and so on. I had to program in a lot of empty if statement to stop the camera errors from doing something while the player was gone, once the player was back I had to make them switch parents to the player, but switch back to the GameManager when the player died, and then the same thing but with the player and their RC bullet.
Take Aways:
One thing I got from this was skill in setting scope and finding the minimal viable product. This was helpful while running multiple projects and making sure each one show off a specific level of quality without any of them falling behind. I got experience in setting up codes for one task and maximizing re-usability. I had rotate scripts used for setting player animations as well as pick-up animations, spawns that spawned both pick-ups, AI players, and players, and tank motors that were used for AI players, players, and RC bullets that the player controlled. Lastly, I got experience planning things out for future use. I set up the multiple control schemes and ability for two players to exist at once from the beginning, that it was just a matter of dragging another player into the scene once we needed to implement multiplayer. I also used this for my bullets, so whenever I needed something extra in my game I would just come up with a movement pattern and add it to a new bullet prefab and add it to the game.