top of page
ALEX ILUKHIN
Game Software Engineer - Real-time Systems
The Office Type
About
The Office Type is an office-themed comedy dating simulator with a wide variety of characters to learn about and narratives to explore. I developed new game systems and features expanding the demo into the full game.
Project Info
Role: Game Software Engineer
Duration: 1 year
Engine: Unity
Platforms: Steam, Android, IOS
Developer: Heavy Thought Studios
Game Overview
The Office Type was an interesting and fun project that gave me the opportunity to take my experience with Unity and extend it to a new video game genre, a narrative-driven dating sim. I started working on the project by evaluating an existing demo that was made as a college capstone project. I worked on updating the core functionality of the game as well as adding new gameplay systems and features present in the final product. I go into more detail about certain areas of the game below the overview section.
Here's an overview of what I worked on and what my responsibilities were:
​
-
Implemented various new game systems and features
-
Character roster selection
-
Date Selection
-
Character introduction scenes and functionality
-
Dialogue history
-
Save system
-
Settings
-
Gallery system
-
Multiple Endings
-
-
Updated existing features and core functionality of the game
-
Refactored structure and functionality of game scenes to be data-driven as much as possible
-
Location, time, and day management
-
Game introduction sequence
-
Expanded character data and functionality
-
Extended narrative file formatting properties to dynamically support player dialogue choices and character pose images and their panel positions
-
-
Developed debugging tool to drastically speed up dialogue and ending testing (up to 30x) by allowing testers to directly skip to a specific date of their choosing for a character and also adjust character data values to guarantee specific endings
-
Led effort to deploy game builds to Steam, Android, and IOS platforms and also document studio build processes for future reference
Play the updated demo on steam!
Game structure and core functionality
The first thing I did on the project was to evaluate the existing game's systems and core functionality. A lot of functionality was hard-coded in the initial demo which was problematic, and developing new game systems in this existing structure wouldn't be a good idea. I adopted a data-driven focus for the game where each scene would pull the relevant data it needed on start and then apply and update the data in specific ways depending on the scene's purpose.
The first step was to refactor the game's overall scene structure and functionality related to it. Going forward, every new class managing any data would be a singleton, and existing systems with data would be turned into singletons ensuring a point of authority for each category of game data that would make the structure of the game flexible and easier to manage in the future.
Save system
I decided to keep my approach as simple as possible and use binary save files. I created a manager class to handle loading and saving using Unity's binary formatter functionality as well as save data and game settings data classes holding all the different categories of game data that I would need to store. Because I had manager classes dedicated to handling their own specific kinds of data, it was easy to access and manipulate everything I needed. I spent a lot of time figuring out exactly what order to save or load specific data in and testing every possible edge case I could think of with my system to make sure save states were stable.
Overall, developing the save system was my favorite part of the project because it was the most complex and rewarding work I did. The save UI is shown below.
Characters and UI
The amount of data associated with each character increased quite a bit during development. In addition to expanded functionality interacting with other systems, it made sense to me to have each character class be responsible for holding a lot of their specific data that any relevant game system can access because otherwise the character manager would've been massive and unwieldy. Character classes all inherit from a base class to streamline specific functionality for how other systems interact with character data.
The roster system (character selection) was the first system I worked on that had a corresponding UI. Due to the extra complexity of the interface and the data it was handling, it was logical to me to separate the two. One script would solely handle the functionality of the UI while the other would solely handle the data associated with the roster system. I maintained this approach for all new game systems that had an associated UI.
For the dialogue history system, I placed a hook into the dialogue parser to copy the string and save it into a new list held by the dialogue history manager. Then the manager sent the string to its UI script to place it into the next "chat bubble" slot in the dialogue history window. 100 of these chat bubble objects (essentially each text box you see in the 2nd gif) are created on game start and recycled for each new scene. Each was denoted by where it came from, either the player character or game characters, placed into the correct slot, and adjusted for correct positioning.
bottom of page