🌳🌳🌳 🤖⚡️🌳🌳🌳
Greetings, BANJOS is returning with a final update to our game! The main changes we made were implementing the rest of the UI, adding the endgame state of the game, and fixing sound issues. Let’s overview the entire game!
Story and Gameplay
Since the first two weeks were remote, the FIGJAM board was very helpful for putting down a lot of ideas and images. The main themes that we gravitated toward were: technology, nature, and robots. After a lot of brainstorming, our narrative began with variants reaching “the core” and the creator trying to stop them. The variants would have an isometric view, while the creator has a bird’s eye view. However, this idea was pretty vague, and difficult to figure out interesting game mechanics. Our biggest breakthrough was deciding that the robots could be soldering robots and the map as a big circuit board. It was much easier to figure out character designs, map designs, and also sound designs. Many of our initial gameplay ideas were based on using different electrical components to redirect electricity: resistors, capacitors, diodes, and LEDs. We also wanted to try different tools for soldering, like the wick for desoldering and a hot air gun. In order to streamline the game due to the time constraint, we kept soldering, resistors, switches, capacitors, and LEDs.
We struggled with getting networking and unity working in the early stages. So we didn’t plan out the creator’s gameplay until the later stages. Instead, we focused a lot on the variant’s gameplay and making sure their mechanics were working. If we were to do this again, we would do more paper prototyping to explore different game mechanics.
Visual Development and Character Design
At first, the visual development was generic dark forests and a concept of the core. After we figured out the circuit board and soldering theme, it was easier to create concept art for the map and characters. The characters were initially going to be 2D animated, but then it was switched to 3D. It took a bit of time to set up the models, but it paid off in the end because the characters matched the environments well and it was easy to iterate upon. If we were to do this again, we would not hesitate to start on the 3D models.
Map Design and Level Design
The most important part of map design and level design is how to relate them to our gameplay and concept. At first, we intend to divide the game into two phases with one as the tutorial and skill-build phase and another as the main phase. But we focus on the main phase because of the limitation of time. We base our game map on the combination of the forest and the circuit board. The circuit board expresses our narrative and concept and the forest offers an environment concept for our gameplay.
In early map design, we used a layout of the circuit-board-style with the forest and the core. Then we tried to add some simple puzzles. The original puzzles consist of lights, resistors, and switches which composed our game map for the Alpha. After that, we discussed how to make them more interesting according to our asymmetric gameplay. We decided to make LED light as the components to control the view which meant both sides needed it to gain advantages. It was viewed as the most important interactive element on the map and a way to achieve a dynamic balance between both sides. More detailed and specific mechanics and relevant components were added to the level including the container for recharging, the gates for entering the core, and so on.
After the basic frame formed, we spent some time adjusting the light setting. We developed a color scheme of purple and yellow to fit the sneak vibe and our UI design. During this process, we tried different ways for light settings and finally used point lights, material emission, and post-processing to realize the expected visual effects.
The most important and difficult parts of the process are not about technical problems (there are but not very very difficult). They should be:
- Relevance to the gameplay: we need to develop our map based on our core gameplay and make all the elements form a system around the core mechanics. In our map: 1) the relationship between the lights and the different view angles mechanics; 2）the relationship between the other components and the soldering mechanics; 3) the relationship between the forest and the sneak mechanics.
- Visual consistency to the art concept, UI, and character design: consistency is critical for the players to view the map and the level as a part of the whole game. In the process, we spent some time adjusting color, material, lighting, and shading to make it look nice. Getting all the artists on the same page is important.
Take-way: if more time is allowed, we may:
- Add some details into the environment for liveness and appealÂ
- Trees with different heights on different scales show distance to the core and make the difficulty different during the process of getting close to the core
- Refine the visual effect after all the functionality implementation and debuggingÂ
Programming
Over the course of the semester, we found many roadblocks in terms of getting certain functions of our game to work. Some features were difficult to implement, while others were quick 5-minute bug fixes. No matter the changes, though, we almost always ended up with some Git merge conflicts. While that might not have been the hardest thing to deal with, it was certainly one of the most frustrating. These conflicts were particularly bad at the beginning of the semester when the programmers were not always completely on the same page but greatly improved as time went on. Communication and better splitting up the work were very important in alleviating how many conflicts we would have to resolve. If we could change one thing from the start, it would definitely be coordinating better what changes we were making and not messing with the other programmer’s work.
At the beginning of this process, we struggled greatly with getting networking to work. We eventually settled on using Photon PUN to easily create rooms and servers, but the fundamentals of networking did not click until midway through. Because of this, we were unable to get started on implementing the main gameplay until past Alpha. We also figured out later on that having a priority list split amongst us was much easier to manage than just updating the discord. This way, we could discuss current updates and make sure all of our changes are kept with the merges.Â
On top of that, we realized that either we did not implement Photon properly, or it has difficulty handling a backlog of RPC calls because the game would start to have a really bad delay, making it unplayable. This only occurred the night before the final presentation, and we have yet to discover why this happened because it would fix itself sometimes. I think if we were to redo this game and process, I would look into other methods of multiplayer, mainly Fish-net which was created by someone who also harbors a distaste for Mirror networking.Â
Overall, the coding process for us was a big learning curve since both Angela and Jasper did not have extensive coding experience in Unity. However, we have learned so much about everything from organizing code all the way to making sure our scene doesn’t break.
Sound
The process for sound design was pretty simple. It was a team effort to lock down concepts and aesthetics of what the game would be, and from there I would go off and create sounds. Upload them to a google drive for the coders to implement according to my specifications. Once we locked in an aesthetic and I was able to make some initial concepts, I was able to quickly iterate and improve on all of them. Efficiently update music and SFX according to playtests and feedback.
It was difficult having to rely on others to do the implementation. Only having two real coders meant that sometimes the sound got pushed down the priority list. Which is understandable. But it was frustrating when sounds had been in the drive for days/weeks had still hadn’t been implemented. If I were to do things differently, I would do the implementation myself and probably use WWise.
Overall
Everyone on the team had distinct roles and skills, so assigning tasks was straightforward. Due to conflicting schedules and for convenience, we held biweekly meetings over discord to discuss our progress and next steps. This worked out well in order to keep people updated. It would have been ideal to host meetings in person, so we could bounce ideas off of each other.
We communicated important events and reminders through group chat and then moved further discussions and links on a discord server. Hence, tasks were also put on the discord channel. However deep in game development, it was harder to keep track of what was going on. So we moved everyone’s tasks on a google doc and prioritized which ones needed to get completed.
Since both of our programmers are relatively new to Unity and multiplayer, it took a while to get a working prototype. We spent a lot of time implementing assets and making sure the game didn’t break. So we wished there was more time for us to focus on how to make the game more fun and enjoyable.