Team Summary:
For this week, we had to focus on creating our first playable and to record playtesting feedback (both internal and external) and improve our game mechanics based on these feedbacks. Maintaining from last week, our team of four is divided in half where two (Fahad and Eva) people are designated programmers and the other two (Averi and Me) are designated asset creators. Although both Fahad and Eva are programmers, Eva was the lead programmer and Fahad assisted in the code and handled the QA Testing and updated GDD document. Because there were too many assets to create, Averi handled the environment assets and the updated GDD document, and I focused on character, monster, object assets.
My Contribution:
Although I am the lead asset creator, due to the time constraint Averi helped me by creating the environments and landscape assets. I helped design the environments, point out details, and create the level design for the river map. My main contribution for this week is to solely create character, monster, object, and shell menu assets. For the character assets, Solis had multiple positions sprites such as: climb, cloak (crying), cloak (not crying), death, idle (used as walking as well), jump, pick-up and throw. Moreover, Solis also has a sprite where he interactively hides into a tree. Eventually these will be separate folders rather than PNG’s, in which each stance folder will contain animation sprites. The monster assets relied on the environment assets. The windmill monster is drawn into the environmental file, whereas the Screamer, large Watcher and Latcher in the river map are separate assets but they were drawn on the environment to be scaled correctly. The Watchers and Screamers have laser assets that detect or hurt Solis. All the monsters (except for the windmill monster), have two sprite conditions: Screamer has a non-scream and screaming sprite, Large Watcher has a sleeping and awake sprites, Latcher has underground and chasing sprites. There is currently one object asset, the pebble asset, which is planned to be thrown by Solis as a distracting mechanism for the monsters but this mechanic is not implemented in the current playable because it is a secondary mechanic. Finally, the shell menu assets are the: main menu, game over, journal menu, 8 prologue journal pages (this adds narrative context for the player), and 3-Solis-drawn sketches of the monster information. The game over menu is not implemented because the current playable has infinite lives. Additionally, I provided a quick feedback on the earliest playable version of our game, which was prior to the external playtesting.
My Reflection:
Overall, the team was quite productive this week. Fahad initialized the code with movement for a placeholder asset and began working in BitBucket; while Eva further improved the code, and added the monster, stealth and map navigation mechanics and implemented the assets. Averi increased our asset productivity by digitally painting all environments, while I focused on creating the foreground assets. Because of busy of varying schedules, Fahad, Averi and Eva did the playtesting, while Fahad and Averi focused on the QA testing and document. It was a nice workflow.
However, one of the major issues is BitBucket and how it seems to be not working properly. Another issue was the lack of time to create assets. One of my biggest worries was that creating these low-fidelity and non-animated assets already took too much time, and we may run out of time to implement proper animations and high-fidelity assets in the final revision of our game. Also, figuring out the logic and syntax for the code can be too challenging and it takes time to figure out the bugs. An example of this is the throwing mechanic, we could not implement it because we ran out of time for this first playable.
To solve the BitBucket issue, we need to restart the branches of code and try to test it before beginning to use it and see if it works properly. To solve the high-fidelity and animated assets, I need to begin making assets when I have time, however this can be an issue with my current schedule. Because Averi wants to help make the environment assets, this will improve the asset-making process. In the worst-case scenario, we may have to reduce the number of frames for each animation, because we should focus more on refining our game mechanic and making it more fun for our audience than making it beautiful. For the programming issue, we may have to work around problems that our coders cannot figure out and adapt our game mechanic to the issues; an example of this is a simplifying a hard mechanic or in its worse case scenario, replacing or discarding the hard mechanic.
Images:
