A Discussion About Development

So let's talk about Door Breakers a bit. I'm going to go ahead and preemptively apologize for the layout and flow of post, it's mostly just going to be a stream of consciousness with little to no editing afterwards so if it does not make sense, my bad.

Those of you who have been following along with it since the beginning already know some of this, but for those who do not know I participated in this jam as a way to take a break from the spooky paranormal investigation game I'm developing. I'm not here to discuss that game, but I really needed a break from it because I was getting frustrated and frankly a bit burnt out with it. 

So originally I had planned to come up with an idea for each of the potential themes for the jam but I'd only been able to come up with an idea for the Relationships theme (which obviously was not chosen). I had recently seen some talk about some old arcade games and thought an on-rails shooter where you play as cupid shooting couples with love arrows would be a fun and silly idea. Since that had been the only idea I managed to come up with in the week leading up to the jam I decided to go ahead and repurpose it for the "What's Behind The Door?" theme. So I kept the idea of it being an on-rails shooter, I figured that would be a good excuse to properly learn how unity's new(ish) Splines package works and I figured I could find some door assets I could use to shoot at.

So the idea was to use the splines package to create the path for the player to follow, which is what I did end up doing. It was fairly easy to learn how to use the package to create splines in the world and the package even has a component to animate an object along the spline. So my movement was pretty easy to get set up. My only issue with that was that I had little control over what part of the frame the object was updated on, and getting the different splines to line up well so there was no sudden jerking when it moved to the next one was difficult. If you've played it, you'll probably notice a couple times where there is a bit of a jerk to the camera as the player turns to keep following the path and this is exactly why. I probably could have written my own class to move the object along the spline and slerp its rotation on those edges of each spline to reduce the jerking, and I'm sure it would not have been too difficult, but I figured for a jam this was really just "good enough".

Once I'd figured out the spline package and movement and stuff the rest of it was fairly simple since it was stuff I'd done for other projects or random prototypes, or even just stuff I've helped other people figure out in the official Unity discord. My biggest hurdle came with getting the arms to correctly follow the camera's rotation.

I used Unity's RotationConstraint component for that. It turns out that updates in LateUpdate, same as the CinemachineBrain component. However, the CinemachineBrain apparently is set to update fairly late using the Script Execution Order setting in Project Settings. This normally wouldn't be a problem, but with the camera's position and rotation updating later than the arms updating, the arms actually ended up being SUPER stuttery at first. And for some reason it is impossible to change the setting for the Script Execution Order for the CinemachineBrain, it just kept resetting back to what it was, and the option to change when the RotationConstraint updates was non-existent. So I ended up just writing a component that would update the CinemachineBrain in Update manually instead of automatically in LateUpdate. This worked fairly well since the player's position updated in Update but CinemachineBrain still had that later Script Execution Order setting, so the arms were able to update after the camera but before it rendered so everything was in the correct position by the time it rendered instead of some parts being a frame behind. 

Those issues were all fairly easy to figure out and solve pretty quickly so by day 3 I'd had most of what I wanted in the game ready. Then I built it.

It turns out that I did not pay enough attention to the size of some of the assets I included (or rather the sheer number of meshes that altogether increased the size) and while my build was fairly small at just under 200mb when archived, the Build.data file was 230mb. itch.io has a limit of 200mb per uncompressed file for web builds. So even though my game was well under the upload limit of 1gb, it could not play in browser because of that single file that was 30mb too large. So then I had gone through and simplified a bit, I removed a few of the buildings and just reused some of the ones I didn't remove, I removed a few sound effects, I increased compression on the largest textures. It wasn't enough, I had only gotten it down to like 220mb. So I turned on compression since I'd left that off for quicker load times. Brotli compression, which is the best compression, was tested first. It made the files pretty small, well enough under the limit with Build.data only 98mb after extraction but it took itch.io more than 5 minutes to actually load the game when I tested it. That was unacceptable so I tested out gzip compression. It got everything just small enough that I could upload and play in browser with no issue. However Build.data was large enough still that I didn't want to risk adding too much else to the build.

So at that point I decided that I was pretty much done, it was only like day 4 of the jam but I couldn't add much else for any extra polish or extra features. So I finished up what was already there, added the end sequence and called it finished. There are a few things that I would have liked to have added but they weren't really necessary and would not have added enough depth or fun to the game that it would have been worth spending the time adding them and trying to ensure the build was still under the size limit. 

As a result of the build size issues, I have now learned the importance of actually paying attention to the size of assets, especially when building for web. I typically develop for PC with the exception of jams where I build for web to ensure everyone can play it. So while the asset I used appeared to be low poly, it seems that it actually wasn't low poly and was just designed to look that way. Or at least that's the conclusion I came to, I don't really know much about 3d modeling and stuff like that hence the use of assets in the first place.

Now that I've rambled about the issues I had during development, let's go over some specific features in the game. The two most common complaints about the game are a lack of a crosshair and how the recoil works. 

In regards to both: that's kind of the point. Not every game needs a crosshair, if this had a crosshair it would be too easy, and the game is already easy enough. Plus I personally prefer no crosshair for arcade-y games. The lack of crosshair means you need to actually pay attention to where your gun is pointing and get a feel for how it shoots. That's part of why the first two doors you can shoot at are positioned they way they are, it's an early opportunity to get some easy points and get a feel for how the gun shoots. Of course later on when you get power ups like the shot speed, it may start to feel a bit different but that's part of the game too, you have to adapt.

As for the recoil, I kind of agree that the recoil does not feel like you would expect. I wanted the recoil to make it a bit difficult to rapidly shoot and hit the targets when you are just blasting away. This also is not meant to be a milsim, it's an arcade game and you shoot bullets the size of your fist from a 45 caliber gun. Now this isn't to say that the complaints are "wrong" or players need to "git gud" or whatever, it's just simply an explanation as to why I made the choices that I did. I appreciate any and all feedback on this and all of my projects, including my in-development spooky game. Anyway, I used cinemachine's impulse listener and tried to get it so that it would just roll the camera and arms upwards, but it seems that maybe I just don't fully grasp how the impulses work and maybe I should have just slerped the rotation manually or something, although I do like how everything would go back to its original rotation after the impulse. So maybe I just need to learn how it works a bit better. That part of the game I can say was a miss, but I think I did a pretty okay job with the rest of it. And it works very simply so pretty much the entirety of the performance impact is graphics related.

Anyway, thanks for coming to my ted talk or whatever. This has been a small look at my process.