Building out a Room System for level generation -- Owen Meyers

     Our game is a rogue-lite that assembles levels dynamically in order to afford maximum replayability for the player. In order to do that in as simple a system as possible, it was decided to have a registry of prebuilt rooms and to string them together randomly in order to build the floor. The result would be a balanced gameplay experience that is random every time, as the game would be built from pre-designed and balanced rooms that are strung together in a unique manner. Building this system would be relatively straightforward, as all that is needed is a list of the following -- Meshes (including transforms), lights, enemy spawn points, and colliders for doors, walls, the floor, etc.

    The first hurdle to jump over is actually building the level. I opted to utilize Blender for this, as I have a script that outputs objects and their transforms from a Blender scene. Included in this is the name of the object, allowing for mesh names to be parsed from the room as well. Thus, our levels are built in Blender and output to a text file, which then goes to the next step of the pipeline. Also within Blender, we need to be able to specify colliders and spawn points, as lights and meshes are the only things that can be parsed from Blender. It was decided that cubes with specific names would be utilized to simulate the desired values. A collider, for example, would be the cube without any rotations, and with a scale applied to it to generate the actual bounds. The transform would then be used to generate an AABB from that bounding volume. This allowed for named "meshes" to also be output from the scene, but which were actually utilized for other purposes.

    The second step of the pipeline is converting that text file into a format that works perfectly within the engine. To do this, the matrices within the text file must be matched up into a list of meshes with no repeats (i.e. every mesh must have a list of matrices, not multiple of the same mesh). This allows for the static meshes to be instanced easily within the scene. Meshes that are specifically marked as enemy spawns or colliders must be treated differently as well, output in the actual format the engine uses. Once all of this is done, the system within the engine must be able to take in the binary file and read in the constituent data. Once that is done, the rooms can be put into a pool and referenced by the level generation system in order to build out an entire floor.

The shop room in Blender. The gray boxes are various colliders, as well as spotlights pointing at the doors.


On the left is a compiled ROOM file for the above room in Blender, generated from the text file on the left. The text file is output by Blender.


Comments

Post a Comment

Popular posts from this blog

Adding assets to every enemy -- Owen Meyers

Image
      As with every game, it is very important to have assets to denote which enemy is which. Being able to tell at a glance what enemy you are encountering before receiving a face full of buckshot is incredibly important. The issue for Project [REDACTED] is that we didn't have any artists working full time to deliver assets for the enemies. Thus, it fell upon me, the designer of the asset pipeline, to acquire assets for every enemy. This led to having to fix models and integrate animations, with each problem being subtly different.     Take, for example, the shotgunner model. His original model was designed for an OpenGL renderer, and was flipped 180 degrees for that very reason. In addition to this, he was also placed halfway in the ground, likely due to something required for that game's collision to function. Fixing this model to function for our renderer required that it be re-rigged and most of the animations acquired from Mixamo. With the help of Kris, and several hours
Read more

Sphere to AABB collision

       I had a problem today when trying to detect sphere to AABB collision. For some reason the collision check that I made was never turning true even though I could clearly see the sphere hitting the AABB. This was a big problem as we needed this collision to detect whether any entities are hitting walls.     I discovered that the problem with this bug was that I was improperly getting the closest point in the AABB to the sphere. The way I fixed this problem this problem was by getting the max vertex that the circle center could be and using that to get the closest point on the AABB to then determine the minimum vertex between the sphere's max vertex and the max of the AABB.  Once I found this point, I could properly compare the distance of that point to the center of the sphere. This solution will allow detection between walls and any sphere collider such as the player collider, and enemy collider. This is very important to make sure they both stay within the level bounds.
Read more