Week 7 Update


This week, we focused on getting at least one iteration of a day in the game done to present as a working prototype. Also this is really late, sorry it’s completely my fault.



This week, programmers worked on getting the main game logic working with regards to buying ingredients, selling product, and assigning tasks to the employees. Unfortunately, programming wasn’t able to implement employee interaction and a lot of the logic isn’t obvious because of the lack of UI elements to represent it.



Art worked on finalizing the design of the bakery, with the assumption that it would present most playable features within one screen. The game would function on the basis of diegetic UI: to assign an employee to sales, the player would have to click on the cash register. This sort of environmental interaction would increase player engagement.

Additionally, two new characters and the outside map had been created for the purpose of the prototype demo.


Prototype Build

The working prototype that we created allowed players to go through the first shift of a day. On the first screen, players would choose two of three employees to work for the day. After that, they would choose what tasks the employees would be doing for that shift, such as taking orders or making bread. When each employee has been set up, the screen transitions to the store screen where a timer starts to count down to the end of the shift. On that screen, players can also click on the door to receive deliveries and when they do so, they lose money as they buy more supplies. While the prototype has a few bugs and does not necessarily reflect the timeline we want the game to have yet, it shows that the features we want to implement in the game are possible. Playing the game on a phone, the team realized that the placement of some of the UI elements was strange and that some of the art assets needed to be polished. Furthermore,

The diegetic UI was found to be too confusing.


Studio Mar: Week 8 Update

This week, we discussed the feedback we received from last week’s prototype and experimented with possible solutions to the origin marker tracking problem. We also continued working on palette/UI concepts and multiplayer support.


After our presentation, Tom suggested that we consider making our game part of an installation, rather than a print-out-and-play-anywhere game like we’d been thinking about. Creating a dedicated playspace might help circumvent some of the technology limitations, and facilitate the fun of the game–playing Charades with, as Tom put it, virtual props. Adrienne and Anna are particularly excited about the art and gameplay possibilities of an installation, and Adrienne is happy to volunteer her studio for an installation.

Right now, our version of the game mainly has problems with the origin marker, which is small and placed on a tabletop. Because of that, the headset has to be very close to the marker and constantly keep it in view to keep tracking 3D space, which makes the player have to awkwardly bend over the tabletop for the 3D drawing to work. The solutions to this problem that we’ve tried are better suited for an installation than a tabletop print-out-and-play experience, so we are currently moving toward an installation for our final game.

Marker Updates

origin Wall Marker

We tried putting a large version of the origin marker up on a wall, in this case, on a large TV screen. The larger marker can be tracked from across the room, and can be tracked from most angles relative to it, even when the marker’s in the camera’s peripheral version. The downside to this is that it prevents players from walking all the way around the origin, limiting gameplay to a more stage-like experience: one person standing before the origin marker drawing, and the others arrayed around the origin watching them. We haven’t tested drawing with the big wall origin marker yet, but we’re optimistic about its capabilities.

Extended Tracking

We also tried Vuforia’s Extended Tracking, which was surprisingly easy to implement, and works fairly well. The caveat is that the surroundings can’t change too much or else Vuforia can’t track where you are relative to the origin. It works best with a very flat, similar background. For example, if you draw something over the origin marker on a tabletop, look away to a different part of the tabletop, and then return to your original drawing, it’s still there. Drawing something with the origin marker not in view is a little more finicky, as without anything to anchor it to, the drawing can jump around in space.

We plan to keep trying different origin marker methods, like a big marker on the floor or a big 3D marker in the middle of the room, or pairing extended tracking with one of these different origin markers.

Paintbrush marker

Vuforia’s cube tracking seems to work reliably, albeit a bit jittery when it tracks from face to face, and it stops tracking if your fingers are blocking too much of the cube face. We plan to test a “cube on a stick” paintbrush to see if not having fingers blocking improves tracking, and if it’s a viable paintbrush option. We’re also going to test Vuforia’s cylinder tracking, to see if that produces any better or similar results to a cube, because we think a “cylinder on a stick” will at least look nicer than a cube.

We have a Google Daydream controller but haven’t gotten the chance to test how it works with Unity. Our hope is that if it works well with Unity and our game build, we can mount our paintbrush marker, cube or otherwise, on top and use the controller’s buttons for things like turning drawing on and off and selecting options from the palette.

Other updates

Palette Designs

Adrienne sketched some palette and UI design concepts. The main palette concept uses a 2D marker that looks like a blank palette, but when viewed in AR, the blank spaces for colors and other options “pop out” in 3D and color for the player to interact with. She also came up with a list of UI elements we need to include, either in the palette or elsewhere in the UI (for example, on the walls of an installation), as well as some sketches of how they might appear: a color wheel, brush size slider, brush type/texture options, and an undo butotn.


Everi has continued working on adding multiplayer to the game, and it’s mostly working except for a problematic bug. She’s going to continue tackling the bug, with the goal of having multiplayer working by the end of the next work week.

Next Steps

This week is CMU’s Spring Break, which means it’s not a work week for Studio Mar! If anyone has the time and inclination to work on the game, we’re going to keep working on what we’ve been working on this week. Our goal for the end of the next work week, March 23rd, is to have an Alpha version of our game. The Alpha should include:

  • Final origin marker
    • Supports using physical space for drawings
  • Multiplayer support
  • Drawing with our final paintbrush marker
    • A 3D marker mounted on a controller, not a 2D piece of paper
  • Basic UI
    • Let user make multiple strokes, undo, start/exit game

To that end, what we’re working on this week and next is:

  • Continuing testing different origin marker solutions
  • Continuing work on multiplayer
  • Testing drawing with different paintbrush markers
  • Integrating the Daydream controller into our Unity project
  • Designing and implementing UI


This post should be updated with video and images of our progress later this week. But after that, we’ll see you on March 23rd! Have a great Spring Break!


Week 7 Update


We have scaffolded all of our different scenes; We have multiple choice scene which Brian has been iterating on and improving, a drag and drop construct your own sentence that Ryan improved on to catch partial correctness such as Sociopragmatic or grammatical errors, which will help give more constructive feedback to players and reduce frustration. Additionally, we have constructed an over-world scene, which the player can navigate using directional keys or WASD, as well as interact with people and strike up conversation.

We’ve also ran into a number of setbacks. One in particular was that upon presenting our checkpoint progress report, a guest industry specialist pointed out that our interactions differ from practice to challenge mode. Before the protagonist of our story set out into the real world, they have an opportunity to practice their Chinese with a buddy bot, providing a stakes free learning environment. The original plan was to have a fun interaction during practice mode like throwing that would help spice up the dull action of selecting multiple choice and help engage  people starting up this game, and remove it later in the game where situational context is more important. However, concerns were raised as to establishing misleading “rules” for the player and giving them false expectations.

As to where we’re going for here, addressing the concern raised above. However, the big focus moving forward will be constructing our database and game manager so that we can start populating our database and resource folders and really streamlining the process of creating scenarios and story before we start making them.


As said last week, we’ve established a more focused and concrete aesthetic of solarpunk rather than cyberpunk. We’ve brought a stronger focus on the Chinese aspects of the environment. We finalized the visual layouts of the game, with the four key views being the Practice View, Challenge View, Conversation View, and Overworld View. Reactions and feedback given by the NPCs who are being questions will involve large talksprites sliding into view with the proper expression for a reaction, to emphasize the feedback being given to the player.

Going forward we will be creating polished art assets that can be used for the upcoming playtestable scenario.

Key Game Views:


This week we will focus on finalizing the prototype so we can move to full production in March. We need to come up with a new idea for the fun interaction during the practice phase. We need to set up “rules” so that the player will experience the same rules through different social scenarios (instead of throwing apples). We also need to build a playable sample of the game so we can start playtesting. By the end of March, we will complete four social scenarios (street, bank, department, fruit vendor) with both practice and challenges phases.

Meanwhile, Xiaofei will communicate with her dissertation committee members about the game plan to make sure that she can use the game for her research study. The goal is to minimize the variables on the interaction and learning experiences in the game and the web-based comparison environment.

Production schedule for March

3/9 Street scenario + storyline
3/16 Department scenario + playtesting
3/23 Bank scenario + playtesting
3/30 Street + Bank + Department + Fruit Vendor

Studio Mar: Week 7 Update

This week, Studio Mar focused on creating a playable demo and revising our production schedule, for the prototype presentation on Friday. We also decided on our game name: LineAR (pronounced “linear”)!

FInal Concept

Our final concept is a mobile augmented reality game for two or more players, that is a combination of Pictionary and Charades. One player gets a prompt like “picture frame” or “pirate,” and has to draw that word in 3D space so that the other player can guess it. The fun of playing this game in AR comes from the ability to use the physical space around you, as well as yourself and other players, when drawing. For example, to illustrate the word “trampoline,” you draw a circle on the ground and then jump up and down on it; for the word “sleeve,” your friend draws a sleeve around their arm. This way, the game becomes a kind of Charades with props that you draw yourself.

Extended features

If we have time, we have a few extended features we’d also like to include:

  • A gallery of saved drawings overlaid on the real world that you can physically walk through
  • Saved drawings are reanimated in the gallery
  • Markers on headsets to track and draw on other players
    • For example, if you get the prompt “pirate”, you could draw a pirate hat and eyepatch on your friend.

Software: Vuforia + Tilt Brush

After exploring all the technology options, we are moving forward with Vuforia and marker tracking for our software. Unity doesn’t support using more than one AR software at a time, so unfortunately we can’t integrate AR Core or any other AR support with Vuforia. We are still exploring Vuforia’s 3D object tracking and extended tracking, to push the limits of what Vuforia supports and allow for the best play experience that uses the whole room.

We are designing and testing Vuforia markers for the origin marker, the point that allows the drawing to be done in 3D, and allows synchronizing across multiple users; the paintbrush marker, which players use to draw; and the palette marker, which players use to select Tilt Brush paint textures and colors. We are moving forward with using the Tilt Brush SDK for players to have different brush options when drawing.


We are continuing to develop for both the Holokit and Google Cardboard, since it is straightforward to make prototypes for both at once. One problem with the Holokit that we discovered during our demo is that the phone camera is placed well above the wearer’s eyes, meaning they have to bend over awkwardly to see something below them that they can see easily without the headset.

Progress update

This week, we:

  • Added adjustable straps to the Cardboard and Holokit headsets, so they can be worn hands-free
  • Developed multiplayer: multiple players viewing the drawing at once
  • Created some palette/non-paintbrush UI design concepts
  • Tested Vuforia’s cube targeting: which works pretty well!
  • Tested the Merge Cube dev kit
  • Made our demo game stereo, so it can be viewed in a headset

We found one major issue with Vuforia’s marker tracking is that it requires the players to keep the origin marker in camera-view at all times, which is awkward, and doesn’t support the use of physical space like we want our game to have. We’ve begun testing potential solutions to the origin marker: a large marker on the wall or the floor, a 3D cylinder or cube marker, and extended tracking.

Diagram of Daydream features, from the blog Above AR.

We also acquired a Google Daydream controller, which we plan on testing to use as a paintbrush controller. We hope that we can use the controller to turn drawing on and off, allowing the user to control drawing multiple strokes, as well as selecting options and increasing brush size. Whichever marker we end up using for the paintbrush would be mounted on top of the controller.

Revised Production Schedule

We updated our production schedule, which is mostly the same as before, but with more consideration for working with markers and UI designs.

Week 8 / Mar 09 Multiplayer [Mid-sem break]
  • Other players can see the drawing live
  • Finalize 3D obj
  • Non-paintbrush UI designs: palette, prompts
  • Origin tracking solutions
  • External playtesting (continuing for rest of sem.)
Week 10 / Mar 23 Alpha
  • Stable release of multiple people taking turns drawing
  • Finalized & working physical paintbrush (marker + controller)
  • Basic UI implemented
Week 11 / Mar 30 Prompts
  • Limited set of prompts for player to base drawings on
  • Refined UI
  • Changing turns supported in-game
Week 12 / Apr 06 Progress presentation due
  • Beta: Stable release of drawing + objectives
  • Prompts integrated into refined UI
Week 13 / Apr 13 Brush options
  • If not yet incorporated, color + line width + animated brushes
  • Full palette support
  • Start work on gallery
Week 15 / Apr 27 Stable release
  • Pre-final: No new features to be added
Week 16 / May 04 Final presentation due
  • Flex week: bug fixes, presentation/final release prep

Next Steps

Our next immediate steps are:

  • Find a better way to track the origin that allows for the use of physical space
  • Decide on a paintbrush marker (hopefully 3D, whether cube, cylinder, or other)
  • Design UI (what we see in virtual space, without relying on markers)
  • Implement multiplayer support
  • Test and implement Daydream controllers
  • Create a bank of Pictionary-style prompts (test which ones work better in AR)

And, as soon as possible, we want to begin external playtesting, to help build our prompt bank and test the game concept.


Thanks for checking in, and keep checking back for more updates on Studio Mar!


Week 6 Update


Multiple-choice Interaction (Bryan)

This week Bryan has been updating and ironing out the multiple-choice setup. The first iteration was a lot of testing different ideas and a lot of messy code. This week was spent to create something neater and more easily utilized for a larger project. So far we have a script that handles multiple multiple-choice questions, keeps track of which answers are correct/incorrect and why, provides unique and appropriate feedback for each answer (through dialogue, currently represented through basically the grossest little green text box imaginable), and has some semblance of the silly physical ramifications we wanted to incorporate into the practice sections.

We were planning to have the “challenge” portion of the game set up alongside this practice section as the next step, but after a group meeting it seems like we might want to spend a bit more time on how the practice scenario handles questions to make it more analogous to the real deal. We want to have the system set up to handle questions exactly the way we want it to before we start creating a second scenario, because any changes made after that will essentially have to be duplicated. It seems we’re setting the real scenario up somewhat differently, which means we have got some course-correcting to do before we set this up in both practice and challenge mode.

Drag-and-drop Interaction (Ryan)

Ryan has been working on how to implement drag and drop responses into our game. Part of our game consists of having Chinese learners create their own responses to questions as a way to be more interactive, so we have been working on a simple word bank and having an answerfield determine which “answer units” have been selected and in which order they are in, which we can use to construct the player’s intended chinese statement and compare it with the given answer.

Additionally, We have been working a bit on integrating SQL with Unity. Since we have a lot of dialogue, a way to effectively store and read lots of dialogue as well as edit and add to it without parsing through the code. As such, we have been looking into SQLite plugins for Unity and C#, and we’ll see if we can get it up and running before the next blog update!

CONCEPT ART (Andrew and Sarah)

We’ve experimented with style and layout and we’ve decided on a couple things: Less cyberpunk, more solarpunk, first person view during conversations instead of third person. Having decided on these points, we’re ready to move forward with designing actual game assets.

Production Schedule

By next Friday (3/2), we will build a full scenario (fruit vendor) consisting of the practice phase and the challenge phase. For art, we will have the background and characters with different facial expressions (upset, confused, awkward faces of the vendor, robot). For programming, we will have multiple-choice questions (positive and negative feedback) and Drag-and-drop (positive and negative feedback) questions.


We will begin playtesting the prototype next week and see what people think about the interactions (multiple-choice and drop-and-drop) as well as the art style. We will move forward with full production in March with the goal of building four social scenarios (Street + Bank + Department + Fruit Vendor) by the end of March.


Studio Mar: Week 6 Update

This week, Studio Mar focused on designing and developing Vuforia markers for use in our game, while continuing work on the headsets and playable prototype.


Sketches of marker design concepts by Adrienne Cassel.

We discussed a few different designs for markers: the origin marker, which represents the center and flat plane of the play space; the palette marker, which allows the player to select brush colors and textures; and the paintbrush marker, which the player uses to draw the line in 3D space.

3D Markers

We tested Vuforia’s 3D Object tracking to see if a 3D marker is a viable option for the origin and paintbrush markers. We want a 3D marker to be accessible by anyone who plays the game, and so looked into objects that could be printed out and put together. Vuforia needs multiple points to recognize a specific object, so a complex 3D printed object works better than a folded paper shape. We are also testing Vuforia’s cube recognition.

We hope that a 3D origin marker will be easier to track as players walk around it, and that a 3D paintbrush marker will support natural drawing in 3D space (by rotating and twisting the marker).

Paintbrush Controllers

We discussed possible solutions to a problem we discovered last week–how to turn the “painting” on or off without changing the paintbrush marker, which would require re-tracking. We came up with two different solutions: a gaze-based on/off button in the virtual UI, and an on/off button on a physical handheld controller. To that end, we hope to acquire some Google Daydream controllers to use with our Pixels, since we believe the handheld controller is a better design solution than the gaze-based UI.

Improved prototype

Last week we were able to start drawing in 3D space using Vuforia and 2D markers. This week we added the ability to draw with multiple strokes–whenever the software stops tracking the paintbrush marker, like if the paper is turned over or goes offscreen, it stops drawing the line. When the marker is re-tracked, it treats it as a new line. The brush texture demonstrated above is “Rainbow” from the Tilt Brush SDK, edited to be all red.

We also have begun working on adding multiplayer to the prototype, so that multiple people can view the same drawings at the same time.


We tested the three-strap headset design and added foam padding to our modified Google Cardboard to make it more comfortable to wear.

next Week

Next week is our prototype presentation! We hope to have working versions of the headset and markers, with designs that we plan on moving forward with for the rest of development. That way, our guests can have an experience as close to the final game as possible.

Keep checking back here for more updates on Studio Mar!

Week 6 Update


This week, the team continued developing the core mechanics of the game. Like last week, we’re still struggling with balancing the concepts the client wants to teach and what we think makes a game appealing to those in our target demographic. To help solve this problem, this week, we gathered information from our target demographic and from an expert in educational games. We hope to use this information to make any changes needed to our core mechanics in the coming week.


Programmers finalized the game’s main cycle, which now includes a day and night portion as well as lunchtime. Taking into account the feedback from different experts, we determined this would be the best way to make time pass in the game. Tasks will be assigned to employees now rather than the player. Programmers also made more progress on the store interior scene, although it is still mostly programmer art. Tapping on on the door marked “Delivery” now triggers a pop-up panel that details an ingredients list that is programmatically generated. We are working to have a similar mechanic for the store employees. Much of the programming work will be dealing with UI in Unity, as programmers decided that loading a new scene for each menu will be too time consuming. Below is how we envision the game cycle to function:

How we expect the game cycle to play out in a given day


This week, artists continued working on the in store assets and started on employee assets. One of the main struggles that the artists have had this week is getting all the assets needed for the game in the small space that we have. Since the game is being developed for a mobile platform, there is already a limited amount of space for the player to interact with. Specifically, we’re trying to incorporate the sitting area and cooking area on the same screen, but the limited amount of space available is making it seem a bit cluttered. In order to get around this problem, artists have considered creating a scroll screen, but are hoping to keep the player on one screen. Artists have also worked on the menu and map assets for the player to do different tasks on.  


Along with last week’s paper playtesting, this week, the team was able to go to an event at the Carnegie Science Center. There, we were able to distribute a survey for students in our target demographic about the way they approach video games and what they thought about our ideas thus far. While we did not get as many people to fill out the survey as we had wanted, there was enough information to obtain an answer to some questions we had about the appearance of the game.

The survey was organized into three sections. In the first, players were asked some demographic questions, including their age and what kind of movies and books they consume. We wanted to make sure that we were getting responses from a wide range of people. In the second section of the survey, we asked more specifically for the respondent’s video game preferences for the same reason. The third section of the survey dealt specifically with BizWorks and some of the concerns we had discussing the game with our client. We wanted to make sure that the art assets and existing UI we had made sense. We also wanted to address the question of whether we should make a more realistic game or a more fantasy game, so we presented responders with more fantastical themes, like steampunk and magic fantasy and asked them if they preferred those themes over the realistic concept art that we have. Lastly, we wanted to know what aspects of a game make it fun for the players.

With all our respondents coming from an engineering fair, we had anticipated the data being extremely skewed, but there was a wide range of interests within the respondents. In general, most of the respondents were interested in action/adventure media, including video games. Half of the respondents reported playing games for over ten hours a week, while half played significantly less. Regarding our questions, we found that most of the respondents would be interested in a fantasy or steampunk style game, but didn’t necessarily prefer it over the existing style we have been using. Therefore, we decided to keep continuing with the art style that we have been using. While we got valuable information from the playtesting, we only got six respondents, so ideally, we’ll get more information in the future from the target demographic when we have a working prototype.


This week, we were also able to speak to Erik Harpstead, a professor at CMU that specializes in educational games. We explained the mechanics of our game, as well as some of our concerns and how we planned to implement the different financial literacy concepts that we wanted to teach. His feedback came in the form of a few large points. He suggested that we take everything we wanted to implement and only include about half of them, with his reasoning being that we should try to make the game as simple as possible so that the players could process it more easily. He also suggested that we don’t have a hard end goal for the game and instead allow the player to choose when to restart the game. After speaking with him, the team decided to change a few aspects of our game. First, players will have the option to sell their business after a set amount of time, but will not need to. Instead, they can keep playing the game. However, no new interactions will be introduced, so ideally, the players will eventually want to restart the game on their own. Second, we changed the structure of the day so that it has a morning and evening shift, with a break in the middle of the day for employee interaction. Lastly, we’ll be trying to make all the calculations involved in the game to be as simple as possible, to make the game not overwhelming for the player.


Studio Mar: Week 5 Update

This week we continued research and design, focusing on three main aspects: designing UX concepts, playtesting our game concept, and testing the technology we plan on using. We acquired two Holokits as well as two Google Pixels to use for development, and so were able to start playing with those.

Designing UX Concepts

Our designers spent some time researching AR/VR UI design guidelines, and came up with a few guidelines of our own. Chiefly, we want to make sure that UI elements and interactions are anchored in physical space and actions, and avoid 2D menus. To that end, we developed a few concepts for micro-interactions, based on using hands as the primary interaction tool.

Unfortunately, we haven’t heard back from Manomotion about acquiring a license for hand recognition. While we will continue reaching out to them, we also started designing concepts for marker-based interaction–using a marker for painting, as well as a marker in the opposite hand for a palette or prompt card. We incorporated some of the gestures conceived for hand-based interaction into our marker concepts, like attaching a marker to a strap to slip over the flat part of the hand so that a player can flip their hand over like viewing a card.

We tested wearing the Holokit headsets, as well as a modified Google Cardboard headset. The Holokit headsets are top-heavy, because of the placement of the phone, and so we began developing concepts for a multi-piece strap that goes over and around the head to keep the headset on.

Playtesting the game

We also spent some time playtesting our game concept, as much as we can without having developed the game itself. Two of us played Pictionary using Tilt Brush on the Vive, and noted what about the game works well in VR, and what doesn’t. We concluded that the most fun out of playing Pictionary in 3D space involves 1) using the physical space fully, like drawing items of clothing on yourself or drawing a trampoline and then jumping on it; 2) taking advantage of the different brushes and textures available in Tilt Brush, like using the fire texture to draw real fire; and 3) watching your friend draw in the space and the excitement of the reveal of what they’re trying to draw.

Our other concepts–like drawing something that your friend describes–weren’t as fun as straight-up guessing a word that your friend is drawing. As one of our team members put it, what makes it fun is the combination of Pictionary and Charades.

Testing the tech

Since we finally acquired the Holokits and phones for testing on, we were able to start fully testing the capabilities of the different hardware and software we’re considering using.

Tilt Brush sdk

The Tilt Brush SDK supports importing Tilt Brush drawings into AR, not drawing them. Still, it gives us access to the brushes and textures used in Tilt Brush, so we plan on incorporating those into our own painting system.


With the Pixels, we were able to test the capabilities of AR Core, Google’s AR platform for Android devices. While its plane recognition capabilities are far better than Vuforia’s, it doesn’t support markers. Since we need to use markers to draw in 3D space, we have to pass over AR Core for now.


We downloaded the Holokit app and tested some of the demos in the headset. As far as we can tell by running the demos, the Holokit app appears to first recognize a plane using the phone camera, place an object on the plane through the phone camera, and then remove the camera feed and switch to a binocular view for the user to finally put their phone in the headset. The result is that the object (or objects) is reflected off the glass in the headset to appear like a hologram projected onto the real world.

Without viewing the world through the camera feed, the projected object is a little offset from the real world, and the in-app plane recognition isn’t that great. While those errors could be fixed by using a different plane recognition and aligning the video reflection with the real world, a more concerning problem with the Holokits is how the edges of objects are clipped by the edge of the phone’s camera. While this wouldn’t be a problem if one was viewing it through the phone directly, when reflected onto the real world the effect is odd.

Regardless, developing the game for the Holokit or a Google Cardboard-like direct view experience will be mostly the same, as will the UI/UX and headstrap design. We plan to keep testing with the different headsets once our prototype is more developed.


Vuforia supports plane recognition as well as marker recognition. While its plane recognition is buggy, it is functional, and its marker recognition works well. Using Vuforia and markers, were able to successfully draw in 3D space!

Granted, the drawing was limited to a small space, as the camera has to be very close to the plane marker for the software to recognize it. On top of that, if the plane marker is obscured in any way, the device loses track of the positions in 3D space and prevents the drawing from being rendered in 3D. Because our paintbrush marker was just a printed-out marker on a sheet of paper, this was problematic–but can definitely be solved by designing a better paintbrush marker.


This week, we learned that the most fun out of a 3D Pictionary game comes from adding in a Charades-like physical action element to it. We developed some UI design principles and began designing straps to create a hands-free AR headset. We also tested Holokits and were able to do some rudimentary drawing in 3D space using markers.

For next week, we plan to keep pushing on developing this game with markers. Can we make it possible for the fun interactions with physical space that we discovered in playtesting to work using marker recognition? If not, can we make the game fun in other ways? We also plan to continue developing headset and paintbrush+palette marker designs, to make the interactions as straightforward as possible.


Keep checking back here for more updates on Studio Mar’s development!

Game Concept Update

Over the course of this week we made more finalized plans on the structure of our game overall. We discussed visual inspiration, potential storyline plots, and various alterations to the game that could make the overall experience more interesting for the player.


For the finalized structure we decided to split the game into two phases, a Practice phase and a Challenge phase. A new scenario will be presented, but beforehand, the player will be pulled aside and be given a Practice session for the scenario. The player will be rewarded/given positive feedback if they answer the practice questions correctly (through more fun interactions, like throwing apples, etc.), but if they don’t do well enough the Practice phase will start over, allowing repetition, but also a low stakes environment. When this is completed, the Challenge phase will begin, where the player engages in conversation with the real social scenario. There will be no rewards/points and the player cannot progress without choosing the correct answer.  

To help facilitate the learning of the player, along with adding a feedback outlet and reason for repetition, we have decided to implement a companion who will help guide the player’s avatar through their journey in the game. The companion is the one who pulls you aside for the Practice phase and assists in learning. It is also the one that gives feedback on your choices during both the Practice and Challenge phase. Hopefully, the introduction of a companion will cause the player to have more emotional investment in the game.

The UI is beginning to move forward to the final design. We have decided to keep a top-down view for environment navigation, but have made slight changes to the question phase with the implementation of more interactive elements.


Through our discussions this week, we’ve learned more about what we are expecting for the final product of this game, along with strategies for effective teaching in a gaming environment. A Practice phase will be added to facilitate learning-by-doing. In the Practice phase, players will be able to practice and learn target Chinese expressions and concepts (speaking appropriately in different contexts) through a lot of questions and positive/negative feedback. The Practice phase is also full of fun interactions so that players can learn in an engaging playful environment. After the Practice phase, the players actually get to use and apply what they have learned in the real social scenarios (Challenge phase) in a higher-stake environment.


Introducing Beefy Chicken Stewdios


Hi everyone! We are Beefy Chicken Stewdios. We will be developing a RPG game for Chinese learning this semester. Our team members are:

  • Andrew Chang – Artist, UI/UX Designer

I am Junior in the School of Art with a Game Design Minor. I am mostly an illustrator with a passion for making, playing and modding games.

  • Ryan Eckert – Programmer, Interaction Designer

Hello, I’m a Sophmore in the Information Systems major, with a minor in Game Design. I’m mostly a programmer, but I’ve been more of a sound designer on previous projects. (Though since we have a person that can actually make music on the team I’m hoping that the sound for this game will be better than anything I can pull off). I’m excited to work on a “full scale” game that’s more than just a demo, and something that’s hopefully actually going to be played by people outside of demos and playtesting!

  • Xiaofei Tang – Producer, Learning Content Developer

I am a PhD candidate in Second Language Acquisition in the Modern Languages department. I believe in the potential of using digital games for language learning. Games can provide a fun immersive environment to practice using language in context. I am very excited to develop a Chinese learning game for my dissertation study entitled “Digital game-based learning for Chinese formulaic expressions”. The study will examine the effectiveness and learner perception of game-based language learning.

  • Bryan Tiggs – Artist, Interaction Designer, Programmer

I am Bryan, Game Designer with Beefy Chicken Stewdios, Master of Art and Unity, Manipulator of Sprite Sheets, Devourer of Bugs, Champion of the 2018 Global Game Jam! The elves know me as a senior Biology major, the dwarves know me as a Biomedical Engineering minor, and I am known in the northeast as a potential Game Design minor, and there may be other secret titles you do not know yet, titles so powerful I dare not utter them to mere mortals such as yourself…

  • Sarah Wang – Artist, UI/UX Designer

I am a junior Information Systems major with a double in Statistics and a minor in Game Design. Despite my technical background, I have a love of art and illustration, and primarily act as an artist in my projects. I’m looking forward to learning more as both an artist and game designer through this semester-long project!

Game Concept

We are developing a RPG Fetch Quest Game for second language Chinese learners to practice using Chinese in different social scenarios in a fun engaging environment.

Plot Synopsis

You are a robot of an older model who has worked for a restaurant for as long as you have been functional. One day, your boss leaves you temporarily on a trip. “Take a vacation for once!” These words are completely foreign to you, so you open shop anyway. Due to your lack of personal skills, you don’t realize that when customers talk to you about their small requests or problems, they aren’t asking you to fix them. However, you try to help them anyway, and are sent through a series of jobs and tasks before finally returning to the restaurant.

By the end of your journey, you obtain much better social skills and the restaurant’s ratings skyrocket. You’ve even made some new friends along the way, who are now motivated to come to the restaurant and visit!

The main phases of the plot are:

  1. The exposition — the leaving of the owner, the introduction of your character
  2. Journey through the world
  3. More journey
  4. The return of your owner and a reflection on what you’ve learned

Game Aesthetic

The game will be set in the future, aesthetically lending itself to a combination of VA-11 Hall-A: Cyberpunk Bartender Action and Gravity Rush. Sprites will be stylized and have dramatized poses/actions during conversation.

The layout of the game will be top-down for world traversal, and character sprite conversation overlay (akin to Fire Emblem).

Key conversations (conversations that prompt response options) between the player and NPCs will have a music shift and feel more like an event compared to just normal conversation from non-key NPCs.

Conversation — Chinese Learning

The robot will go through a series of day-to-day scenarios, in order to experience all aspects of society. Each scenario will have a series of Chinese questions that have appropriate answers based on the social connotations (i.e. some answers are too formal, have improper grammar, etc.). Correct answers will grant positive reactions from the sprites, along with continuation of conversation and plot. Incorrect answers will grant various negative reactions from the sprite, depending on what the player chose and why it was incorrect.


  • Fruit Vendor
  • University
  • Bus
  • Train
  • Taxi
  • Bank
  • Street
  • Mall
  • Restaurant


End Goal

Our goal is to make a game that engages learners of Chinese to practice Chinese expressions in an immersive environment. One challenge of making an educational game is that we want to motivate learners in a fun gameplay experience, but we also do not want to distract their attention from learning. Our end product will be used in Xiaofei’s dissertation study to test if the game promotes better learning outcomes and learner motivation compared to an online learning environment that delivers the same learning materials but without gaming elements.