Devlog 3 - Interactions, Puzzles, and Enemies (Or lack thereof)

Devlog 3 – Enemies / Interaction / Puzzles

This week mostly involved the interaction with a puzzling enemy called ray-casting. While trying to get my level generation functioning, I was plagued by phantom collisions being detected when newly instanced rooms were checking for collisions with existing ones. These phantom collisions would cause rooms not to spawn when they definitely have space to.

Prior to running into this, I was hoping to have generation out of the way within a day, but this stupid bug ate up three days of what’s left of my time. Instead of stumbling around in the dark, in an attempt to run into a solution though, I figured I would expand the editor and diagnostic functions of my room script in order to better visualize the problem. I started by logging each action each room takes.

I also numbered each room, rather than leaving them as Room1(clone) and Room1(clone)(clone) and so on. I then added visual names to each room to help relate them to the logging.

This wasn’t enough though, since it wasn’t able to tell me why a collision happened, only that it had.

The script will now, upon a collision, grab the exact position of where it happened, and send it to a director script, which collates them and displays them as purple gizmo spheres. With this, I was able to prove that the problem was not with the positioning of the raycasts themselves.

This only ruled out a couple of possibilities though, it still took hours of messing around to find the actual problem. By the time I had figured out what the problem was, my debugging system for the level generation had become quite matured.

From the beginning, the level generation script ran and finished entirely before even the first frame. Believing Unity to be reasonable enough to be able to handle this, I set up the process in such a way that new rooms are spawned centred on the spawner room’s corresponding doorway. The script then grabs the new room’s door offsets, and moves the room by that amount, so that it will be door to door with the spawner room.

After that, the spawner room invokes the collision checking script in the new room, casting out 4 raycast lines (visualized in cyan) in a square in order to catch any collisions.

This has since been changed to a boxcast (visualized in green) in an attempt to remedy the phantoms, but it did not fix them. I still kept the boxcast since it is a lot easier to manage in code.

After that, if no collisions are detected, it will add the room to a list of verified rooms, or else it will be deleted, and the spawner room will continue with the next door.

The point of explaining this, is that it seems like it should work just fine, everything is being done sequentially, as revealed within the logs, even though I haven’t actually given any specific order of operations for the spawning of each room, and all of the maths is correct as verified by hours of cyclic experimentation. Where it all went wrong, is in updating the position of the rooms correctly prior to passing the first frame. Even though I was explicitly telling the rooms exactly where to go, when they were running the collision checks, many other rooms simply hadn’t updated on their end, causing them to collide due to them not having yet spawned.

As detailed above, when room 3 is checking for rooms to collide with to the left, it still sees room 1 as not having been moved yet, and so it collides with it. Previously, room 0 has attempted to spawn room 1 to the north instead, but has collided with room 3, which has already been spawned, but not moved yet, thus causing phantom and time-travelling collisions. My solution to this was to simply make the rooms initially be spawned 100 or more extra units away, and then take away that same number just before running the collision checks. This, for some reason, fixed the phantoms. It did result in collision checks failing at random however, leading to overlaps, so I added in an extra collider to ensure detection.

Finally, with the generation functioning correctly, I moved on by making a new function in the director script that deliberately waits for two frames, then begins checking door connections. I’m sure if I didn’t add the wait, more nightmares would arise. Each room first checks for neighbouring collisions, then if it finds one, it checks to see if their doorways line up. If it doesn’t find a collision, or the doorways don’t line up, then it will seal off the doorway.

With this system all set up, the implementation of future room designs should be straightforward and easy (lies). Had I perhaps added some waiting functions in the scripts, it may have saved me some time, but what I have now works well, and I am quite proud of it. My latest adjustment is in making the generator create a specific pathway, rather than span out in a big blob every time.

Feedback received this week was mostly limited to the issue of the player overlapping the torches in an odd way.

I am yet to fix this, since I haven’t had time to yet.

It also didn’t take long for someone to run into the square of testing, nice.

In the next week, I will begin work on the player combat and possibly some enemy AI. I have been putting this off for weeks, so I am keen to finally dig into it, as so far, the game has admittedly been void of any actual gameplay.

Thanks