The past two weeks our team has been prototyping, researching, and documenting the new mechanics and systems we plan to implement into Cash Force. The programming team is focusing on the core architectural pillars of our game such as guns, interaction, AI, and levels. We had many systems to discuss and flesh out. With all this finished this week, we are ready for the next two weeks of sprints to prototype and prove our concepts.
My focus these past sprints were on the handling / interaction system and the procedural level generation system. Both these system required a large amount of research and architectural design in order to understand how it could be best implemented into our game. The progress I made on understanding these systems help me determine the future architecture of each and the functionality needed.
Handling / Interaction System
One of our most vital systems in the game, the handling / interaction system allows object manipulation and movement with the players hands. Our current version of this system has proved to work well for our current needs with minimal bugs. Unfortunately it does not support some of the future development we planned for such as sockets, weapon attachments, and body rigs. We are building the new architecture from the ground up to ensure we are creating modular functionality that will work for all mechanics we need in the coming sprints. Taking inspiration from games like Boneworks, Blade and Sorcery, and Job Simulator, we have decided on the feel we want when players interact with object in our game. Creating a strong feedback system and UI indicators will further the user experience, but at its core we need strong input and physics system in place to make objects feel natural to hold and grab. With some prototyping we have done and more in the coming weeks, we really hope to have this nailed down before our next milestone in a couple of sprints.
Procedural Level Generation
To lighten the load on our level designer, we have decided to move towards procedural generation methods to do the bulk of our level creation. While researching we came across multiple methods and examples on how we could create this system, but landed on two main concepts. The first is a example system created by Jonas Tyroller for Islanders, which discussed their methods for randomly generating level. Through breaking down the level into layers, they were able to control each step to their need. This was the base for our system. By breaking down our level into roads, buildings, and environment, we were able to start defining how we wanted each to look and feel. Our second concept came from methods of performing procedural mazes or dungeon generation. Using path finding algorithms with Manhattan style rules (creating squared blocks) we could generate roads to and from a selected start and end location. Since we intend for our players to have multiple routes they can take, we just need to slightly modify the algorithm to our new constraints. With central points of interest implemented into the level, it will allow for less roads needed to be generated, and core structures to revolve around. While our system is starting to be documented, the next sprint I'm tasked with creating a 2D version of this system that can produce our desired results.
Coming Sprints
With our core documentation laid out, we are ready to prototype some of the new features and prove they are viable to complete this semester. We have determined many of the risks we face in completing these new systems and are documenting our back up plans in the case we are unable to reproduce our intended functionality. Overall we are excited to start implementing the many ideas we have been researching the past few weeks and excited to update with our results in the near future. Until then, thanks for reading, it's time to get back to the code!