addiemakesgames

addie

@addiemakesgames

making games for the xbox 720


Project Space Capitalism (extremely tentative title) is a new game in active development from Cel Davison (Humble Grove), Rebecca Michalak, and myself (Adrienne Lombardo). It follows two lesbians who find an old abandoned cruise-space-ship and raid it for anything of value. As they delve deeper into the ship they become further and further corrupted by the last remaining clutches of capitalism.

The game is comprised of two types of scenes, “Grand rooms” and “Service tunnels”. In grand room scenes the player takes control of the character’s torches, by moving the cursor where they would like the torch to be directed. In doing this the player will be able to find objects or areas of interest for the characters to talk about. In most cases players won’t be able to observe all interactions in a scene, as at a certain point the characters will be forced to move on for one reason or another. Service tunnels scenes focus on Je (Jessica) and Ju (Julia) and how what they’ve seen has changed them and their relationship with each other, the interactivity here is purely in the text.

This dev log will be reviewing the torch mechanic and dialogue system used in grand room scenes. Progress Showcase

Torch Mechanic

During grand room scenes the characters remain static, except for the torches they carry, which are controlled by the player. Generally one character will hold the “controllable” torch and the other torch will act as an ambient fill light. In some cases both torches may both be controllable and crossing a certain threshold on the screen will switch which torch you control.

In this way it’s better to think of the player as “suggesting” where the characters should look and point their torches, rather than directly controlling them.

Object selection is guided by the player as they move a torch, but the game will not wait for confirmation from the player. Merely directing the torch at a selectable object and having it rest for a moment will cause the camera to zoom in and dialogue to start. Selection can be made less obtuse by using the arrow keys to automatically lock on to selectable objects, but we have designed selection this way as to encourage players not to think too hard about what objects they’re picking and instead picking what they are naturally most interested in or drawn to.

Dead by Daylight’s killer blinding mechanic inspired the visual indication for the torch focusing on selectable objects. Video

How It Works

I ended up using three packages for this feature that did a lot of the work for this feature. Final IK for handling Inverse Kinematics, Sensor Toolkit 2 for its Trigger Sensor and FOV Collider components and Volumetric Light Beam for the torch’s light beam and some particle effects to make things look nice. I could of made a trigger sensor component myself but I already owned the Sensor Toolkit 2 package and it fixes some quirks with the OnTriggerExit MonoBehaviour method.

Let’s get in to how it works!

  1. The first step is to move the aim target, how we control it varies by control type...
    1. Keyboard and Mouse: Moving the aim target using mouse simply raycasts from the main camera using ScreenPointToRay to a custom made “nav mesh” on the wall which blankets objects in the scene and allows the torch to smoothly glide over them (see Example A vs Example B).
    2. Controller: Moving the aim target with controller while maintaining high aim precision needed for focusing on objects was one of the first big problems I faced. I ended up constraining the aim target to a spline and moving it along it based on controller inputs (see Example C vs Example D). Ex A) Placing selectable objects on the torch hitbox layer results in a little jump when hitting objects. Ex B) Blanketing the selectable objects in a “nav mesh” to smoothly move the torch over. Ex C) Keyboard and Mouse aim target movement using raycasting. Ex D) Controller aim target movement using a spline.
  2. If we have successfully moved the aim target the current actor will leave their idle state and begin aiming. Here is where Final IK does a lot of the work with it’s Aim IK component to aim the torch itself and rotate the character as necessary. Based on the scene two actors may be controllable, we check as we’re aiming the torch which side of the scene we are on and swap actors if necessary. Swapping between actors based on torch position.
  3. The prominent actor’s Trigger Sensor component is subscribed to detect GameObjects with the “Selectable” tag that enter/exit the FOV Collider. When a selectable enters the torch’s FOV, focusing will begin after a brief delay to allow the player to “confirm” their selection. If a selectable exits the torch’s FOV before focusing is complete the focus will be canceled. Detecting and focusing on selectables in the scene.
  4. With accessibility in mind I made it so selectables can also be focused on by using the Up and Down arrow keys. This takes priority over aiming the torch manually. Aiming by locking on to targets instead of manually controlling the torch.
  5. Upon focusing on a selectable object, player control is revoked and the torch locks on to a predetermined point on the selectable to ensure consistent lighting when we zoom in with the camera. At this point our scripting solution (Fungus) will take priority over the aim system and handle stuff like camera transitions and dialogue. A simple flowchart block which sets that the selectable has been focused on before returning control to player.

Commented source code for the torch prototype can be found here.

Dialogue System

Je and Ju get their own dialogue feeds on either side of the screen, so that their dialogue holds equal weight. They are the only characters in the game and we explore the ship through their eyes. Dialogue teaches us about Je and Ju’s relationship and how it is being changed by their journey. Player has branching dialogue choices to choose from, either choosing Je or Ju’s lines. Whose lines the player has control over alternates from scene to scene.

Some dialogue choices will be locked from the player. These will be visible to the player, but crossed out with a strikethrough, in order to communicate that the character is either thinking it, but unable to say it, or that it is something that they are incapable of saying. These choices are unlocked/locked by failing/succeeding at skill checks.

Lastly, the ship’s AIs communicate with Je and Ju through pop-up boxes that can appear anywhere on the screen.

Character Stats and Skill Checks

Je and Ju, both have hidden stats which have an effect on the things they are capable of doing or saying. Doing or saying certain things will also change these stats. Having a high or low stat isn’t intrinsically good or bad.

Skill checks are a hidden “dice roll” mechanic whose main purpose is to lock or unlock dialogue choices for the player. Checks are calculated using two random numbers, plus or minus a relevant character stat. Checks may also be used to see if a character can perform a certain action; hacking, sleight of hand, an act of athleticism and so on...

In another case skill checks might be used to determine when a grand room scene ends. Perhaps a character fails a check, gets nervous and decides to move on. Or the character succeeds another check, is curious and wants to see what more they can find.

Accessibility Considerations

Game accessibility is something that’s near and dear to my heart so upon embarking on this project we are agreed to put accessibility first in our designs instead of hacking it in near the end of the dev cycle/post release. The dialogue system features the ability to switch between 3 predefined font sizes, a dyslexic font, and different accent colors for dialogue choices. I hope to integrate screen reader support like we did for No Longer Home’s accessibility update later in the development process.


in reply to @addiemakesgames's post: