This week, the Interactive Academy team dove deeper into Chapter 2 development while analyzing the data from the recent Chapter 1 playtest.
With the designers working together to optimize the Texture Editor mechanic and UI, the programmers continued to divide and conquer on the core functionality of Chapter 2 (applying textures, changing textures, editing textures). To this end, new prototypes were made and subsequently amplified as we all learned more about what and how this was.
First, a color-changing prototype was created with an integrated hex code display. This saw the user choosing a color and clicking on a placeholder icon. When that icon was clicked, the selected color became a part of the icon. The icon can now be dragged from the Inventory and on to an object where it would imbue the object with the aforementioned color.
This prototype was combined with the skew shader discussed in Week 9 to observe how both aspects functioned togther:
And finally, the prototype was amplified further by testing how primary and secondary color functionality would look on a placeholder texture:
With so many successful tests and prototypes, it is time to start getting into the details. The next steps would be gathering patterns to act as textures that would work optimally for these kinds of color editors while also keeping an eye on variety. Some current pattern ideas include standard ones such as stripes and spots, but others like fractals and waveforms are the more ambitious of the bunch.
With the inside of the Gallery in a solid place, it was time to turn the attention to the Gallery exterior and the world around it. This was a daunting task for a plethora of reasons. First, what would an environment look like inside this digital world? Second, how can it be unique enough yet also understandable? Finally, can we balance the amount of details so the world details don’t get in the way of the player’s creative pursuits?
We continued where we initially thought: a grounded natural environment.
While this provided easy-to-understand landmarks and objects to customize (ie. the player would know they are changing the sky, trees, mountains, etc.) the world-building details were off. It wasn’t exuding “digitalness” enough. Meetings were had between designers and artists, and more iterations occurred:
As we can see, the digital nature of the world is brought to the forefront while still appealing to natural elements. The trees lose their evergreen feel to evoke more of a pixel / voxel aesthetic, while the broken ground echoes some of the “breaking” of the world while also utilizing pentagons and hexagons for that much-needed digitalness. Finally, clouds break up the vastness of the sky and the mountains became more rough and rugged. This last detail is important since those contours and shadows should be able to come through even with a texture applied, ultimately allowing for player freedom of expression without compromising the tactile nature of the object.
While all of this was happening simultaneously, the designers collaborated on how best to design the Texture Editor for ease of use, range of customization, and inclusion of concepts linking art to tech.
With this design, we not only were able to hit on all of the above aspects but also establish a hierarchy and flow between steps.
Section 1 has the player choose if they wish to change the primary color or the secondary color of the Texture. Section 2 showcases the hex code selector. By clicking up/down arrows players can change the value of each bit within the range from 0~F. Any change of the 6-digit hex value will change the color selected in Section 1 as well as Section 4 (the texture display) in real-time, and the connection is visualized by three wires connecting the color block and hex code and representing the R,G,B values respectively. For example, in the mock-up above the secondary color slot is selected with the hex code input of “00FFFF”. The wires point to the color block on the right because we choose the secondary color. The color block is displayed as cyan[#00FFFF]. The wire coming out of R section is black because the first two hex digits are 00. G wire is green because the middle two hex digits are FF. B wire is blue because the last two digits are FF. In this way, we’re able to highlight a real-world application and bridge between the art world and the tech world.
However, without knowledge of hex codes, this functionality is useless. That is where Section 3, the color picker area, comes into play. This color picker serves as an encyclopedia where players can look up the hex code for a specific color they want. The rainbow-like bar on the right is the hue bar, and the spectrum on the left is for saturation and brightness. Every time the player clicks and pick a certain color, a speech bubble pops up and shows the hex value of the color. Unlike traditional editing software such as Paint or Photoshop, choosing a color here does not affect Sections 1 or 4 at all. As explained, it is merely a “visual hex code wiki” and requires players to manually input the hex code of the color they wish. Our goal for this functionality is to push this art-tech bridge even further and reinforce it through the player’s interaction of actively inputting the values themselves.
Chapter 1 Playtesting
We were very fortunate to playtest Chapter 1 again with a different group of 15 12-13-year-olds from a 7th-grade class. In short, the results showed that Chapter 1 is indeed going in a solid direction given our goals, but some changes could be made to bring it to the next level.
Since one of our biggest goals is to get children more interested in STEAM, we want to see how their perception changes due to their interaction with our experience. As such, we ask a number of questions before they play as well as afterward. Since Chapter 1 revolves around coding and programming, we asked about the student’s interest in this subject as well as their perception:
While this class seemed to have an elevated interest in coding/programming, the bell curve shifted to express a general increase in interest of 14%.
It was interesting to see how the student’s perception of the difficulty of actual coding changed. While the bell curve flattens out and there is an increase of students’ opinions on both the “easier” side and the “harder” side of the curve, the average perception showed an overall decrease in difficulty by 2%.
Puzzle engagement remained relatively high, with students enjoying finding the pieces in the room, solving the coding-relating puzzles, and chatting with Brad at the end. The difficulty of the puzzles still leans on the harder side, and we believe this is due to Puzzle 3, since our last playtest (without Puzzle 3) yielded an average of 4 out of 7 for difficulty, this playtest saw that number rise slightly to 4.3. While we did have a hint system in place, the puzzle itself could still be too difficult and changing the hints is merely a band-aid on the problem.
To this end, we also asked students about this hint system. It appears that not only did students notice these hints, but they utilized them as well to help solve the puzzle. Combined with the data above, we can infer that Puzzle 3 is still too difficult and needs some edits to get it in a better place.
It was great to have the team come together in even stronger ways as Chapter 2 continued development. Compared to our process a little over a month ago, it is clear that we’ve come a long way. With this continued drive and vision, we are extremely confident that Chapter 2 will see progressive leaps while Chapter 1 keeps on getting the love it deserves to make it as good as can be.