Polishing, Win/Lose Conditions, Main Menu Setup and some other Bug Fixes

Polishing, Win/Lose Conditions, Main Menu Setup and some other Bug Fixes

This post is all about polishing the game experience, implementing win/lose conditions, and finally setting up a Main Menu to give the game a proper flow. Most of the mechanics were in place already, but now it’s about making sure everything feels smooth, responsive, and coherent.

TileMap Pain (and Progress)

First off: the TileMap slicing issue. I originally imported a tileset with incorrect grid settings, so some tiles weren’t aligned properly, causing seams and offset visuals in the scene. I went back, re-sliced everything using the correct pixel-per-unit and grid cell size, and re-painted the level. It was tedious but absolutely worth it. The environment feels more consistent now, and small things like tile alignment really DO affect how polished the game looks. Below is the final view of how the "FirstPlayable" level looks like.


Of course, not everything in the above picture is made from the TileMap. Some furniture and "Movable" objects were inserted in the scene separated from the TileMap. The "Movable" objects have a Rigidbody 2D and a box collider, while the other furniture only have a box collider. Besides, all of them have attached a "Navigation Modifier" from the NavMesh 2D Unity so when baking the NavMesh path, those objects are skipped and set as "Non Walkable". Below is a picture of how the map looks like after it has been "baked".



Win/Lose UI

Next, I implemented the Victory and Defeat screens. Now, when all enemies are dead and the player is still alive, a "WinCanvas" appears showing a win message, along with options to restart or quit. On the other hand, if the player dies, the pause menu is repurposed into a death screen with the text "YOU DIED!!!" replacing the normal UI. I could have created another canvas for the losing condition, but I thought that reusing the pause menu was "faster" to do. However, thinking in the long run, I think I should have created a new one so the logic and the structure looks cleaner.

To avoid weird behavior, I added checks to make sure this message ONLY appears when the player dies (not when you pause normally). That meant separating pause logic from death logic and making the UI respond accordingly. 

Fixing Friendly Fire

Another huge bug that I finally fixed: enemy bullets damaging other enemies. Initially, I had no way to tell who shot what. So a ranged enemy could end up wiping out their own allies by accident. I solved this by assigning a "shooterTag" to every bullet when it's spawned (e.g., "Player" or "Enemy"), and adding logic in the bullet collision that checks the tag of the target. If the tag doesn't match the intended target group, the bullet is ignored. This ensures that enemies won’t shoot each other.




Gameplay UI System

This was something I had been postponing but was absolutely necessary: I created a dedicated "GameplayUI" script to handle all the real-time player feedback on screen. It displays the number of remaining enemies, manages the ammo count, shows/hides weapon icons, and handles both the Victory and Defeat UIs. Now, whenever an enemy dies or the player picks up a gun, the UI updates automatically.




Main Menu and Scene Flow

I finally created a Main Menu UI that appears when you launch the game. It includes Start and Quit options, and cleanly transitions into the game scene. I had to tweak the "InputSystemUIModule" and make sure the arcade setup could still navigate through the UIs. 


There's a consistent flow now: from Main Menu → Gameplay → Win/Lose Screen → back to Menu or Restart.


General Polish

Beyond that, I did a general pass of polish: added sounds to firing weapons and background music, fixed some buggy input behaviors, and I even made sure that ammo UI only appears when you’re actually holding a gun. Now that I am writing this, I feel like I could have implemented the same architecture and logic I did for the weapons, but for the enemies as well. Sadly, I am running out of time, but it is worth it to mention. 

Next Post

For the next blog post, I will document if the game successfully works (or not) on the arcade machine. Exited and scared at the same time.



Comentarios

Publicar un comentario

Entradas populares de este blog

Enemy AIs, UI logic and Adjusting Weapons Architecture

Imagen
NavMesh 2D, Changing Weapon's Architecture, and Implementing first UI For this blog post, I started by cleaning up the weapon system, then gave the enemies some actual AI, and implemented a Pause Menu. A Cleaner Way to Handle Guns At first, the weapons were just hardcoded actions. One script, one gun. But that wouldn’t scale, and it was starting to get messy. I was having some other problems as well, specially when grabbing and dropping the gun, because (for some reason), clones of the GameObject were being created instead of using the original. So I decided to restructure it using an abstract class called "GunBase". Every weapon now inherits from it and implements its own "Shoot()" method and other characteristics a weapon has (ammo, icon, audio, etc). For example, the pistol and machine gun now share the same structure but behave differently (semi-auto vs. full-auto). There’s also built-in logic for ammo, bullet speed, and reloading.  This approach makes i...
Leer más

Core Gameplay Prototype

Imagen
Introduction So far, I’ve been building the foundation of the game by getting the core gameplay running: movement, shooting, and bullet ricochets. These mechanics define the entire feel of the game, so I wanted to make sure I nailed the basics before diving into level design or AI. Movement & Rotation I started by implementing 2D movement using Unity’s new Input System. The player can move using a joystick or keys, and optionally rotate toward the aim direction (in my current setup, that’s the mouse). A key aspect of the experience is that the player always faces where they’re aiming or moving, which makes the action feel more responsive. If you’re holding the "aim" button, the character rotates toward the cursor. Otherwise, the player rotates automatically based on movement direction. Shooting System & Bullet Behavior Next came the shooting system. Once the player picks up a gun, they can shoot in their current facing direction. Bullets are instantiated slightly ahea...
Leer más

Final Game and Conclusion

Imagen
What I Built and How I Did It Throughout the development process, I got to work across nearly every Unity system: Scripting : I wrote dozens of custom scripts using to manage weapons, enemies, player controls, pickups, and more. I also used coroutines for actions like rolling invulnerability or UI transitions, and relied on Unity events to communicate between systems (like triggering win conditions when all enemies are dead).  Input & Vectors : I implemented the new Input System , allowing for both keyboard and arcade stick integration. Movement and aiming are handled using vectors to rotate the player or calculate bullet direction with precision. Physics : All movement and combat use Unity’s 2D physics engine . I configured rigidbodies , colliders , and triggers to manage everything from bullet impacts to object pushing. Careful layer setup and tag filtering helped prevent unwanted collisions (like enemies accidentally killing each other). Graphics & Audi...
Leer más