Coming up with Ideas:
I wasn’t too sure what was expected of us in terms of how much effort we should allocate to editing scripts creating new core mechanics vs. level design, so I took a look at some of my classmates projects to try to get a general idea going. namely Kris and Lishan. I noticed that they took their projects in fairly different ways, Kris focusing more the technical aspect with the player clone idea, and Lishan with more focus on level design. I first played around with the public variables of the blaster prefab, editing whether it was fully automatic, semi-automatic, bullet spread, etc. Eventually I essentially had it operating as a revolver with 6 shots which led me to start thinking about a western styled game. I threw together a quick model in maya for a ‘space cowboy’ looking gun,
so that I could continue to use the prefabs provided if need be, as I wasn’t sure how changing the mesh and animations of the enemies would affect the general workflow of the scene that was already set up. At this point I was also considering changing it to be like a “Cop vs Criminal” theme. It’s a somewhat common trope in TV and movies for a cop to chase a mad criminal into the mirror maze of a carnival, and using the patrol path function I could’ve set up a map full of reflective surfaces, confusing the player as they tried to hunt down the enemy.
Ultimately, however, I noticed that the turret had a few more options compared to the drone, and decided to stay with a more stationary game, with an open map, so I leaned back towards the wild west theme. I found 2 nice low-poly asset packs to design the map, along with a small hat pack so I could slap a cowboy hat onto the turret to make it seem not so out-of-place thematically.
Process:
I honestly think I might’ve had a much easier time making this game from scratch, if only I was used to using Unity and C#. Reverse engineering the game flow manager, the enemy, the player, the HUD, and the weapons was far more painstaking than I’d originally thought, but it was certainly a very good learning experience.
I ran into a lot of trouble, especially when it came to referencing variables from other scripts, and writing variable values to other scripts. As I started to edit and add more functions and variables to the original scripts for the gameobjects, I found that my code fairly consistently conflicted with the original code. The two problems that had given me the largest headache were the ones that showed even when there was no inherit error in the scripts.
1. Reloading the main scene caused the weapon handle to move, pushing the pistol off screen.
Intended Position:
Reloaded Position:
Solution: It could be considered a shortcut, or a ‘band-aid’ solution but I realized that in the player’s weapon controller script, there was a few functions editing the position of the gun to simulate sway, recoil, etc. Seeing as the player cannot walk in my game, I just commented the function calls out of void Update() and it fixed the problem.
2. The HUD message signaling the start of the duel wouldn’t show up.
Solution: I thought that Time.time would reset to 0 every time I loaded the scene, so I directly input the variable delay (Time.time + Random.Range()) into the message delay, which meant that if I had played a couple minutes already, the message for that round would in turn take a couple minutes to show as well. I remedied it by simply creating an extra variable to send to the message before Time.time was added.
Looking back these had very simple solutions, but with no error messages pointing me in the right direction, I was lost for quite a while.
Polishing the Game:
Since the game is quite simple, and only really requires 1 input (firing when the duel starts), I wanted to go a bit old-school arcade with how the game progressed. I first tried to create an empty object and a script with DontDestroyOnLoad(); in order to save the variable “level” so I could scale the difficulty between rounds but found out pretty quickly it was not the optimal way to store the data. Instead I used PlayerPrefs, as it is far more ideal for simple variable value storage. This also allowed me to store a value for a highscore, which is displayed on the main menu. I also used the value to dictate the 2 things that scale the difficulty, the first being the delay before the turret starts firing (1.5*(0.9^level)) seconds, and accuracy (5*(0.9^level)).
When I set up the player’s weapon, I liked the idea the original blaster had with the fuse cells animating as you spent ammo. Although much simpler, I left a grid of 6 holes on the side of the pistol so that the player can see how much ammo they have left. This led to me question what was and wasn’t necessary on the HUD. I remember in particular an interview with Glen Schofield, creator of Dead Space, about how, to him, the HUD would ruin the immersion as its a very “video game-y” element to have, and would also serve as a distraction. He remedied it by putting all the information the player needed on the back of the player’s character. I thought the same with my pistol, what need was there for an ammo counter when the gun already showed how much ammo was left? Is the compass really necessary when the player doesn’t move? Is the health bar really necessary when everything in the game is intended to die in one shot? I figured no, and I think the result feels much cleaner without redundant or useless information covering up a significant portion of the screen.
In the end, especially because of how easy the first couple levels are, I wanted to add an extra layer of difficulty, so I removed the crosshairs, and made it so that you only had the 6 shots per round to win. I think that the gun not reloading might’ve confused people and since it’s rare to see that kind of ammo limitation in an FPS, I figured I’d just make it the title of the game, because really it is a theme in it’s own right.
Link to Game: