First week back! This week I led the discussion on big refactoring changes that need to be made before we begin full production. The big decisions we made were that we will move to a Mech vs Mech game, moving the map to reside within the actual fighting Mech model, and redesigning the Mech interior. Mech vs Mech will hopefully help us remove production costs because we no longer have to design monsters. On the other hand, we believe placing the map inside the Mech model will greatly help us keep the player immersed. Additionally, we will no longer have to "fake" Mech movement because it will actually be happening. Lastly, we split the core into two parts (Core and Medbay) to make the space feel less empty. We are also redesigning the arms because of navigation issues with them.
This week we got to really implementing the changes we spoke about last week. We also are getting a Cockpit room underway. For this room, I added functionality for a pilot seat that the player must walk into to enter the pilot view. Another change we decided on was focusing on a player vs player type of game. This would have two teams operating their own mech to fight each other. The required me to redesign the play to be interesting in a pvp environment. To solve this I designed a "heat" system that speeds up your battery charge time based on the actions of the pilot. Additionally, Keira, Walid, and I worked on a "desired final product" that we can turn into a timeline on Thursday.
This is week we began our timeline for the quarter. Unfortunately that timeline is VERY tentative because many task require others to be done before them. I have also begun reworking the GDD to fit all the changes we made to the game. Ultimately, we are in a bit of a paralysis on the design side until our implementation changes are finished. I don't expect this to be an issue though, and I somewhat accounted for delays from the sheer amount of the game that we reworked.
More or less this week has just been an extension of last week. Mostly working on documentation while implementation catches up. Unfortunately I have been pretty disconnected from the unity build because of issues we are having with Perforce, but I believe those are being solved as I write this. I worked a little with Justin to get the bare bones implementation of our Mid-game progression system. Luckily, we were able to cook up an implementation that didn't conflict with the existing parameters screen. My goal is to have that completed next week so we can have that in the playtest build.
My contributions in week 1 began with pitching the original concept for the "Mech Game". After the team chose to adopt the idea, the rest of my week was spent conceptualizing and building the gameplay cycle for the player. Most of this involved long meetings, where I answered questions from the team and address their concerns. When present new mechanics and solutions, I used my background in programming to make sure all of my suggestions were not only interesting and fun, but practical and "Tech Team Friendly".
I also created some visuals of concept designs:
My week 2 contributions began directly after class on Monday. Me along with a group of my fellow team members completely rebuilt the mech combat, and heavily reworked the engineer's resource management system. The main change with mech combat is that we settled on a system in which everything works synchronously. The main difference between the inside and the outside of the mech is that the fight outside the mech is executing at an extremely slow speed. I met with a couple group members on Wednesday to record a LARP of the combat, which seemed to go well. As for the inside of the mech, we consolidated all of the different resources we discussed into the "power" resource. Everything currently designed for the mech only consumes power to function. We hope this will simplify the game inside the mech to give us more freedom with adding more systems.
This week we did a much more expansive version of the LARP we did last week. In this LARP, we had 3 engineers and systems for the arms and med bay. This LARP was VERY eye opening for me. The biggest result I felt was that I now know that the game is fun! We just need to lean into what made it fun for our implementation. The most important aspect of the game for me was the importance of entering dangerous areas of the mech, and trying to coordinate with the pilot to not die while trying to replace batteries or do a repair. If we can implement in a way that brings out that strength, I believe we will have a great game on our hands.
This week most of what I had planned to work on is currently waiting on the bottleneck of getting a playable build of the game. Regardless, I still worked on refactoring some of our systems in response to our epiphanies from the LARP. The first was redesigning the power system to work around a 1 charge per cell system, as we found the simplicity was enjoyable in the LARP. I also made note that when designing the level, we should put the BattPacks (see GDD) in the hands of the mech because that challenge/danger proved very fun in the LARP. Additionally, I created functions for scoring that will be implemented into the game as soon as there is a united build between mech and engineer play.
This week I spent my time working on the GDD. I was trying to move it more towards being a vision document rather than an info dump. To support this I put more art throughout the GDD and added some more "sell" oriented information so that someone new could get an idea of what are goals are for this game with out having to ask too many questions. I also gutted some parts of the GDD, removing information that either doesn't apply anymore or is no longer in our scope.
This week I participated in meetings to discuss the greater map design we want for the mech. The goal is to have it be easy to navigate when there's no time limit, but chaotic when there's a time crunch. To do this we finalized that we want the chest area of the mech to be a huge cylindrical chamber that the player can swing around and parkour in. This will allow for a high skill ceiling and give players who love "movement tech" to discover best strategies in our game out of necessity.
This week we worked out in lab some solutions to common issues we were facing. For the rest of the week I continued to review documentation and make some changes to that as well as our sell presentation. We are in a bit of a production/documentation depression at the moment, but hopefully we can refactor some of our team organization this week in class to get ourselves back on track!
This week I can't say I was as productive as I would've liked to be. We are trying to get our bearings with some unexpected organizational changes. Communication is suffering so it's hard to know whether tasks are done for me to mark in the documentation we have. Regardless, I updated the GDD to have some more specific descriptions of what are game needs to include.
This week began with us restructuring our team organization in lab and consolidating where we store our information. The Asset Manager was completely revamped, and we separated tasks that are more urgent from the greater list so that we can stay on top of them. We really hit the ground running after that. We had an alpha demo ready by Saturday, which I was able to have someone playtest on Sunday. The first playtest revealed some very interesting info and really helped me see the way our game is received with as little entry info as possible.
I spent most of this week creating and outline for a completely revamped GDD. Our previous GDD was outdated and not very robust. I thought it would be easier to rewrite the whole thing rather than trying to edit one with a shaky foundation. It looks like its gonna be a huge undertaking but I think the Diefenbuck return for the team will make it worth the time.
This week I wrote the new GDD. It took a lot of time and effort especially because I was sick while trying to work on it. There are many more improvements that could be made on it but I think that this is as good as it is going to be for now. I think when we return after break it will be worth while to refactor it but I think it needs to be left to stand for a bit.