Overview:
Dreams of Disquiet is a game I made in cooperation with Steve Gutierrez in the Unity game engine. The game was made over the course of 6 months (8/18/2021 – 4/25/2022). The Game can be found on itch.io here
Dreams of Disquiet as it stands now is a first person JRPG where the player explores a variety of weird, strange, and disquiting realities. On there adventures they will meet strange inhabitants, battle terrfiying monsters, and begin to slowly unravel the mysteries behind the Agecny currently holding them hostage the reasons they keep coming to these disquiting places.
If any of that sound intresting than I would highly suggest going and playing the game for yourself as the rest of this post is a highly indepth analysis/summary of the games system and will contain massive spoilers.
--Dialogue--
Design Philosophy:
When discussing the design of Dreams of Disquiet we should first talk about the games three primary gameplay loops. Exploration, Combat, and Dialogue. Put a pin in that as we will discuss all three of these loops implementations and design philosophies as we go.
When the player first enters the game they are immediatly introduced to the first of the three primary gameplay loops, Dialogue.
The Dialogue system works just like ay other dialogue tree with the player choosing a response and getting taken to the next piece of dialogue or quiting out of the tree depending on the response. Depending on the sitaution a response will yield either cope or emotional debuff points. The functionality of both of which we will get into during the combat section.
We decided to open with dialogue as it provideds an immedate hook into the games story which is the central modivator for the player. It also gets the player using the WASD keys the first (and most used) of 7 total keys the player will use through out the game.
Implementation of Dialogue:
Dialogue in the game is stored in .txt files and parsed in the game at runtime. The dialogue is written by the designer using google sheets and is download as a .tsv (tab seperated varaible) file that gets convert to a txt file that unity can read. Each row in the sheet contains one dialogue entry that consits of: Content what the other person is saying, response text what the player is saying, cope amount the amount of cope give to the player for picking that respone, and function calls a string of characters used to call function in the code. respone text, cope amount, and function calls is repeated 2 more times for a total of 3 dialogue options.
the function calls section stores a function call or multiple calls as a string like this “C,1*D,2,10”. This example contains two function calls divide by the ‘*’ character. the first call C,1 calls the continue function which jumps to index a given index in the array of dialogue option in this case index 1. D,2,10 calls the debuff function which increases the debuff at index 2 by 10.
This system for dialogue parsing works in engine perfect satisfactory and meets all the criteria that we needed of a diagloue system. My favorite part of the system is the ability to add arbitrary functions to call to any dialogue response as it allows us to change the world in accordiance with the players actions. however the main downside to this system is the production disconnect between designer and engine. Having to go through google docs adds a lot of time to the iteration procces which can slow developement to a crawl. if you want to learn more about these dialogue woes check out my post mort blog post here [INSERT LINK]
--Exploration--
Camera Look:
That agency room is an exceedingly simple space with only one interactable object in the middle of the room and now way to walk around. the level was designed with such simplicity to introduce the player to the first half of the next core gameplay loop Exploration.
We only introduce them to the first half as the mechanics of navigation are designed contrary to first person convention. You see the players camera is controlled by the W, A, S, and D keys with left mouse button being interact/move and right mouse button being inspect. We picked these controls as the inverse of the normal first person controls because we wanted the player to immidetly feel slightly uneasy as now there is a layer of translation the player has to go through that they would have to go with the standard convention that has become second nature.
Movement:
Once the player interacts on the TV they are taken into the level poper and introduced the second half of the exploration loop with movement.
The player moves their selector target in an arc with the further they look forward the higher the arc gets and thus the further the move marker gets. We decided to go with an arc because a standard raycast would have the palyer looking at the ground most of the time.
*Show implementation
Inspect:
*What purpose does inspecting have in the system, how does it tell as story and why tell a story in this way how is it suitable for this game?
*Discus the implementation of the system. How does it fit the criteria above, why design it this way?
Inspecting tells the story by letting the player fill in the game gaps with there own thoughts. We use a print out system instead of a basic put text on screen because it allows more expresiveness in the pauses
Inspectable objects can also serve the purpose of pickups
Interaction:
*Discuss the design philosophy behind this system of interaction, why is it in the game? what purpose does it serve?
*Discus the implementation of the system. How does it fit the criteria above, why design it this way?
We designed the system to be arbitrary and because of that we used Events
--Combat--
Overview:
*Why not turn based combat? why pucnhout?
When designing the combat Steve and I knew we didn’t want to make it a turnbased system.
Dialogue Phase:
*Touch briefly in a sentence or two on why there is a dialogue phase and the importance of it.
*Talk about the nessecery difference if any between dialogue inside of combat vs outside
Power Words:
*Touch briefly on the reason for power words and why they are used. Don’t get into the nitty gritty of game design foucs more on game implementation.
*Why use the scriptable objects for implementation talk about how arbitratiy has shot you in the foot
*What elements fo the system are from a bye gone era. Why keep them around, what changed to make them obslite and or nesscesary
Combat, Damage, Blocking, and Attacking:
*Why use animation for interrupts, why use signals pre built into the animations and how does this all tye together
--Level and Game Managers--
Level Manager Events:
*Discus why the level manager is designed as a singleton what benifits does it have what drawbacks does it have?
*Why use unity events for level events what is the purpose of such arbitraty what limitations do the events have?