Project: CASA

Timeframe	July 2022 - January 2024
Languages Used	C# Typescript
Softwares Used	Unity, Postman, Docker
Framework	Nest JS, Prisma
Project Role	Game Engineer

CASA (Computer Adaptive Story Assessment) was my primary project that I worked on during my employment at Filament Games. The purpose of this application is to assess children within the ages of three to five through various types of language and positional skills. The game was made for English and Spanish children with support for both languages. To read more about this project, a blog post was made here.

The project was separated into three unique structures. One such structure was the Unity application that was designed for the children to interact with questions. Another was the teacher dashboard which allowed the teacher to interact with their students during the assessment. Lastly there was the server backend which was in charge of handeling all inputs and outputs, REST calls, socket.io interaction, and our database for the researchers.

During my time on the project, I worked in both the Unity app and the server backend to ensure the bridge between both was efficient, secure, and adaptable to make any changes that were required to be made during the university's calibration process. I worked in a scrum environment alongside web developers, UX/UI, producers, designers, and other engineers.

Unity Application +

Students who play CASA will be answering various questions from either a set list created by researchers or through a random generated list created by the researcher's CAT (Computerized adaptive testing) algorithm. I explain more about that in the Server Backend section.

Each question is set to have up to three different VO prompts; each are the same except for the dialect that it uses. As an example, an English question has access to Latin, Black, and White dialects, all of which were given to us by the clients.

The game, while acting as a source of research, needed to feel fun for the users who were all under the age of five. To make our client's dream game come to life, I worked alongside a game designer, UX/UI designers, and producers to make this happen.

Gameplay Loop +

The gameplay loop is as followed: Select Avatar, Training, Assessment/Story, Finish.

If the user is brand new to the program, they first must select an avatar. This avatar is the student's portrayal in the game. They may choose any of the possible avatars depending on the scene they are in (Grocery store or Festival) and their language. Each Avatar includes a parent and a child.

Training +

All students regardless of how much time they have spent in CASA will start their game in the Training scene. I was the sole game engineer in charge of designing the code and editor architecture for the Training system. The purpose of the training scene is to allow the student to practice all three question types before going into the main assessment. If the student fails to answer both the touch and drag questions correctly, they are sent back to the main menu rather than proceeding to the real assessment.

Each training question gives the player three attempts to score correctly. For every failed attempt, the question either plays a VO hint or visual animation hint depending on the question. Answering a training question correctly results in a positive compliment VO towards the user.

Here is a clip of the touch training question. The question will ask the user to "find the cart." As shown, the user selects the cart, then on the teacher dashboard, the teacher will confirm the selection. From there, the game will check to see if the selection was correct. If so, the game moves on to the next question.

As a side note, the teacher dashboard also allows the question to be restarted. In addition, the dashboard also allows for the question prompt to be replayed. This occurs in both training and the normal assessment.

Lastly, here is a clip of the festival training scene where it uses glasses as the main item across all three questions.

Assessment +

The assessment in CASA takes place in one of four areas depending on the scene. Each of these areas have their own theme in both the artstyle and question content. Questions made for the picnic area in the Festival are often themed around food, foodtrucks, or picnic supplies. The animal section of the festival is obviously themed around animals.

It was my job to construct the systems for proper question spawning, question importing, and general gameplay code for each of the three types of questions.

CASA has several types of questions. The three main types consist of touch questions where the user touches an item(s) to select it for an answer. Drag questions required the user to drag items into some form of container such as a box or grocery cart. Lastly there are speak questions which simply need the user to speak for an answer and the teacher will score the question manually. Questions also do not look the same with each having a different spawn configuration of items, different amount of items, different visual setting in the game (example, one question could be in the dairy aisle, another could be in the produce section).

The gameplay loop for a question is: Question prompt plays -> all item VO (if there are any item VO) plays sequentially in order from first to last -> student answers question -> teacher proceeds to next question / replays question.

Question Spawning +

I, alongide my senior engineer, created a system that allowed to generate questions as objects from a Google Sheets page. This sheet was dedicated for creating all types of questions with any info they would require to show in game, including its spawn configuration, its setting/scene, the correct answer(s), art, language, and more. Each of these objects have an ID that we use to match with whatever ID the server backend gives the app. From there, the system instantiates all objects inside of the set configuration, stores the correct answer(s) for when we score the question, and prints the question ID and sentence for the researchers to see.

Here is an example of a Drag Question using the "single spawn config." It's container is a grocery cart and the items include three different types of cheese. The correct answer is the queso redondo (middle item). Our system imported this question from the Google Sheet to make a scriptable object. Then, after matching its ID with the backend, the game took this object and used its information to spawn the question that the student would see and interact with.

Server Backend +

The server backend is in charge of handeling all game info being sent to or sent from the Unity application via REST calls. These calls include submitting an answer, grabbing a new question, finishing the assessment, and editing the student's entry in the database for the researchers to access in the teacher dashboard.

It was my job to create both the selection manager which handles grabbing new questions as well as the overall session manager that handles the REST calls that sends or obtains info from the app. We used Nest.JS as our framework for the server backend, socket.io as our communication library, and prisma.io for our database to store student info including their assessments. This was all written using Typescript and Node.js. Additionally, I worked on the bridge connection from the server backend to the game application by adding all REST calls to the game through a unity socket.io library to ensure efficient communication.

Assessments in the Unity game are all the same, codewise. However, in the server backend there are two different types of assessments: Calibration and CAT. The only difference between the two is that calibration uses set lists of questions provided by the researchers, whereas CAT assessments use randomly selected questions dependent on student score. The purpose of calibration was for the researchers to find adequate difficulty values for each question manually, of which they would then update the questions for CAT.

Selection +

CASA uses what is called a "CAT" algorithm that was given to my team from the client researchers. This algorithm allowed for us to determine which question to send to the app depending on how well the student is answering questions in the assessment. Each question has its own difficulty value (set by the researchers). When the game asks via socket.io for a new question, the Selection Manager will take the student's score and after going through various calculations (functions given to us by the researchers), it will randomly select a question within a close range of the current score.

Example: If a student's score is 5, the Selection Manager will find all questions roughly near 5 and randomly select one to send to the game, specifically its ID.

If this assessment was Calibration, the Session Manager would skip the Selection Manager and simply pull from a premade list of questions. Calculations have no affect in calibration. Architecturally, the Selection Manager is only ever able to talk to the Session Manager.

Session +

The Session Manager simply handles all REST calls and stores player info in realtime to send to the database after an assessment completes. The Session Manager acted as the bridge between the server backend and the Unity application, and it was important to ensure proper and secured communication occured between the Selection Manager, Session Manager, and Unity.

Whenever the game successfully submitted an answer which was triggered by the teacher dashboard via socket.io, the game would send all information through a JSON object to the Session Manager. From there, the Session Manager adds the information to the player's current "profile" being held during the assessment and edit any current player values that needed to be edited, such as the player's current score, amount of questions the player has answered, and more.

Getting a new question simply talks to the Selection Manager (shown above).

After an assessment completes which was triggered when the student answered the maximum amount of questions (or the selection manager failed to send a new question), all info is sent to the prisma database for the researchers to use. That info included the student's final score, all submitted answers, all question IDs that were asked/answered, amount of time it took to complete the assessment, and all final calculations that the researchers provided us through their functions.

← →

Timeframe	October 2023 - January 2024
Languages Used	C#
Softwares Used	Unity
Project Role	Game Engineer