Boil it down.

With our concept pinned, we are rushed our prototype for the coming playtest session. Sure, bulk of the work relied on Ben and Keyin to get a playable prototype for us to test the viability of our concept, especially one that we have spent a week or more on conceptualising, so they had a lot on their back to make this happen, because we can't risk more time on changing the core game. 

The prototyping didn't completely go as intended for us to playtest before 7th August, we haven't got the rolling motion of the eye ball to work - "not yet" was the response I received from my programmers. Well perhaps it should be the least of problems we should worry about, because after all it is just a mechanic that forces the players to use both eyes instead of one. 

Also, remember what I mentioned in the previous devlog? "The player has to navigate a lab room where their final goal is to place themselves (the eyeballs) back into a patient laying on the bench." Sounds familiar? Sounds like a version of escape room right? Well escape room + janky physics + being tiny might be too much fun to have in one game that will ultimately backfires, so "nah" was our solution. Our intention was to keep this game "clean" - this term in our collective understanding means "least mechanic for the most fun", and designing many interactive mechanics that the players can explore while using the janky physics + being tiny doesn't align very well. Perhaps, the game will present too much struggle (with the controls) for an already hard objective gameplay of an escape room. Likewise, a non disruptive way to communicate the to the players their final objective, and another to show a checklist of found-clues would be 1) over scoping for a 12 weeks project and 2) require a fair bit of UI elements. This is a no go for a game that relies most of it nostalgia on being tiny; not to mention, the game will be displayed in splitscreen so field of view is already low, so supposedly the player would want to see more of the environment as they explore and not have a screen clustered with information. With that idea now scrapped, our goal for the game is simplified as: exploring a lab room with weird physics from the perspective of two eyeballs.

This helped simplify a lot of the programming and level designing aspect, which allows us to place our focus on a few core mechanics - this might be very limited in terms of evoking dynamic game play, but may be a blessing in disguise, because again we think the players would appreciate fewer of unpolished mechanics (making the game gimmicky?) and more interesting ways of re-utilising the few that they are familiar with. 

With that in mind, I proceed to sketching out the layout of the game, so we can have some visuals of the game (please ignore the writings). I have highlighted the possible elements that can evoke gameplay.

That is the end of this devlog, although I have thought about only using one eye ball. Because the fun of it is not only the strategic use of eyeballs, but perhaps in the exploration of an environment from a tiny perspective, because "too much  challenge is not fun as well?" Perhaps, we will need to playtest this.