Enemy AIs, UI logic and Adjusting Weapons Architecture

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 it way easier to add new weapons in the future. It also separates logic cleanly between the player and the gun itself. It will let me expand the game without rewriting everything every time. 


Gun Handling and Pickup Logic

On the player side, I added a script called "PlayerGunHandler" that lets the player equip, fire, and drop weapons. Dropping a weapon isn’t just about unparenting it: I had to reset its physics, reactivate its collider, and even add a delay before it becomes pickable again (so you don’t just re-pick it up by mistake). There's also a difference in how the player fires depending on the weapon type, which is handled automatically now. 

This part was EXTREMELY complex and it took me quite some time to get it right, specially the damn "drop and pickup weapon" mechanic. 




Enemy AI: Finally Doing Something

I implemented two types: ranged and melee. Both use the 2D NavMesh system for pathfinding, and both switch states based on what the player is doing.

The ranged enemies stay still until they see the player, then start shooting at regular intervals. If the player breaks line of sight, they’ll start chasing. Melee enemies behave similarly, but they try to get close and punch you instead. It’s a pretty basic state machine (Idle, Chasing, Attacking), but it makes a huge difference in gameplay. 



The trickiest part here was raycasting and making sure the enemies don't shoot through walls. I also had to override some default NavMeshAgent settings since I’m working in 2D. 


I got all of this thanks to this video that explained how to set the NavMesh for 2D projects: 

https://www.youtube.com/watch?v=HRX0pUSucW4&ab_channel=Rootbin

First UI: Pause Menu

I also implemented a proper pause menu. Pressing Start freezes the game, switches the input context to UI, and lets you navigate with a controller or keyboard. The pause canvas gets enabled, and buttons like Resume and Quit become interactable.

You can’t shoot or move while the game is paused, and it even resets input modes when you unpause. The game also defaults to selecting the Resume button automatically so you don’t need a mouse. This part was a bit tricky as well since I had to edit the provided input asset and create a new action map that could work with the arcade machine. 

I still need to implement the "Main Menu" and "Win/Lose" UIs (as well as the winning/losing conditions) but that will be for the next blog post.

Wrapping Up

I’ve reached a point where the game has a solid structure. I can drop in new weapons and enemies easily thanks to some solid prefabs I managed to create. The player seems responsive as well, the pause menu finally does its job, and the input system is clean enough to adapt to the arcade machine.

Next up, I’ll probably focus on visual polish (the TileMap was not sliced properly 😭), create the Main Menu and Winning/Losing UIs and conditions, and fix some last minute bugs. 

Comentarios

Publicar un comentario

Entradas populares de este blog

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