Refactoring for growth
While developing the wireframe for my little adventure game, a glaring issue began to jump out at me. With the overworld set up to be 10 layouts high and 30 layouts across, I faced a challenge that would either cement or break the tone I wanted to achieve — how to guide the players from one area to the next.
All too often, the method I see used is along the lines of placing portals in an obvious open area that takes the player to a corresponding location in the next area. This is a straight forward solution, maintains the flow of game within control and reduces unexpected scenarios.
After coming up with the wireframe for a couple of dozen layouts and working out how to keep it interesting and not break the suspension of disbelief, I became frustrated. This method felt extremely linear.
During the mechanics testing, I found another issue that was jarring to the experience. By using the standard portal method to navigate to the next layout, the players would shift to whatever the default coordinates had predetermined.
Thinking back to the countless games I’ve played through my life, I was struck by how it was always like this. I paused further wireframe work and thought about these issues. I realized that whatever solution I came up with would need to be scalable to account for the 300 overworld layouts as well as the still undefined amount of dungeons, caves, fortresses, etc.
The first solution I came up with involved adding a perimeter of 120 tiles around the layout.
While this made the players shifting issue less noticeable, the resources spent working on this method were significant. Each of the 120 tiles needed to be programmed to its corresponding location. After a couple of timed trials, it became apparent that the average time spent on this method per layout would be around 45 minutes. Given the scope I am working towards, I would easily hit upwards to 400 hours on just programming the level switches.
The other resource issue this had a massive hit on was the file size. Though each one was relatively small, accumulated, the tiles totaled about 146 megabytes. Again, I paused work to reflect on the process.
After taking a few days away from the project, I worked out an alternative solution. Rather than use an excessive amount of objects to trigger the level change, I came up with a module system that works out where to place the players and relies on a perimeter of only four objects per layout to trigger this shift.
I tested it and it was fantastic. The players automatically went to the precise corresponding location in the next layout — keeping the suspension of disbelief going a little bit longer. This meant that the players truly could explore the entire world — which freed up the concern I had of making the design too restrictive. The process to add in and connect a new layout was reduced from 45 minutes to about 3 minutes. And, equally important, the overall file size remained reasonable.
Keep an eye out for more updates in the near future!