Week two update:
This week’s work, we’ve finally been able to dive into work prototyping, and the branding for our team has been coming along nicely. We have all brainstormed individually the mechanics and frameworks we should work within for the game, and come together to discuss on a daily basis.
On Wednesday, Jan 31st, we presented a basic design concept of our game to faculty – an overview of what we wanted to try and achieve for the semester: Design Presentation. This included an outline of how the gameplay interactions would go, our theories on how the map would potentially look like, and the educational methods (and how effective they would be).
Since then, we have worked on enhancing specific ideas and looking at possible design constraints. One of the things we realized quickly is that in order to teach coding, we needed to begin to break down the topics we wanted to teach into tiers:
- Level 1: things that can be manipulated through code, “block.obj” or other asset types.
- Level 2: simple commands that can be used to manipulate level 1. Transform, rotate, scale, etc. would be included in this level.
- Level 3: more complex operations that can be added on top of the commands in level 2. Things in this level could be loops, if statements, things that can potentially automate parts of environment manipulation.
In addition to this, we took a good look at the gameplay interaction that the player would go through in manipulating their environment – how would the player character use their PDA, what sort of UI would pop up? What button presses would be involved in applying code modules or selecting objects in an environment to be changed? We settled on an interaction flow that cycles between three modes. Players would use WASD and mouse to move around in the environment. When they find an object they want to manipulate, they would press “T” to bring up the selection screen, aiming and clicking on the highlighted object. From there, the editing UI would come up, and players would be able to make changes with their code module abilities, hitting enter or a submit button to return to the movement mode of gameplay.
Taking these design ideas, we have started moving forward with a prototype to show for quarters on Feb 6th, working to implement a simple puzzle that requires the use of a rotation command, and move command, as well as a good example of how we envision the player interaction through the aforementioned “modes.”