Development Blog

Week thirteen update:

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.

Week twelve update:

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.

Week eleven update:

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.

Audio can be found in a zipped file here.

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.

Week ten update:

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 update:

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:

1. UI Improvement
2. Adding friction to blocks
3. 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).
4. Lessening the difficulty of platforming
5. Creating consistency on emitter intervals
6. 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.

Week six update:

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.

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?