Designing Themedior: Game Mechanics and Puzzles
Advisor: Swetha Bhattacharya
Internship Location: Roblox
Onsite Mentor: Utkarsh Singh
The research I will conduct is gaining information on successful game mechanics and puzzles. To procure this information, I will be playing through successful video games and analyze their use of game mechanics and puzzles in relation to the narrative of the games. Additionally, I plan to watch documentaries exploring the use of game mechanics and puzzles and how they are incorporated into video games. Finally, I plan to read through research papers on effective game development strategies as well as engaging forms of game design/mechanics.
The final product of my senior project will be a playable video game and a successful game mechanic and puzzles that help enhance the narrative and increase player immersion. For the game mechanics, I plan to create a side-scroller RPG combat system. There will be one playable character with different equipment and skills to enhance player strength. Additionally, there will be multiple enemy sprites with different skills. For puzzles, I plan to incorporate search puzzles that allow players to explore and interact within the stories.
Some additional game mechanics that I plan to incorporate (if time permits) are a replay system, that allow players to replay parts of the game and interactive character models, which allow players to interact and form bonds with characters.
Project Blog
Week 1: A New Operation
Hello! Welcome to my senior project, “Designing Themedior: Game Mechanics and Puzzles.” In this post I will give a brief intro to my project as well as go over what I plan to achieve in the next eleven or so weeks of this operation.
Operation’s start
As an artist, animator, programmer, and avid fan of video games, I have naturally found myself on the path of video game development. Oftentimes, video games are able to attract players due to their interesting storylines and high-quality illustrations but fail to retain these players due to lacking game mechanics that are either repetitive or lack relevance to the story. For this project, my main goal is to understand and design game mechanics and puzzles that enhance user experiences through creating immersion and elevating the game storyline. I will be examining different game mechanics and puzzles and their effectiveness in successful video games such as Omori and Gris as well as their effect on game narrative and immersion. I want to understand how game mechanics affect the overall experience of players and how I can use them to create a more successful and engaging game. Besides game mechanics, I also hope to study and create animations that help to attract players to our game and create a pleasant experience.
Dedication page
And so with this senior project, I have started my game development journey, as the animator and programmer, with my ally Ellie Xi, as the artist and story writer, for Themedior. You can find her blog here, definitely check it out! Additionally, I will be working with my knowledgeable external advisor, Utkarsh Singh, a software engineer at Roblox. And finally, I will be working with my wonderful internal advisor, Ms. Bhattacharya. If you have the time, feel free to view all our progress pictures and videos at https://themedior.artstation.com/.
Operation Themedior
All good operations must have a plan. As you may have already guessed our final goal is to create a video game titled, Themedior. Well maybe not the whole game, but at least the first chapter, where players are introduced to the world and various game mechanics and puzzles. I plan to use the following software: Live2d, Clip Studio Paint, and Unity or Godot.
And here is the timeline that will be taken to clear this operation.
Week 1: Play through Gris and analyze its use of game mechanics and puzzles in relation to its story. Begin familiarizing myself with Unity and Godot.
Week 2: Play through Omori and analyze its use of game mechanics and puzzles in relation to its story. Continue familiarizing myself with the game engines.
Week 3: Set up characters. Start on character movements and enemy movements.
Week 4: Create character interactions and enemy tracking system.
Week 5: Create character projectile/attacking system and enemy attacking system.
Week 6: Continue working on the combat system.
Week 7: Finalize combat system (fine-tuning the aiming system, tracking system, and character movements).
Week 8: start creating different menu screens (start screen, main menu, story menu, end screen).
Week 9: Start creating story interface and puzzles (how the story will run in the game and were the puzzles will be located in the the story).
Week 10: finish the puzzles and start fine-tuning everything.
Week 11: start beta testing and incorporating feedback.
Week 12: finish incorporating feedback and incorporating any last adjustments.
That's all for now. I hope you enjoyed reading about my project and will join me on my operation, as I design game mechanics and puzzles and bring illustrations to life through animation. I'll be back next week to report my analysis on Omori and Gris as well as my progress with Unity and Godot. See you then!
Week 2: Choosing Sides
Hello and welcome back! In this post I will be discussing the Pros and Cons of Godot and Unity Engine and which one I have decided to continue on for this game. Additionally, I will be giving a review of GRIS and its use of game mechanics.
Weighing the Sides
Both Godot and Unity are great game engines with their own strengths and weaknesses. I have tested both engines over the course of the past two weeks, building a simple 2D game in each. In this section, I will discuss the pros and cons of both engines and which engine ended up outweighing the other. In this case, I will be discussing Godot 4.0 and Unity 2022.3.
Godot Engine (4.0) | Unity Engine (2022.3)
Speed: | Time is of the essence for this project, so the faster the engine the better.
pros:- has a much faster compilation time and runtime than Unity | cons:- significantly slower compilation time and runtime than Godot
Usability: | How easy is the game engine to use/learn?
pros:- lot more beginner friendly (simpler user interface)cons:- less features- not ideal for collaboration or team projects- not as many tutorials and many tutorials are outdated (Godot 3.0) | pros:- much easier for collaboration and team projects- greater amount of tutorials and forums for learning and troubleshooting- more complicated interface, but greater usabilitycons:- needs a separate IDE to process code
2D GameDevelopment: | Since our goal is to create a 2D side-scroller game with 2.5D features, we need an engine that works well for 2.5D games.
pros:- 2D intuitivecons:- does not allow for 2D and 3D objects to coexist- does not handle 2.5D games well, clear separation between 2D and 3D functions | pros:- more ideal for 3D games, but works just as well for 2D- allows 2D and 3D objects to coexist in a single space- 2D sprite rig allows for skeleton to be moved in the z-axis, allowing for more possibilities in animation
Compatibility and Assets | What other applications is it compatible with and what assets/libraries are available?
pros:- no built in library of assets, but has an asset sharing platformcons:- not compatible with some applications that we plan to use (Live2D) | pros:- built in library of assets, along with an online asset platform- compatible with many other applications (live2D)
The Chosen One
So which game engine did I end up choosing?
Although Godot is a great beginner-friendly engine, it just doesn’t have all of the features that I need for creating certain parts of the game. Some of the game puzzles I have planned out (spoiler alert) will be using 2.5D graphics. Additionally, some of the in-game animations that I will be incorporating into the combat/story systems use Live2D which simply is not compatible (yet) with Godot. Finally, as a beginner game developer, I will be relying mostly on tutorials (and my amazing advisors of course) for troubleshooting and learning about different features. The number of tutorials that are up-to-date for Godot pales in comparison to the amount that Unity has. And thus, the final decision was made to choose Unity.
Weekly Game Review, File 01: GRIS
First impressions:For some context, GRIS revolves around a girl who is navigating through the stages of grief. As you progress through the game, you see Gris grow emotionally and this is reflected in the gameplay. At its core, GRIS is a 2D platform puzzle game, with a side-scrolling mechanism. What really stood out to me about the game mechanics were the way they reflected emotional growth within Gris. As you navigate through each stage, color is slowly added to reflect new emotions, along with challenges that reflect those you would face in each stage of grief and skills to help combat those challenges. For example, in the anger stage, Gris is periodically confronted with red sand storms which blow her back and these can be a metaphor for emotional fluctuations within Gris.Although, I have only played through the beginning of GRIS, I think it is a beautifully created game that I would definitely recommend.
Looking into the Future
For the next step in the operation, I will begin creating the actual game, starting with characters. Next week's blog will start with an introduction to the main character and include my process in setting up their movement and animations (and maybe skills if I have time). Additionally, I will be analyzing Omori's use of game mechanics. I hope you enjoyed reading my analysis on Godot and Unity and my review of Gris. See you next time!
Post 3: Week '003': The Art of Dismemberment
Hello and welcome to week 3 of Themedior! Today, I invite you to a first-hand observation of the dissection of our main character: Cynefin. I will begin with an explanation of the importance of dividing up body parts, and the basics of the skeleton, bones, and skin. In other words, I invite you to a beginner’s guide to skeletal animation and the beginning of my operation of animating Cynefin.
File 02: Skeletal Animation
For most of the game animations, I will be harnessing the powers of math, complex algorithms and a huge amount of geometry in an animation technique known as: skeletal animation. Unlike traditional frame-by-frame animation, which requires you to draw each frame individually by hand, skeletal animation uses a skin(a visual layer) and a skeleton composed of bones, which animates/deforms the skin. And the process of creating all of this is known as rigging. So hold on tight as I take you through my process of dismembering and rigging our main character, Cynefin.
Parts and Their Significance
The first step after creating and drawing our main character is to dismember him. Quite literally separating his arms and legs to even the two eyelids on each eye onto different layers. After all of that effort, he should look like this. The same as before.
Before | After
However, do not fret! It may look the same to us, but for Unity and Live2D, it looks something more like this.
Live2D | Unity
These are the texture atlas and sprite map which are used by the software for the skin/mesh.
“But why?”, you might ask. By separating each part, I am able to individually assign them to specific deformers and bones and give them their own meshes. This way I can choose which parts affect each other and which parts don’t.
“But what are deformers/bones and meshes?”, you might ask. Another great question, which I shall address in the next section.
Skeletons, bones, and skin
Now that we have divided our beloved main character into parts, we shall start rigging him, with the first step being skinning. And now to go through the steps of rigging…
To start us off, we have the skin/mesh. Before we can do anything else with our character, we must first skin him. Skinning is the process of generating a mesh for each individual part of the character. The mesh is composed of vertices that stretch and shrink the parts. Think of a mesh like a net. If you stretch one of the holes in a net, you affect all of the other holes around it.
An example:
Now that we have our meshes, we can move on to add bones and deformers.
Deformers/bones are what allow us to add movement/distortion to the character. Additionally, it allows us to deform parts/objects together. For example, if you create a deformer for head rotation, you would want to apply it to only the head parts (eyes, hair, etc.) and not the legs. This is where dividing your sprite and creating a proper mesh comes into play.
Live2D | Unity
And voila, we end up with this monstrosity! Although these may look really complex, they can currently only perform basic movements, as of right now.
“But what if we move the upper arm, does the lower arm move in relation to it?” Yet another great question. That comes down to the skeleton, a.k.a. The hierarchical system of bones. Bones/deformers are often never independent of each other. You can link them and add them as children of each other so that the parent bone/deformer also affects the child.
File 02.5: beyond rigging
Now that we created the rig, our main character can now move! But that was only the beginning. To establish his basic movements, we need to set up parameters and weights to allow the bones and skeleton to deform/move the character the way we want it to. Additionally, when thinking of movement, we need physics. I'm not gonna go into it since this post is getting really long, but I will show you some of the results.
“Good Morning, See You Tomorrow”
That’s all for this week and I hope you learned a little bit about skeletal animation! Since I didn’t have time to finish adding character skills this week, I’ll include that in next week’s post. In addition, I will be creating the basic character interactions and enemies. See you then!
sources:
if you want to learn more about skeletal animation:
Week 4: The Action Begins
Welcome back to my Senior Project Themedior! Today, I will be reporting on the progress I have made in my operation of adding movement to our main character, Cynefin. Starting off with a Q&A and an explanation of how Unity imports PSB files and finally to my struggles with the animator and scripting movement.
Q&A
Q: “Which parts of the process are being accomplished in Live2D and which parts happen in Unity?”
A: For the game, we plan to include some cutscenes which will be animated in Live2D Cubism but the actual game sprite of the main character (which I included in last week’s post), will be animated in Unity.
Q: “Are the parts separate or integrated together?”
A: As mentioned in my previous post, I divided the sprite for our main character, Cynefin into different parts. Each of these parts are separated onto a different layer and sorted into folders based on their relation (e.g. one folder may contain all the parts of the head (eyes, hair, etc.) and another folder may contain the right leg (right lower leg and right upper leg)). These layers are then exported as a PSD file for Live2D Cubism or a PSB file for Unity. As PSB/PSD files, these layers/folders don’t have any relation to each other. But once imported into Live2D Cubism or Unity and rigged, the layers are linked to bones, deformers, and skeletons which integrate them together. I will be talking more about how the layers work in Unity in this post, so look out for that!
PSD Importer
Something I didn’t have time to mention in my previous post was how to import the multiple layers. In order to properly import our main character, I used a built-in importer called, “2D PSD Importer.” Unlike the name suggests, the importer actually takes PSB files by default, although it can also take PSD files. This importer allows me to preserve the layers in my PSB file and generates each layer as a separate sprite rather than merging them all into one. So technically, the main character sprite is composed of many other sprites under a parent game object.
Animation and Animator
For any kind of animation you create, keyframes are an essential step to map out motion and for ensuring smooth movements. For each animation, I created a new animation file and set up the frames like this. Each dot on the timeline is an individual keyframe and each row is used for moving a different bone/rotation.
(These are the keyframes for just the running animation.)
Once the keyframes are added, I finetune the movements to make sure they are smooth and loop properly. Finally, once I finish setting up all of the animation files, I end up with these animations.
walking | jumping | running | shooting
However, this is just the beginning of getting Cynefin to complete actions. After creating the animation files, I set up the animator, which controls triggers and transitions for the motion. In the animator, each animation is treated like a node and you start off with the “entry” and “any state” nodes. The “entry” node dictates which animation plays by default and the “any state” mode lets you set an animation that can be transitioned to at any state.
After adding each animation as a node to the animator, I link them all together based on desired transitions and set up conditions for transitions between the animation nodes. Initially, I had some trouble getting the animations to transition properly. I was able to fix this after tinkering with the exit time of the transitions.
In the animator, another option you have is to add layers. This allows me to add blinking to the character and overlay attack animations no matter which animation is currently being played for the character.
Scripting Movement
The next step to getting these actions to actually work in the game is to create a character controller script. Within this script, I declared Input Actions, which allow me to detect what keys are being pressed, the animator, for playing the animations, and the rigidbody, which I will be using to move the character.
For changing the animation, direction, and speed of the character, I used the update class, which runs once per frame.
However, for motion, I used the FixedUpdate function, which is in sync with the physics engine and won’t cause varying physical effects based on engine load.
And finally our character is ready for action! (note: I haven’t added physics yet, so the jump animation doesn’t actually lift him off the ground).
Continuing On
And that is basically all I have accomplished this week. I hope you enjoyed the gifs of our main character moving around. For the next step in this operation, I will be working on the projectile system as well as developing the dialogue system. See you next time.
Week 5: 'Trash Mobs'
Hello, and welcome to week 5 in our operation of designing Themedior! At the top of today’s agenda is a Q & A. Then, I will be discussing implementing our main character’s attack/projectile system, health bar, and scene changes. Finally, to finish things off, I will talk about enemy creation.
Q&A
Q: “When you say that the animator treats animations as a node, does “animations” refer to parts of a whole animation, or separate complete animations that transition into each other?”
A: For the animations in Unity, I created separate complete animations (refer to the gifs of jumping, walking, running, and attacking) and each of these animations would be treated as a node in the animator. In the animator I can set a default animation that plays on start and then transition to different animations using triggers and parameters. Essentially, the animator is a tree consisting of animation nodes.
Q: “Are PSD and PSB files just file types for animations specifically?”
A: PSD and PSB files are not just used for animations. PSD/PSB files are also used in digital art and digital design as they often require the use of multiple layers.
‘The Attack Begins’
For our main character’s attacks, he will be shooting bullets out of his gun. Creating the bullet sprite and scripting it to instantiate on a mouse click and move was easy but getting the bullet to appear like it was coming out of the gun was a lot harder.
Initially, I tried adding a Rigidbody component to the gun and getting that component in the parent script. However, this didn’t work as the rigidbody resulted in the gun not moving with the player anymore. After tinkering around for a bit and with the help of google, I was able to get the bullet to start at the gun position using “GameObject.find(“gun”).transform.position”. This looks in our parent game object for a child game object called “gun” and finds the child object’s position using “transform.position”.
Getting the bullet to spawn at the gun’s location was only the first step of the challenge; I also needed to delay the bullet’s spawn time to match the animation. To do this, I changed my method from void to IEnumerator. This enables me to use a coroutine to trigger a wait time.
Finally, so that the bullets don’t destroy themselves when coming into contact with the player, I placed the player sprite and bullet sprite into separate layers and configured these layers in the settings to not interact.
Change in Scenery
Another thing I accomplished this week was creating a UI and a scene manager. The UI only contains the health bar for now but I’ll eventually implement a pause button. The health bar contains its own script for decreasing based on player health and it currently looks like this.
The scene manager essentially just contains methods that change scenes. I then add this script to an empty game object and link this game object to buttons and select the function that I want to execute on button click.
‘Invincible’
As of this week, I have created the basic enemy movements, but haven’t implemented a health system for the enemy, so the enemy is currently invincible. Additionally, The enemy can’t initiate attacks yet, so the player is also technically invincible. I will probably implement the damage system next week, so the player and the enemy will no longer be invincible.
here is what it currently looks like.
Week End
That concludes my progress for this week. Next week, I will be moving onto finishing the damage system and starting on the dialogue system. Additionally, I plan to add gravity so that our main character can finally jump. See you next time.
Week 6: Becoming Mortal
Hello and welcome to the 6th week of my senior project! As of this week, gravity now exists and our main character and enemy are no longer immortal. Additionally, the dialogue system is now in development and, in its current state, is just a bunch of canvases and panels layered together.
For this post’s agenda, I will be talking about how I accomplished the things mentioned above and what future me will (try to) accomplish in the next week.
Becoming Mortal
As I mentioned in the first section, our main character and enemy are no longer immortal and can now kill each other. (yay!) To achieve this, I gave the enemy projectiles and added methods for detecting anything that collides with either the enemy or main character. Finally, I added a health bar to the enemy. Below, I will be explaining how I accomplished each of these things.
Projectiles
For the projectiles, I did basically the same thing as I did for the bullet, the only difference is the script. The bullet shoots in the direction of the gun, while the projectiles shoot towards the player. In order to get them to shoot in the player’s direction, I created a game object reference to the player. However, rather than referencing the whole player gameobject, I only referenced the chest sprite. This is because transform.position, which I used to aim the projectile, is based on the pivot point of the sprite. By using the whole player gameobject, the enemy would basically be aiming at his feet, but, by using the chest sprite, It centers the aim.
And this is the final result.
HealthBar
For the enemy health bar, I created a canvas containing a healthbar frame, and two healthbar components. Then I attached a script to the canvas to animate it.
For the enemy health bar, I used a coroutine to adjust the timing of the two healthbars. Based on whether the HP is decreasing or increasing, I set the bottom or top bar to decrease first. For the second bar decrease, I used a while loop for decreasing its width to create a gradual effect.And it turned out like this.
Collisions
This method detects things that collide with the enemy sprite. It takes in the object that collides with it as a parameter and I then check if that object is either the player or a bullet. Based on that, I deduct player or enemy health.
Similarly, this method detects if anything collides with the projectile. If the object that collides with it is the player, it deducts player health.
Dialogue
Essentially what I have for the dialogue system now is just a bunch of panels and canvas, but I can explain what each of them does. For the dialogue scene we have two cameras instead of one.
This allows us to have a camera that shows the UI elements and one that doesn’t. Now for the canvas, we have two of them too, main and overlay. Overlay is used for the UI elements, such as buttons, and main contains everything else that appears on screen. Within the main canvas, we have multiple layers each in charge of a different visual element. This allows me to organize my scene and keep track of different elements.
Next agenda
For next week, I plan to continue working on the dialogue system and creating some animations that will be used for the background in the side-scroller. I hope to see you next week, as I report back on my operation!
Week 7: The Art of Building Text and Scrolling
Hello and welcome back to my senior project. I have finally reached the point in my operation where I must work on finishing the combat system and dialogue system. Both of these tasks will extend over into next week and the foreseeable weeks of this project and that is what I will be talking about in this post.
Buttons, Layers, and Text
In the previous post, I briefly went over what the different elements in the dialogue scene were for, however, I didn’t actually have anything in the elements. Well, that has changed as of this week and now we have buttons, a background, and a character. These are all just placeholders to help visualize what the actual dialogue scene will look like.
We still haven’t finalized all the buttons that we plan to include and Ellie is currently working on creating a more visually appealing dialogue box and buttons.
Dialogue System: Becoming a Text Architect
So for the dialogue system, instead of using a dialogue system asset from unity, I decided to build my own. Now the main considerations when I made this decision were that there honestly weren’t any decent dialogue assets on unity that were free. Additionally, implementing my own dialogue system allows for so much more freedom and customizability. For creating this dialogue system, I referenced Stellar Studio's "Make a Visual Novel in Unity 2023" playlist to understand what components would be necessary and how to implement them.
Dialogue Blueprint
For my dialogue system I currently have 4 scripts/classes, textArchitect, dialogueControl, and dialogueSystem for changing and displaying text and a tester class to actually create the architect object for testing.
Text Architect
The textArchitect class is the main script/component of my dialogue system. It is in charge of making the text appear on screen based on the build method. The build method essentially controls how the text will appear on the screen and I currently have three build methods(typewriter, instant, and fade), but I have only implemented ‘instant’ as of this post.
Dialogue Control & Dialogue System
The dialogueControl class is just used for creating references to the UI elements responsible for the text and is serializable, meaning it allows me to load and save data to and from the object as well as making these properties visible in the inspector. The dialogueSystem class generates a dialogueControl object and is a singleton, which essentially means that there is only one instance of itself at any time and this instance is a variable that is globally accessible.
Tester
This class contains an array of strings for testing and creates a new instance of the dialogueSystem for testing. With this instance it then generates a textArchitect object and calls the build method every time the space key is triggered.
The Art of Scrolling
For the combat part of the game, I am planning to create a side-scroller. Essentially what I plan to do is have the camera to follow the player around. I am currently working on the script for the camera but I have already imported the backgrounds into the game.
Scrolling to the next week
As I move into the 8th week of this project, I plan to keep working on the camera scroll system and finish up the rest of the dialogue system. Additionally, if possible, I will also try to finish laying out the UI for the opening, defeat, and dialogue scenes. That’s all for this post and join me again next week as I struggle to get the camera scroll to work.
References
"Make a Visual Novel in Unity 2023." Youtube, uploaded by Stellar Studio, 27 Jan. 2023, youtube.com/playlist?list=PLGSox0FgA5B58Ki4t4VqAPDycEpmkBd0i&si=eN64qJUApQ61-4rc.
Week 8: New Abilities Unlocked: FileReader and Scene Manager
Hello and welcome to week 8 of my senior project! In this post, I will continue talking about my progress with the dialogue system as well as the side-scrolling mechanism. Additionally, I will discuss the different scenes that I have implemented and plan to implement.
Instant, Typewriter, and Fade
As I discussed in the previous post, my dialogue system has three text display/build methods: instant, typewriter, and fade. I have finally finished implementing all of them and this is what they currently look like.
Instant | typewriter
fade
For the typewriter and fade display methods, they also have a 3-click system; essentially, on the first click the next line of text displays, on the second click the speed that the text displays increases, and on the third click, the rest of text instant displays on the screen.
Beyond just displaying the next line of text, the dialogue system also has the ability to append text to an existing line. This allows me to display the next line on the screen while the previous line is still displayed. Again, I referenced Stellar Studio's "Make a Visual Novel in Unity 2023" videos to understand how to do this.
Reading Files and Parsing Dialogue
One of the most crucial abilities that our dialogue system needs is reading and parsing text files. For the dialogue system that I am implementing, I currently have two ways for the system to read and access files: either as a text file or as a text asset. The text file reader uses the file location and a stream reader to read lines, while the text asset loads the text file and uses a string reader to read lines.
Another thing I implemented in the dialogue system is a parser. This parser essentially separates the speaker, dialogue, and commands in each line of the text file. By doing so, it allows me to change the visuals on screen and display certain things based on the commands.
Scroller
This week, I also managed to finish the camera scrolling aspect of the side-scroller. It essentially just takes the position of the player and changes the value according to that. To prevent the camera from moving off screen when the player moves to the edges of the scene, I used a clamp which essentially limits the value that can be given for the camera’s x value.
Beyond getting the camera to follow the player, I also finished setting up most of the visual components of the scene. I also added a secondary scene for the side-scroller as the character enters the tunnel. I will talk more about the different scenes in the next section but here's how it looks currently.
Scene Manager
As you may recall from the week 5 senior project post, I briefly mentioned the scene manager. To recap, the scene manager contains all of the functions for changing to certain scenes and this class can be referenced through the scene change prefab. As of right now, the game has 5 scenes in total:
An opening scene | A dialogue scene
Two scenes for the side scroller
And a defeat scene
Most of the scenes have triggers or buttons to move from one another, but i am still working on incorporating the dialogue scene and adjusting some of the button functions.
Leveling Up and Moving On
That's pretty much all I completed this week! I hope you enjoyed seeing the dialogue system in action as well as the various scenes I have in the game currently. Moving on to next week, I plan to finish up the parser and display systems for the dialogue system, as well as, setting up and configuring the different obstacles that our main character will have to face in combat. See you next week!
References
"Make a Visual Novel in Unity 2023." Youtube, uploaded by Stellar Studio, 27 Jan. 2023, youtube.com/playlist?list=PLGSox0FgA5B58Ki4t4VqAPDycEpmkBd0i&si=eN64qJUApQ61-4rc.
Week 9: Parsing Dialogue
Hello and welcome back to another week of Designing Themedior: Game Mechanics and Puzzles! This week, I made some progress with the dialogue system as well as some mechanics and graphics within the side-scroller. I will be discussing that along with how I will be moving forward next week with this operation.
Dialogue Parser and How It Works
As I mentioned in the previous post, I have been working on a dialogue parser to separate the speaker, dialogue, and commands in the text files.
The format I have the lines written in is shown below.
Speaker “quote here” commands(argument)
How it works is that it first takes a line and finds the start and end of the dialogue based on where the quotation marks are located. Then using Regex, I specify a command pattern and find matches in the line. Lastly, I find the speaker based on the dialogue start/end and command start. In order that it doesn’t flag quotations in the dialogue as the start/end, I check for whether or not the quotation is escaped.
An issue that may come up is if the dialogue has quotes in it.
To check if a quotation is located within the dialogue, I check if it is escaped. When writing strings in C#, in order to use special characters such as “, you need to put two backslashes in front of it to signify that it is part of the string. Using this, I can make sure that it is actually the end of the quote or if it's just a quotation within the dialogue.
Here’s how it looks:
Mechanics and Graphics
For both the main scene and the tunnel scene in the side-scroller, I added some extra graphics and animations for some detail. Additionally, in the tunnel scene I set up some obstacles that our main character will need to jump over in order to get through.
Into the Future
For the following week, I plan to finish the dialogue system, as well as getting the enemy placement done. I’m also gonna try to finish up the functionality on the buttons in the dialogue scene and begin working on separating the dialogue into different scenes. I’ll see you next week for more updates on this operation!
References
"Make a Visual Novel in Unity 2023." Youtube, uploaded by Stellar Studio, 27 Jan. 2023, youtube.com/playlist?list=PLGSox0FgA5B58Ki4t4VqAPDycEpmkBd0i&si=eN64qJUApQ61-4rc.
Week 10: Who, Where, When
Hello, and welcome back. This week I will be talking about the character system. As of my current progress, I have finished connecting all of the scenes together, as well as incorporating all of the dialogue and characters. I will be discussing this along with my plans for next week.
Active characters and backgrounds
As I mentioned in the previous post, one of the sections in the lines of dialogue is commands. Using this, I can read commands directly from the dialogue file and match those to existing commands within my script to set the active characters and backgrounds.
Dialogue boxes
Another small feature within the dialogue system that I added was separate name and text boxes. Adjusting some of the code, I can hide the name box if the narrator is talking or show the name box when a character is talking.
Following along
Another thing I worked on this week was a target tracking system for my enemy. When the main character comes within its detection range it should start moving towards them and attack. Once the main character moves out of the detection range, the enemy should go back to normal.
Play-Testing
This week, I managed to get some people to play-test our game. Although the combat system is still in progress, I was able to get some suggestions on character sizing, lighting, and the appearance of the UI. Moving into next week, the game should be fully ready for play-testing!
The Final Stretch
As we go into the final week of this operation, I will be finishing up the enemy as well as fine-tuning the appearance of the dialogue scene. Thanks for reading, see you next week!
References
I used these videos from Stellar Studio to understand how to create a dialogue system.
"Make a Visual Novel in Unity 2023." Youtube, uploaded by Stellar Studio, 27 Jan. 2023, youtube.com/playlist?list=PLGSox0FgA5B58Ki4t4VqAPDycEpmkBd0i&si=eN64qJUApQ61-4rc.
Week 11: D-Day, W-Week
Hello and welcome back! This week, I will be discussing the incorporation of a tutorial, the addition of an ending scene, and a new enemy!
Tutorials: A Guide to Side-Scrollers
Currently, I am working on incorporating a tutorial for the side-scroller aspect of the game. This will inform players of the basic movement/attack mechanisms, as well as their objective in the combat system.
Final Scenes
beyond tutorials, I also worked on adding a final dialogue scene after our side-scroller scene. This scene will be the final scene in the prologue of our game and will include some hint about the mystery that our main character is trying to solve!
Atwater: Trashmob 2.0
I have finally incorporated another enemy within our side-scroller! However, this guy is a little bit different, Instead of fighting him, players will need to chase him down. He first appears at the beginning of the side-scroller and at the very end were players finally catch him. As players chase Atwater, his eyeball minions (refer to the trash mobs post) will spawn in to stop players.
(Nearly) At the End of the Journey
I hope you enjoyed following along in my operation: Designing Themedior! As we near the end of this project, I hope to polish out my game and finish up any final touches like the tutorial and ending dialogue scene. Stay tuned for the final product and a play-through of our finished game!
Week 12: Everything That Has a Beginning Has an End
Hello and welcome back! This is the final week of my senior project and also the final post. I will be talking about some finishing touches I added to the game as well as a video of the final product: our game prologue!
Let's Make It Flashy!
One of the final touches I added to the game was tutorial pauses within the side-scroller combat system. This freezes the player once they spot Atwater and when they spot Atwater's eyeball minion in the first half of the side-scroller to explain the movement keys and attack key. At the beginning of the second half, I also added a pause at the very beginning to explain the jump feature for getting over obstacles.
Another tweak i made was adding some additional commands, characters, and backgrounds for the dialogue system. As we finalized the dialogue for the beginning and end of the prologue, we ended up adding some additional backgrounds, elements, and characters. In order to properly incorporate all of these, I added some new game objects to hold the new elements and new commands to show and hide these elements.
The final change I made to the game was some additional scenes and fixing the scene changes. After the side-scroller combat is finished, I created another dialogue scene. After the dialogue scene, I transition players to a To Be Continued scene that takes them back to the opening screen of the game. After tweaking the scripts and buttons, I finished cleaning up the scene changes for a smooth and coherent game.
The Showdown Comes
And now, our final product! This is a video of the full play-through of the game (without the defeat screen). I skipped through most of the dialogue to speed things along, but it still captures the full experience of the prologue.
At the End of the Journey
With that, my senior project has finally come to an end. This project has given me the opportunity to delve the into the field of game development and I have learned quite a lot throughout the process of creating the game prologue. Although this may be the end of the journey with my senior project, it definitely isn't the end of my journey in game development!
As we come to the end of this post, I would like to thank my internal advisor, Mrs. Bhattacharya, and my external advisor, Mr. Utkarsh Singh, for helping me along my journey! Additionally, I would like to thank everyone who has been following my posts.
Thank you for coming along with me on this journey, Designing Themedior: Game Mechanics and Puzzles!
References
I used these videos from Stellar Studio to understand how to create the dialogue system.
"Make a Visual Novel in Unity 2023." Youtube, uploaded by Stellar Studio, 27 Jan. 2023, youtube.com/playlist?list=PLGSox0FgA5B58Ki4t4VqAPDycEpmkBd0i&si=eN64qJUApQ61-4rc.