In week thirteen we’ve focused on getting our build ready for soft opening. Early in the week we drove out to Elizabeth Forward High School for a playtesting session with the students in the game creation class and beginner programming class. These students were a mix of genders and ages, with varying experience in playing games. We tested our most recent build with the new environment, updated UI, and narrative/tutorial VO. Our survey can be found here.
Following this playtesting session, we’ve worked on polishing the build, showing to faculty for feedback on soft opening presentations. Most of this focus has been on improving ease of usability so students will be able to focus on learning the puzzles and concepts behind them rather than how to use/navigate the game.
This weekend and upcoming week, we plan to re-record the voiceover, adding in narrative. In addition to this, we are finishing up the final version of the UI, and tweaking some of the puzzles that presented problems during playtests.
In week twelve, we’ve refined our approach to our final product. We’ve decided to back off from the previous decision of “open world,” after a few meetings where we realized that in all this discussion what we’re really aiming for is to give the player a sense of progression, with some meaningful choice in the puzzles they solve.
We’ve maintained the idea of giving players modules as they progress, but have vastly simplified the environment and as an extension, taken a lot of stress off of our art and design decisions to be made.
In this model, we’ve returned to a somewhat linear scheme, with challenge puzzles, which are harder than the main progression. These challenge puzzles can be skipped – but they will be given a completion score to judge their progress in learning how to use the modules/solve puzzles. In addition to this, it gives the player the opportunity to replay the game and experience challenge puzzles they might have passed over the first time through.
This week, we’ve also been preparing our final build, getting it to a playable point where we can test it at Elizabeth ISD on April 17th for our final testing session.
This week Team Parallel has been working on ironing out some of the remaining kinks in our open world design – particularly the player’s progression through the space and providing them with a sense of freedom without putting too much strain on our team and over-scoping.
With regards to progression, we’ve taken a step back from the overall map, and taken a good look at the order we want the players to learn code modules.
We will be able to use this chart to develop the environment and arrangement of puzzles – helping inform our design. In addition to this, we’ve been working on reducing the scope of our world; originally we’d planned to include 24 puzzles on top of the larger final puzzle, but we have been working on scoping down to around 16 puzzles, merging some of the already done work into the final puzzle and shrinking the environment work.
Another update we have this week is part of the sound assets for the tutorial, and we have been making headway on some of the companion dialogue for the game. We chose to use a text to speech program for the AI, as we feel that it reflects it’s character and it’s easy for us to add/remove voice lines in the game.
Moving forward, we’re gearing up to test our whiteboxed puzzles and updated UI this Saturday, April 7th. We have a great opportunity here to work with students in the 13-18 age range, and there will be a lot of room to get feedback throughout the day.
The past few weeks, the team has been traveling, both for spring break and to San Francisco to attend GDC – thus, work has been inconsistent up till week 10.
Across weeks 8 and 9, we spent time preparing for the ETC halves presentations (internal mid semester presentations). If interested, our halves slides can be found here.
Moving on from halves, and our feedback from fellow students and ETC faculty, we’ve planned a road map for the second half of the semester – mainly what our final deliverable should look like, and what sorts of testing goals we should strive to meet. This week, we have begun designing the larger world for the game, and drafting how we would arrange the puzzles in that world. The filled in dots represent hard gates where the player is expected to learn how to use a new module in order to progress. In addition to this, the solid lines represent paths that the player can take – dotted lines represent one-way paths for the player. We believe this format will allow for more of a feeling of exploration for the players.
A more detailed spreadsheet of how we imagine the levels to progress can be found here.
From there, we’ve made decisions to improve our UI – both making it more readable for naive users, and more intuitive to use. In addition to this, we have decided to edit the visual representation of buttons in order to make them feel more clickable, and display more clear information about what modules do, editing those parameters.
Our next testing goal to hit is on April 7th, in which we will be playtesting the game with students from local middle and high schools. It’s likely that we might not be able to get the UI refined to the point where we would like it for that session, but we will be aiming to get the new puzzle arrangement and world implemented for it.
Week seven of our project was spent following our roadmap for halves presentations (and our next playable version of the game). Following the compiled feedback and our proposed solutions, we ranked tasks by order of importance for this week:
UI Improvement
Adding friction to blocks
Visual and auditory feedback on actions: Interactable objects, stepping on checkpoints, energy bar, and tutorial dialogue (at the very least in text form that a playtest proctor can read out loud).
Lessening the difficulty of platforming
Creating consistency on emitter intervals
Adding camera movement while in edit mode
The majority of these tasks work in service of making the game easier to play and more streamlined so players can more easily focus on the game rather than getting used to the interface with which to play it: we got a lot of positive feedback on the concepts, but were warned that the game was a bit tedious and punishing to play.
Keeping this feedback in mind, we also brainstormed some ideas on simplifying the puzzles by limiting the parameters and providing extra reference for movement/rules of interaction to the player. At the core of this new idea, we thought about restricting the movement and rotation of objects to planes – at least to teach players about the sorts of spatial thinking that our game would utilize, and how that mapped to computational thinking.
These are early stage ideas we’ve taken into consideration for the design of our puzzles, and we will most likely be investigating these further after halves. In the meantime, Team Parallel has been working fairly well considering the time we will have off for the next couple of weeks; we feel adequately prepared moving closer to the deadline for halves at the ETC.
This week we focused our efforts into finishing up our first testable prototypes, then getting them in front of people to playtest.
Our first round of playtests was an internal session, getting other ETC students to play through our puzzle progressions and give us feedback on what they thought needed improving. Although not our target audience, we got good responses from other students who have experience in UI design, game design, and programming. The full working feedback document can be found here. Some of the standout comments we got though, were:
Control for applying the loop is inconvenient.
There should be a delete button for individual commands.
There should be some sort of reward from finishing a puzzle.
There should be a way to measure depth – how do we make the units a block will move, something apparent to the player?
With these major comments in mind, we began brainstorming solutions (red text in the document) that we would be able to implement before spring break on the 10th.
(Tutorial progression)
Our second round of playtesting took place at the ALICE Bootcamp on March 3rd. This was an event at the Carnegie Library in East Liberty (Pittsburgh), that introduces students of all ages to the ALICE software and help them begin to develop their own games on the platform. We had the opportunity to sit down with some students, ages ranging from 5 to 16, and get their thoughts on our prototype so far.
(Demo progression)
Many of the comments we got from the students, were consistent with what we heard from our ETC classmates. However, in addition to those, we also began to realize that our platforming segments, and the price for replaying puzzles was incredibly punishing (re-inputting commands, and getting reset to checkpoints after failing platforming segments doesn’t encourage players to keep going).
Moving forward, we compiled all of this feedback in order to most efficiently work for the final week before spring break and GDC week.
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:
The player can jump. One block high, and two blocks far.
Player cannot program a block that has already been programmed (unless they reset the puzzle).
Player can ride on blocks.
Modules are restricted by energy.
Move costs energy based on the arguments – 1 unit = 1 energy.
Energy is based from puzzle to puzzle.
No gravity for blocks and energy balls.
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.
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?
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.
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.”
