Imperfect Control: Gameplay

 As promised, in this post I'll be talking about the gameplay in Imperfect Control. As the name suggests, I wanted to do something different with this game rather than creating a typical roguelike where the player moves around the rooms. Instead, I had the idea of having the player move the enemies. Each room then becomes trying to perform the correct movements to destoy the enemies (by moving them into hazards), while at the same time making sure the player wasn't hit by any of the enemies. 

Spawning:

I wanted each room to have a separate parameter (which I called hazard level), detailing how difficult each room would be. Each room could then be generated with a seperate value as part of the map (Part of the reason for this was that one of the powerups I was hoping to add would reveal the hazard level of nearby rooms, unfortunatly I didn't manage to implement this). To control the spawning of each room therefore, I assigned this hazard level, and therefore the spawning, to the door of the room. Due to the map generation algorithm (see the previous post), each room has a unique door that is on the path back to the starting room, so each door can identify a room.

Room spawning

 

  • The algorithm:

The spawning algorithm for each object was pretty simple:

  1. Find a random coordinates between 0 and 20, with 10,10 being where the player is.
  2. If the coordinates are too close to the player (within 4 cells), restart
  3. Check if there is already an object at that location, if so restart (Done by checking for unity coliders)
  4. The spot is empty and far enough from the player, spawn the object.

I say each object rather than each enemy because this algorithm allowed for spawning of enemies, hazards an powerups in the same way. All I needed was some code to decide which things would be spawned (usually by picking a random index over the number of elements, like I did for the walls in the previous post), and then the spawning code was complete.

Movement, projectiles and triggers:

Quite a lot of the meat and potatoes of the gameplay came from making sure that when two things collided, the right thing happened. To control this, I used the Unity tagging system to designate the right objects to be handled. I used triggers in some cases to run code, but for certain bits of detection (only on the boss, I think) it made more sense to check for the collision in the update callback. With hindsight, I didn't do this quite as cleanly as I'd have liked; for example, each enemy had scripts attached to it's top level object, however it also contained a bounding box that acted as a hitbox, which also had all of the compoments as a child. Next time, I will know to make the hitbox the top level object itself, as that allows for easy inergration with the code without having to worry about it being on a different level of parenthood. 

Sorry if I went too deep into the techincal details there. One thing I did like about my implementation was that I avoided using Unity's inbuilt physics, allowing me full control over the objects as they wouldn't get into unexpected decisions. Projectiles were controlled in the update loop, so their position was adjusted every frame. I did use the physics for one thing though. When the player dies, I instantly enable collision and physics on all of the parts of the player's body. As many of them were already clipped into each other to produce the desired shapes, the result is an explosion, perfect for highlighting the player's loss. Boom!

Boom!



Comments

Popular posts from this blog

Armageddump (Boss Rush Jam 2023)

Introducing: Minigame Monday! (3D Minesweeper)

Minigame Monday: Covert Behaviour