Proof of Concept 1: Dev Log

January 17, 2017

Aside from designing, I was in charge of developing the system that spawned rooms as well deciding upon small interactions players would have with the game, some for the sake of having more natural interactions, and some for the sake of saving time.

 

To begin with, I was dealing with procedural generation. Although it wasn’t random, it still had to be introduced in response to the player’s action. Because this was a proof of concept and because I had limited time to complete it, I chose to have all the rooms be made as squares. This was done for a couple reasons:

 

The first was that all the rooms fit together into a grid very nicely. Although it would have been nice to have varying sized rooms, it would make the core mechanic of our game a lot harder to convey, which I will touch on more later.

 

Secondly, this method allows the level designers on my team to quickly mock up on and iterate on each level design. Because each room has to fit into a certain spot rather precisely, we could make a base template for the rooms and then use that to generate the levels in MagicaVoxel. 

 

It was also so much less time consuming this way as the coding side of it didn’t require many checks to make sure a room could be placed or anything of the like. 

 

Going back to our core mechanic and our focus of this proof of concept. Our goal was to install the sense of discovery and perspective shift into our players as their view of the card of each room from top down differs greatly from the players view of it in first person. If we had more varying sized rooms, we’d have to make more things to populate that level specifically, which would require more man power. If we could not handle this, we would have to rely on generating more content randomly, which would take the meaning away of having the player design the dungeon themselves.

 

From a more technical standpoint, this was really hard to do, and then really easy. At first, I had a base room with 4 exits, 1 on each side. The room that you were in knew you were inside of it, so based on which door the player was at, the room instantiated another room based on that. However, this lead to problems with overlapping doors when rooms were instantiated beside each other. In order to fix this I realized I will never be a true coder and put colliders and rigid bodies on them and destroyed them if they were overlapping. Further along into development, when doors didn’t have 4 exits all of the time, a door wouldn’t destroy even when it lead into a blank wall, so I took a similar approach to when it overlapped other doors and destroyed them that way.

 

Also, since our goal for each room was to have a micro-level, we decided to make each room have a designated entrance. We accomplished this by rotating each room by seeing which door it was spawned from, and based on that rotation, set each of its doors to its true compass direction based on the room they were spawned for.

 

Definitely going back to this idea, I would push for being able to further customize each room, while still trying to maintain their designs. give the player more nuances to explore or have more challenging platforming aspects and the such are things that can push this idea further.

 

-------------------------------------------

 

The goal of this proof of concept was to demonstrate our core mechanic of card based dungeon building. I feel that we started on the right track of accomplishing this, but there were many more things that we could of added to make that mechanic more visible. 

 

Going back to one of our earlier ideas, we wanted the player to be able to choose an element of the room and an element for themselves. By limiting the amount of times they could change their own element, they would have to try to build each room with an element that they were advantageous to. This would of added a layer of customization that supports the building mechanic, but also would introduce many aspects that could of been built on later. This idea was scrapped due to time constraints and lack of resources, but it is an example of the direction we were trying to head for. 

 

I believe rather at hinting at other mechanics that would be in the game, we should have solely focused on the construction of the rooms. You get to choose the amount of enemies in each room, and that is an aspect of customization, but looking back on the project, we could have directed the energy toward that into something of equal or more value that undoubtedly made the player feel like creating each room was meaningful to them. Regardless these mechanics were fun, and if we went further with this, we would definitely develop them more. 

 

However, I'd still say the proof of concept is fun. Although we don't  have a goal for the player to strive to, going through each level and looking for the chests is a very enjoyable thing to do. This experience is capstoned by getting to the exit door of the level and using a card to make the next room. By having that perspective shift from the top down view of the card to the first person view of the room itself is a great feeling that player's will enjoy. Touching back, the treasures and enemies also add in a layer of fun as each room has its own design, and the chests placed are rewards, but also a scavenger hunt.

 

Overall, I feel that this proof of concept was good and the biggest criticism that I can hove it would be that as of now, it lacks some focus that could of been found in the building dynamic. 

Please reload