Hello! I've recently submitted a game for the GoedWare Game Jam, and wanted to make a quick post before going camping to tell you a bit of my experience making the game, and lessons that I learned along the way.

Context

 While I'm still a rookie developer, I do have some game jams under my belt. This game jam was different tho, because I had a whole week to work on the game due to being in vacations. I was pretty excited to make something while not being absurdly tired. This time my objective was not to necessarly to try a very whacky idea, but rather focus on the fundamentals of making any game idea fun. You can judge if I did a good job or not, but even if I didn't, I still learned a lot. I also wanted to avoid crunching, so I used Pomodoro to schedule my required breaks, but also made sure to take extra breaks outside of that.

The idea

 Because I wanted to focus on making the game as fun as I could, I went with very tried and tested core mechanics (top-down dodging and shooting) in a pretty standart context that would lend itself well for a game jam, (arcade, survival, round based) but putting a little twist on it. (every time you kill an enemy, you have to survive for longer) This not only lead to a solid foundation, having a "baseline of fun" so to speak, but also made it more intutitive for the players. I didn't need to do a very hand grabby tutorial, I just explained the controls and let the player, well, play. So that saved me quite a bit of time.

 A video made from the developer of Patch Quest really inspired to make this decision, actually. How NOT to make an indie game goes more in-depth about why this can work well.

Technical detour

 I implemented some basic enemies, and because of previously traumatic experiences with AI, I tried to make it simple, reusing as much code as I could while making every enemy have distinct roles. However, I realized that my ranged enemies, called Snipers, where sometimes impossible to dodge, even with the dash. This happened only on a very specific spawn timing, but I thought it would be a fun challenge to fix this, even tho it wouldn't affect the final product that much, and would definetly make the code more complicated.

 The basic idea is that sniper have a timed cycle where they aim, shoot and then reload, and I have to make each sniper have an offset cycle from the other snipers, by an amount of time that would let the dash cooldown end, enabling the player to dodge. However, how can you do that when you don't know when each enemy is going to spawn? I think the key to that is this bit of code:

 It determines how long a newly spawned sniper has to wait before starting its cycle. First it calculates the time it will take for the previously spawned sniper to shoot it's next shot, by subtracting the cycle time by how long it has been since that sniper shooted. If the resulting time is too low, we instead get the time for the next shot, by adding the cycle time to the calculation. In the last line, we add the interval we want between shots, while also subtracting the telegraphing time. The resulting time will be used to delay the sniper's sequence accordingly.

 That was fun to solve, but later on I realized that it probably didn't make the snipers easier to dodge, but harder. I'll explain that later...

Game feel & SFX

 With the main mechanics implemented, I was ready to add some juice! This was super fun, but also more time consuming than I thought it would be. I think that is mostly because of my inexperience juicing up games and a lack of SFX and game feel libraries. I used the free version of More Mountains' Feel for the Unity engine for camera shake, hit stop, and other effects, and found myself fumbling a bit trying to set it all up, specially with the new URP that kind of broke everything. In terms of SFX, I downloaded a bunch of free to use sounds, used Bfxr to make more specific sounds, and Audacity to edit and layer everything. I took more than a day of work to get all of that in the game, and didn't even implement particles. (which I highly regret, it would have made quite an impact I think) It's pretty nice knowing how much it takes now tho, I think in the future it would take me less because of what I learned, but the data is still super useful for scheduling.

Art & Music

 This is probably my biggest mistake this time around, one of the most important takes I have for the process: If you're going to have free art assets in your game, take into account how much time it takes even finding those assets, and then also implementing them. I misscalculated  HARD how time consuming finding assets is, and by the time I tried implementing them, I had other, more critical stuff to do. For the music I didn't even have time to search for any tracks, which is still kinda sad, but is much worse when you already spent so much time searching to still be lacking. And I didn't even think of how the assets would fit together. (I would've probably have to change almost every sprite's color palette to make them match eachother) Super important lesson, I hope I won't have this problem again, I'll make sure to schedule better, and if I see I don't have enough time, then I won't bother even searching for assets if I don't have them already.

Menus

 Took surprisingly little, and still added quite a lot of professionalism and pragmatic value. It's just so much better when you can pause the game and exit instead of having to Alt+F4. I had made a custom package for implementing the menus, which was pretty outdated, but with a few tweaks I had it running pretty well.  I think I should make more custom packages so that I speed up development time. Obviously, I shouldn't make my game full of packages, because then it isn't very fair for other participants, most of the game should still be coded/made in the time frame. However it's okay for some things, it's basically like using Cinemachine or other Unity packages that help you with specific stuff, but instead of getting something that other people developed, you do it yourself.

Intense ending

 Related tangent: sleep geneoursly, please. Did you know that not sleeping results in the same physiological effects in your body as being drunk? If you consider staying up late in the night making the game, and then waking up super early the next day, try to consider that that, is as good of a decision as starting to drink vodka shots in the middle of development. Not only your productivity will dicrease, maybe even becoming negative, (making changes that actually make you loose progress) but it will make everything you make, worse. And, you'll feel miserable, and not happy with the final product. So, it just isn't worth, I can tell you that both from personal experience and known research. There's a whole GDC talk about this if you're intrested. Anyway, moving on...

 Because of the previously discussed scheduling mistakes, and because I pushed back way to much some pretty important tasks, the last day I was on a frantic rush to finish everything critical. This lead to a few issues: first of all, I had to make a compromise about both the winning screen and the easter egg challenge, which might have lead to a worse product overall than if I didn't do any of this things. Secondly, some critical stuff where less polished and thought out than others, which kinda created an unprofessional disparity, where some things seem waaay better made then other. (case and point: the player character having a sprite while everything else is just kinda... squares, you know?) And thirdly, it just stressed me out. Not as much as in previous game jams, but still. 

 I think to remedy some of these issues, having the winning and losing conditions ready in the mid-phase of development is a good idea, you should absolutely make sure that you have that before the very final stressing stretch. I also think I should have taken even bigger breaks. It might sound counter-intuitive, but if I just would've taken a day off in the middle of the week, it would've already improved my workflow so much. The thing is, sometimes working less is better for the game. That break would've lead to changes in the game and the scope? Yes. But for the better. I would've come back full of energy, with fresh and better ideas, an improved plan of what to do, and with a happy grin in my face. My productivity would rise to its peak again, maybe even higher than before, but either way, making everything with better quality. This kinda proved itself on those 2 first days where I couldn't work in the game, and came up with an idea that I was really happy about.

Addressing feedback

 So, there was some compromises. One of the major critiques I got was that the "controls felt sluggish". Why was that? Well basically for three reasons: 

1. The movement speed was really low, because I was planning on making a speed-boost upgrade that I didn't have time to do.
2. I used the built-in Unity physics, with a bit of tweaking, which might've had some unintended consequences on lower-end devices; and 
3. The shooting, dashing, and slashing... didn't have input buffering. I was planning on adding it, but I really should've prioritized it more. While holding down the click button to shoot works well, if you don't, it's really unresponsive. Something to take into account next time.

 The other issue I want to focus on is difficulty: the Snipers were waaay too overpowered. The main issues were: 

1. If a sniper just spawned, specially if it was the only sniper, it could start aiming and shooting way too quickly. I should've made so that it reloads first, then aims and shoots.
2. It was really hard to dodge without the dash ability, the only other option was getting behind another enemy. Sometimes there weren't any other enemies, and even then the enemy could get pushed and can cause you to get hit anyway. I could've made the dash be enabled from the start instead of an upgrade, or designed the sniper in a way that it doesn't aim toward you directly, but your previous positions.

 A minor issue also was the readability, that was caused because I didn't implement the art assets, which lead to me not making an effort early on making distinct enemy shapes and colors.

Conclusions

 This game jam was loaded with lessons on game-making, I feel like I've learned months of experience in just a week. I think making this devlog really made me think of what I learned, I'm definitely gonna do this more often. Apart from what I've discussed in the previous sections, I would like to try out some other stuff next time: using PlasticSCM instead of GitHub, and Godot instead of Unity, and search for some sort of continous integration solution that is more accessible than GitHub actions. (I haven't done CI yet on any game jam because github has a storage limit)

 Anyway, I hope you got something useful out of this post, or at least some insight about my workflow. Have a nice day! Cheers 😁