Group members: Cole Sohn, Rita Tlemcani, Annie Nguyen
Table of Contents
- Artist Statement
- Design Process
- Methods
- Playtesting and Iteration
- Game Playability
- Narrative
- Group Final Playtest Feedback
Artist Statement
The Dall-E Alchemist is a game about player curiosity, creativity, and interest in a world that has changed from the one we know. Players will interact with townspeople by talking to them and helping them by fulfilling requests. In interacting with the world, the player will put together their own picture of how a community has sprung forth many years after the last civilization ended.
With each area, players are encouraged to explore every nook and cranny and interact with whatever they can. The only thing guiding them are the character requests. Players can explore at their own pace, and come back to places where they want to delve deeper. The hope is that players will be curious and feel free in their exploration.
Inspired by the images generated by the AI model Dall-E, character requests are satisfied through combinations of objects, potentially resulting in funny results for the player that satisfies what the character wants. We hope that they will enjoy playing with the creative potential of these combinations!
Design Process
Target Audience
The game is for a general audience of players who want a relaxed creative gameplay experience. The game requires no twitch-skill and is open-ended for the player to experience in the way that they choose. It currently features 3 environments: a town, forest, and beach. The familiarity of these environments to other top-down games puts the focus on finding and combining items in unique ways.
Game Mechanics
1. Game Map
Our game map consists of three main areas: a central town, a beachside, and a forest. Here is a quick overview of the locations:
2. Core Concepts
The final game is a slice. The puzzles/requests are representative of ones that players would encounter in a larger game, while the style is polished and what we would want to see in a full game. The narrative is incomplete, as there would be a larger world to explore and understand if there was more time to build out the game.
In terms of the formal elements, the game is single-player, with the primary objective of satisfying NPC requests. In fulfilling requests, the player will also explore the map to find materials, which can be considered as a secondary objective. These objectives are supported by the inventory and combining UI, the primary mechanic of the game. The UI allows players to see what is in their limited inventory, combine materials together, and select what materials (combined or not) to present to the NPC. By satisfying the objectives, the outcome is that players will get new dialogue that tells them more about the world’s story, both of its past and its present. The only rule that players are bound by is the “magic” of combining available materials in the game. The results of combinations will have properties of the separate objects, and those properties will affect whether or not their results satisfy requests. Paying attention to the character dialogue will help players progress and get to know the world more.
The game architecture of the map relies primarily on constraint and concealment. Constraint generally covers the borders of the map, which helped scope the extent of players’ exploration, as well as the guiding paths spread throughout. The paths help guide the players to the main locations and potential points of interest, but does not fully constrain them from exploring other spaces. Along the way, somewhat familiar buildings and natural elements are incorporated to create an environment that is relatively known by the player, but still has particular features for them to explore. In this general structure, concealment of materials is what fills out the inner areas of the map. There are a variety of materials that are interactable, but they are all in different locations. Some blend in with the natural environment more than others, so players should try to interact with them to find out what materials are hidden in plain sight.
For space & narrative, exploration of the map is how the player will experience the game’s loose narrative. In addition to the information from NPCs, players can draw their own conclusions from how each area is laid out, from the placement of a certain NPC’s home, to a peculiar feature nested deep in the woods. This makes the progression of the game non-linear. While there are requests to fulfill, the player is open to completing them at their own pace. As they traverse and fulfill requests, they’ll gain more objects and knowledge about the world.
For onboarding the player, we have an opening demo/tutorial. The player is initially placed in Qumama’s house. Qumama guides the player through using the game mechanics. Qumama first asks the player for coffee and a guide shows up to teach the player how to pick up an item and give it to an NPC. Another request is to combine toast and egg. This is how the player learns to use our combiner tool. Qumama gives instructions on which buttons to use to combine the toast and egg items. Once combined, the player gives the item to Qumama concluding the tutorial. Before concluding the tutorial, the player is not allowed outside of Qumama’s house to ensure the player learns the game mechanics.
3. Main Design Elements
Tone
To set the tone of a mysterious new world with reminiscent objects of the past era, we added some hidden ruins throughout the map. The NPCs will tell you bits about the past and solving their puzzles gives you relics of the past that Qumama will help you understand. We bought a tile palette set to use in our game and recolored the set with a pastel color palette that creates a mysterious, but cozy atmosphere. Every item generated from the DallE Mini is recolored with the same color palette to keep a uniform style. The tone is cheerful, curious, and mysterious. As such, our characters are a mix of cheerful and mysterious people, telling you about the past and present to create a sense of curiosity.
Core Loops and Player Relationships
The game starts in Qumama’s house. After the player finishes the tutorial, they are free to explore the map. Qumama tells you about characters that need help in some areas. Helping certain characters will reward the player with ruins from the past. Taking the ruins back to Qumama unlocks her explanations of the past world. The core loops are getting requests to help some NPCs, helping them, then returning to Qumama with rewards and looking for a new quest.
Our game is a single player game, with the primary relationship being between the player and the narrative. The NPCs all know Alice’s mentor, Qumama. By going back to Qumama with the relics that they collect in their travels, the interaction establishes that Alice has a good and knowledgeable mentor to lead her through her journey. Hopefully, the player feels more attached to the characters and world through this progression.
Visual and Auditory Design Choices
We picked a pastel color palette that we used for our whole game to make the style uniform. We also created a dense forest and vast beach to create the feeling that there is a mysterious and exciting world to explore. The warm and crowded town in the middle is there to feel like a comfortable and safe place for the player to go to. Visual design choices such as different trees in the apple grove guide the player to the items they need to solve the puzzles.
Additionally, there are subtle paths all throughout the map, blended into the environment so that the player doesn’t get lost in the big map. We also surrounded Qumama’s house with pink trees to give it a special feel and tie back to the fact that Qumama is a powerful Aljemist. There are a variety of distinct touches to make each area unique, from ruin pillars near some bones on a cliff, different ground textures in town, and unique building interiors. We also added different background music to areas, in order to distinguish the regions further. Creating different local themes was important to slightly change the tone according to the location.
Game Walkthrough
Here is a link to the walkthrough video: https://www.youtube.com/watch?v=3rOTtCyhV98
Here is a link to the hosted game: https://colesohn.itch.io/the-dalle-aljemist
Password for the game: Alice
Methods
Custom Systems
For more detailed information about how the game system works (with lots of images), refer to our documentation.
The Dall-E Alchemist was built with Unity. Unity is a component-based game engine where scripts defining game behaviors are assigned to game objects. This has the benefit of organized scripts and scripts on the same game object being able to access each other. The downside, however, is the need to manually assign dependencies when scripts must reference code on other game objects. To reduce the need for dependencies, we utilize the C# coding patterns of singletons and callback methods.
A singleton is a class that can be instanced once and accessed from any other script in the Unity scene. This makes singletons useful for storing global data such as game states, inventory states, actively speaking NPCs, etc. A callback method is a method that calls other methods from other game objects that are subscribed to that function. This is useful for updating UI elements such as dialogue UI and inventory UI.
The item and NPCs puzzle systems in this game were built using scriptable objects. Scriptable objects allow developers to create and assign data to objects from the Unity editor without having to interact with code. To see how this system works, refer to sections 3 and 4 of our documentation.
As an example, the item system in The Dalle Aljemist was built to use scriptable objects. The developer creates a new item using the interface and assigns data such as a name, sprite, and set of properties to the item. A similar approach was taken for NPCs, which require sprites, and a name and color to be assigned.
The dialogue system was also built utilizing scriptable objects. NPCs take a list of “chat” objects, which contain lists of dialogue lines. Chat Request objects extend chat objects but contain information about the puzzle.
Tilemaps
Methods we used for creating tile maps are illustrated in section 2 of our documentation. In summary, we used Unity’s 2D tilemap toolset which allows a user to define tile palettes that they “paint” the map from. We used tilesets using Gif’s Super Retro collection, recolored using the K-Means approach described in the following section. We used Unity’s tilemap collider components for collisions.
Recoloring
All assets used in the game are recolored using a K-Means approach. Two methods are used subsequently for recoloring: Color Reduction and Color Transfer. For Color Reduction, K-Means outputs a set of k cluster centers based on the colors of an input image. Pixels in that cluster are assigned the color associated with the center. For color transfer, the cluster centers from the previous approach are used to assign colors to a new image based on the nearest neighbor. We use the approach described in Syafiq Kamarul Azman’s blog post for color reduction and transfer.
Dall-E Mini
Dall-E Mini is an Open source version of OpenAI’s DallE model. DallE Mini has been developed and trained by Boris Dayma. Is it a Generative Adversarial Network that created images from text inputs. We used it in our game for the combination mechanic. We assigned a word for each image and with some prompt engineering trial and error, we figured out that the prompt “1 2, 2 in the shape of 1, artstation game asset” gives the best results. In the prompt, we replace 1 and 2 with the different items that we want combined. For example, to combine “Apple” and “Hat”, we would use the prompt “apple hat, hat in the shape of apple, artstation game asset”.
Web Automation Tools
Our initial approach was to import Dalle Mini and Mega into a Collab notebook and generate images based on item combinations. This approach was not sufficient, however, as Dalle Mini had reasonable runtimes but poor outputs and Dalle Mega had reasonable outputs with unreasonable runtimes.
The Dalle Mini web demo uses the Dalle Mega model running in parallel on multiple GPUs to generate 128 images, score them using a CLIP model, and output the 9 best images in roughly 30 seconds per prompt. This approach generates good results, but would have been impossible to replicate locally due to hardware limitations. Instead, we used the Selenium library to write a python script which automates the online web demo to generate the combination item images. See full code in here: https://github.com/ritabt/Dall-E-Alchemist
Pixelator
The image outputs from DallE Mini did not match the pixelated style of the game. We used a python pixelator named Pyxelate in a Colab notebook. Our method takes as an input a folder path and pixelates every image in the folder. After generating images with Selenium and DallE Mini, we ran Pyxelate on all the output images and imported them in our game.
Playtesting and Iteration
1. Checkpoint 1: Concept Doc
See the original document here: https://mechanicsofmagic.com/2022/05/03/checkpoint-1-project-2-group-concept-doc/
We submitted our Concept Document with our initial thoughts and ideas for the game for this checkpoint. The original idea, inspired by the images generated by Dall-E, involved a post-apocalyptic world where there are now a few “Collectors” who have the ability to mutate/combine objects together. The document provided an overview for our target mood, mechanics, and aesthetic, among other things. Our feedback came from three classmates, who generally expressed a similar enthusiasm for the early premise of the game. There were concerns raised about how we might pace the game given that it depends on exploration, as well as concerns over the scope of combinations that we would create (quality versus quantity).
The positive response to the setting and premise of the game helped us focus our later plot details to stay with those ideas. For pacing, we ended up incorporating NPC requests that would reward the player with unique items and dialogue that revealed more about the overall world. That way, the narrative pacing would be tied to the NPC interactions, providing some structure to what the player discovers and when. As for combinations, we considered a variety of options to control the scope, since we could only generate so many fitting images for combinations. We narrowed down to having a limited set of items that we planned to use in our NPC requests, which we would then generate combination images for, then select the best ones. This way, we could control the quantity and quality of what we put in the game.
2. Playtest 1
In our first playtest, we tested a simple base forest map, and the earliest version of our inventory and combination UI. Two classmates playtested that day, walking around the map and testing the limited combinations that we had. One of the playtesters really enjoyed seeing the results of the combinations, amused by the base descriptions and interested by the combinations they could make. They both appreciated the overall aesthetic of the forest scene. They also expressed a desire to explore outside of the boundaries. There was some confusion on how the combination UI worked; there were attempts to drag and drop the items from the inventory into the slots, as well as confusion over the “add” and “hold” buttons to interact with the items.
We took the positivity towards the aesthetic and combination results as positive feedback, and really pushed forward in those regards. In particular, this playtest helped cement that players were indeed interested in the combination system and the possibilities of what they could make. With regards to the inventory/combination UI confusion, we changed the keywords to make them more distinct, using “mutate” instead of “add” to more clearly indicate which button added the item to the combination. At this point, we considered making some intro demo at the start of the game that would make the buttons clear, though it was not implemented by the time of the second playtest (it was done later).
3. Checkpoint 2: Testable Core
This checkpoint submission had the same version of the game as for our first playtest. Our section TA noted some considerations for moving forward, such as the design of the map itself. Would it be more maze-like in the discovery? Would there be any landmarks to guide the player? With regards to the puzzle mechanics, she wondered if we would incorporate them into the larger narrative, and how. Would there be an order to them, would the game be over when the player finished solving them? The primary feedback was suggestions on the direction of the game moving forward.
We decided to create request puzzles that would reward players with certain relics of the past or reveal extra dialogue about the region or people they are interacting with. That way, there would be motivation to seek out characters and gradually learn about the world. The order of puzzles didn’t quite matter to us in the larger picture of the game, other than some smaller puzzles that were needed to obtain materials for a larger request. This would hopefully let players explore and progress at their own pace. For the map design, we tried to make the map more “free-roam” style to allow the player more freedom to look around, but considered the maze-like suggestion in case the map became too confusing to traverse.
4. Playtest 2
This round of playtesting had a more refined map, this time featuring the forest area that we planned to have in the final game. We also had the design for our protagonist, Alice, as well as some early NPC requests and interactions. Our classmate, the playtester, had fun trying to figure out how to satisfy the NPC requests, as well as seeing the variety of combinations that she could make. She also enjoyed the fun text descriptions of the items, which helped her understand what she picked up. In exploring to find materials, she noted that she felt lost when trying to traverse the map, feeling like she couldn’t really remember where certain objects were once it was out of camera view. She was also confused by the use of “mutate” as a button to add materials to combine; for her, the word seemed to mean the act of combining itself, rather than adding the material to a slot to be combined. She was also slightly confused by the font letter “I” used to indicate the inventory, as she first read it as the number one, believing it to be a count of how full the inventory is.
To address the issues with map navigation, the area was resized and detailed with more landmark features that would help the player better remember where they traversed. The direct suggestion by the playtester was to include a minimap, but we figured that the root of the issue was a “aimless” map with no distinguishable features to help players remember. To address this, the map was revised to be more maze-like, with suggestive paths and more land features. With regards to the confusion of buttons, we tried modifying the button to be “add” to better imply that it is added to the combining UI. The inventory “I” was later changed in the final iteration of the game, but was not changed by the time of the next playtest.
5. Playtest 3
This playtest had one classmate testing our different map parts separately, as we hadn’t combined them yet. We wanted to playtest the map designs as well as our updated inventory UI. They mentioned that the quests and map felt out of place and they weren’t sure why they were helping the NPC. They also found bugs in our NPC interaction where the player gets stuck and can’t move. However, they enjoyed exploring the map and collecting items.
We made a bigger effort to incorporate the different sides of the map into the bigger story of uncovering the mysteries of the previous world. We did that by changing the rewards received from helping an NPC from regular items to special items that unlock Qumama’s knowledge. We also investigated the bug where the player gets stuck and made sure to fix our implementation.
6. Final Playtest
The final playtester was a fellow classmate, who had heard the quick overview of the game before. This version of the game had all three regions incorporated on the same map (town, beach, and forest), as well as an opening demo interaction to onboard the player. There was a lot of positive feedback on the improvement of the UI, including the clarity of the buttons in the inventory/combining system (now changed to “combiner”, “give to”, “put away”, and “collect”). The playtester found the demo to be useful and funny, giving them a taste for what to expect as well as a practical introduction to the UI functionality. The playtest revealed some bugs in collidable layers, and lack of visibility in some UI elements (the trashcan to remove inventory objects, the “E” indicator drifting). She was interested in seeing the various rewards the NPCs gave, particularly the “relics” that were fun objects. Overall, she enjoyed how casual the game felt, and looked forward to seeing more.
Final playtest link here (recommended time to watch 7:21-10:30): https://youtu.be/zv14bZPSFuE?t=441
7. Post-Mortem
Generally, we wish we could better refine the final output of the game. This slice is a good representation of the base details and narrative cohesion of the game, but there are elements that could be added to better deliver our original idea. Having music for each area/building, having more light effects, and adding animations would make the game much more lively and cozy than what we have currently. Having time to fine-tune the map collidables, interactables, and clarity of boundaries would also be good to add to a smoother play experience.
Outside of map aesthetics, adding more meaningful NPC interactions and requests to further build out the world would be the next step. This would help us smooth out the narrative progression of the game, and have it conclude on a good note (related back to the main emotions that we want to convey). The world would become a much more rich one that builds on the initial curiosity and interest from our playtesters.
Game Playability
1. Tutorial
We designed our tutorial to guide the player in understanding our UI and mechanics. At the start, there is an arrow on top of Qumama that bobs to catch the player’s attention. Once the player is near Qumama, an “E” pops up to indicate the key for interactions. After pressing “E” the player gets a request from Qumama to bring coffee, and Alice talks to herself to suggest how to pick up an item. When the item is picked up, a similar dialogue window pops up telling the player how to give the item to Qumama. In case the player doesn’t register what needs to be done, if they press “E” next to Qumama, a reminder will show up. To ensure the player goes through the tutorial, Alice cannot leave Qumama’s house until it is finished. We implemented a similar process to teach the player how to use the combiner. After the player has learned how to pick up an item, give an item to an NPC, and combine two items, they can play the whole game. The “E” and “Q” button reminders keep appearing throughout the game to remind players which buttons can be used. To see the tutorial in action, refer to our walkthrough video in section 2.2.4 where the first 1:30min is the tutorial.
2. Polishing
We polished different parts of the game from the feedback we received during playtesting and from each other in the team. Multiple iterations have been made to the inventory UI to achieve the final version. The main modifications include changing button names to be more intuitive, re-organizing the layout to display all the text descriptions for the items, and improving the design to the final purple look which aligns more with the tone of the game. For the map, a big effort went into making sure the collisions and player covering tiles were set up correctly. Also, we added decorative and unique tiles to each area to create a slightly different tone with more refined visuals. The dialogue boxes have also been modified to match the aesthetic of the inventory look. The NPC sprites have also been meticulously created to match the character’s tone. We added signs in the game that the player can interact with to know directions.
3. Hint System
To make sure the player is able to progress smoothly, the game provides clear keywords about materials or material properties needed to satisfy requests. In the case that the player tries to give something unsatisfactory, the NPC will not accept it, and instead provide some dialogue hinting about what would satisfy them. For example, one NPC’s request asks for tea, with “some spice” to it. The correct combination would involve combining cinnamon with water, which can be found in the forest village. However, if the player presents something incorrect, the NPC has dialogue about asking someone in the village for tips, or potentially looking around the nearby trees. In general, the requests and hints either give location tips or key adjectives to convey what needs to be combined.
Narrative
The game’s narrative, which is more loose and explorational, relies on the player traveling to each area and making note of the landscape, NPCs, and items that they interact with. Each feature is intentional within the space of the map, and the paths are there to loosely guide players along the way.
Puzzles, or requests, fit naturally in our world, as NPCs pose requests for the player to fulfill. The central combining mechanic is the main tool that is used to satisfy requests, avoiding any other confusion as to how requests should be fulfilled. The objects used are not foreign to players, so the property associations of the objects (i.e. cinnamon being warm, and a spice) as well as the objects themselves (crabs, fish, sand, berries, etc.) are natural to the player. The requests also fit the needs that the world presents; the NPCs with requests all need help or want something, and those requests fit with their location. The puzzles vary in difficulty in the sense that there are different specificities for requests. Some NPCs may require a specific combination, while others accept a variety of related things. Some NPCs reward the player with materials that can be used to satisfy other requests, while some requests rely on exploring the environment for all the necessary materials. While the request conditions vary, we have provided relatively clear keywords to guide the player. There are also more clear hints that are given if the object does not satisfy the NPC.
The narrative is not linear; rather, it relies on the player to draw their own conclusions from NPC dialogue and the environment. This makes it dependent on requests being fulfilled, as players will gain more information this way.
Group Final Playtest Feedback
Cole: Notetaker/Moderator
I really enjoyed the experience of taking notes and moderating the playtests for our game. It was interesting to piece apart what people’s reactions and pain-points were in the game, and take note of what it seems like it is saying about the whole experience. For example, some players noted that they wished there was a minimap. We didn’t want to add a minimap as we wanted players to pay attention to their surroundings. We realized this request was likely due to players getting lost. As a result, we scaled down the sizes of our maps and added more visual markers to prevent players from getting lost.
Rita: Moderator
It was a lot of fun to see the player’s reaction to our game. There were a lot of unexpected reactions and confusions so the playtest session was very helpful. The player was confused about how the beach map tied into the whole story. This feedback helped us think about making NPCs give Alice relics of the past that she can take to Qumama. That way talking to NPCs and helping them has some meanings. The player also identified a few bugs that we did not see earlier and we were able to fix them afterwards.
Annie: Playtester for Sky Chaser and Art Heist
I first playtested Sky Chaser, a 2D platformer about a character who wants to reach the stars. The aesthetic was clean and simple, somewhat similar to Night in The Woods. The playtest version consisted of a placeholder character, trying to collect enough stars to navigate to the top of a building. The trick was understanding that the lit up windows of the building corresponded to window sills that you could land on; you would fall through the ones that were not lit up. You also needed to collect enough stars to make additional platforms appear in order to reach the top. The visual and auditory feedback of the jumping was satisfying, as a small light trail followed the path you made, and the jumping had a little “squish” sound every time you landed. The game could be improved with some hints or feedback to understand where to jump, in the case that the player kept making mistakes and not jumping on the correct platforms. Collecting stars and seeing the number you collected was also not very obvious at first, as the counter was at the top left corner, and the use of the stars would not have been clear if the player didn’t notice they made platforms appear. One suggestion would be to make the counter “pulse” or have some effect to draw the player’s attention to it, so they could be more aware. As the levels increase, it might also be good to include checkpoints for the player, so that they don’t have to start from the bottom again.
I also tested Art Heist, a puzzle-in-a-box game, where the players have to catch the art thieves in a limited amount of time. The 20 minute timer provided a nice amount of pressure to push the game along and make players consider the most optimal use of their time. The puzzles, in my opinion, were of reasonable difficulty given the time, and it was good that they were open enough such that players could work on different parts to help solve them together. Assembling the painting was particularly fun as a group! There was a slight disconnect when being introduced to the virtual “email hacking” situation, and then going through a text-based chase to catch the thieves, so maybe that feature could be better set up and clarified for players. Perhaps even having the site up on a separate computer would be good for other players to be involved.
