Week 03
This week as Quarter walkarounds loomed over our heads, we discussed a more concrete gameplan for the rest of the semester. We are in an incredibly unique position this semester because we have game systems ready to go from last semester. Though there is no formal “game” yet, we can see one starting to come together from the prototype the previous semester left us.
A meeting at the beginning of the week with Chris was a helpful reminder to follow the fun. We got a bit more insight into how tricky publishing to Steam will be. We were also advised to ask around the ETC and at Schell Games for further advice on this topic. When we mentioned that we wanted 1 complete hour of gameplay for our final product, Chris did not hesitate. He encouraged us to keep following the fun regardless and told us to keep that hour in the back of our mind throughout our development process.
In our weekly meeting with both Chris and Tom, we explained that we were hesitant about a few of the high-level design and technical documentation decisions. Everything is very big and we fear the scope of this project. They both encouraged us to avoid solving any problems before building it. And though the document may not seem doable or necessarily “fun” yet, we cannot strike anything out until we have developed and played it for ourselves. We were encouraged to start thinking about the rhythmic “spinning plates” of the game’s systems and to begin building said systems.
Following our weekly meeting, we discussed Art and Fortress design. The goal of the discussion was to narrow the scope of assets required. We decided on fewer, but more dense building upgrades. This will allow the artists to show more detail with fewer types of buildings.
The second half of the week had us developing some important assets for the game. Hongzhu and Varun developed a game manager with both win and lose conditions. The state machine is being developed in Playmaker so Julian can iterate more quickly as the weeks go on. They also developed a level manager which lets Unity switch between a “Start” scene, a “Level” scene (where all gameplay will take place), and a scene which will loop the player back to start. Varun also separated pathfinding logic from the map class. Before Varun did this, we were not able to send two characters to do different things. After Varun’s new logic was written, multiple characters can do different things across the map. Hongzhu began researching a new notification system for the game, since players may need more consistent reminders of the events happening throughout gameplay.
On the art asset side, Healthy was able to finish the Fortress’ legs and textures. She’ll now help Keran develop the Fortress’ central core design and decide how it connects to its attachments.
Initial Legs 
Upgrade 01
Keran spent the week cleaning up and UVing the previous semester’s central core room. This cleanup phase is necessary because the current models have too many polygons and are slowing down our builds.
By the end of the week, we had a fully playable game with a top-level manager, a win and lose state, basic gameplay loops, and the ability for Unity to cycle between the different scenes. In the video below, you can see our systems coming together. Our win condition is simply to reach the end of the map before your survivors starve (this is why the game loops back to the load screen).
On to preparing for Quarter walkarounds with ETC faculty!