Month: March 2018

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.