Month: February 2018

Week five update:

In this fifth week of the project semester, we have been working towards getting a good progression of puzzles to begin playtesting with our core audience.

Admittedly, we ran into a few bumps along the way this week – the biggest of which was issues in the specificity of our design rules. So moving forward, we’ve written down in more detail the rules we expect to work under in designing our puzzles:

1. The player can jump. One block high, and two blocks far.
2. Player cannot program a block that has already been programmed (unless they reset the puzzle).
3. Player can ride on blocks.
4. Modules are restricted by energy.
5. Move costs energy based on the arguments – 1 unit = 1 energy.
6. Energy is based from puzzle to puzzle.
7. No gravity for blocks and energy balls.
8. Reset will set the puzzle and the player back at the beginning positions.

To go more in depth on these rules, we also worked out the specifics of the design constraints in a stand alone document.

On Thursday, Feb 22nd, we were able to get a prototype of the game that had updated UI, as well as a progression of a few puzzles. The art/environment is not in yet, but for now we wanted to see how the prototype would play like, and got it to a level of whiteboxing where we can test it.

Proceeding from here, we’ve reached out to ETC connections both internally and externally (drawing from near by schools and students who are interested in playtesting for us), to begin to put the puzzles in front of people and hopefully help us answer a lot of our design questions.

Week four update:

This week we have focused on hitting our next milestone for the client meeting on Tuesday, Feb 20th. We have been full steam ahead, working on three more puzzle designs to begin playtesting, and to show to our client.

On Friday, Feb, 16th, we had our quarters walkarounds, introducing the faculty at the Entertainment Technology Center to what we’re doing, and how we’ve chosen to approach our project challenge so far. For quarters, we aimed to produce a simple prototype, building off of the last one in order to show how the five verbs we have so far would be applied in game. For Level 2 verbs, we have Move, Rotate, Wait, Destroy – which are commands applied directly to the object in game. The one Level 3 verb we are working with right now, is Loop, which can be applied to multiple Level 2 commands.

In addition to this, we discussed potential for increased complexity in our puzzles, layering the idea of moving forward from puzzles requiring the player’s movement from point A to point B. Our most recent idea on this has been the idea of creating Balls and Probes (balls and goals). These provide another puzzle system that now asks the player to become more engaged in the system – manipulating objects for a different goal rather than personal transportation.

Moving forward, we intend to refine the puzzle in prototype 3, and implement at least two more puzzles of lesser difficulty to illustrate how the game’s progression would work. To further this, we plan to playtest our puzzles – specifically with the demographic in mind, to fine tune our puzzles, and to see if our game is actually playable by non-programming teenagers.

To round out the week, we also have a variety of questions we’ll be asking ourselves;

• Are we emphasizing the educational aspect, or are we emphasizing the inspirational/fun aspect of our game?
• Is it possible to schedule client meetings on a weekly basis, instead of bi-weekly to shrink the feedback loop?
• Finally, how does our game fit in the overall larger framework that E-Line is working on?

Week three update:

This week we’ve spent a lot of time working on putting out a working prototype of our ideas. We built off the frameworks we came up with last week, and have worked from our prototype to develop our goals for our next milestone in two weeks.

On Tuesday, Feb 6th, we presented our first prototype to our client, Alan Gershenfeld at E-Line Media – showing our design brief and quick footage of our initial prototype. Our goal with this prototype was as a proof of concept showing that our mechanics could work in a simple environment, as well as being able to show what direction we wanted to potentially take our game in.

Alan was fairly satisfied with our work thus far, and encouraged us to keep exploring this avenue of gameplay. We discussed the very real issues of scope for the project; how we could extend the gameplay through the design of puzzles, using assets from the Unity Asset store if they could save us time on production work. In addition to this, we were encouraged to flesh out the story and worldbuilding to give the player character an interesting motivation to explore and traverse our world.

Thus, we have decided to move forward in the level design by creating tools for the designers – Zacks is primarily working on this to be done by Feb 10th, and from the 10th onward, the process gets handed off to our designers Yuqiao and Erhan and, artist Siyu to work on three more levels involving a few more verbs (level 2 and level 3 operations), as well a first pass at UI, which will be primarily overseen/implemented by Longyi and Zacks.

In parallel with this effort, Erhan and Omar will be working on creating a basic outline of our narrative – what is the player character’s motivations, how can we engage the player using the narrative, what are they discovering, how do the code modules fit organically into the world? For this, we’re drawing a lot of inspiration from games like Everybody’s Gone to the Rapture, and Valley, in their storytelling styles.

Finally, now that we’re all confident on the direction we’re going with Parallel, we are also prepping to be able to show off our work on the second milestone for Quarters presentations. We have been very careful and deliberate in keeping our sketches and designs around in order to properly document the working process and bring faculty new to the project up to speed.

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.”