Product Doc – Sky of Echoes

Chang Liu Product Documentation

Background

Sky of Echoes is one of the two audio-based games the team have developed over the second half of the semester. Unlike the other one, Sky of Echoes uses phone screen as the second layer of interaction and information interface. The game is a story-driven, space exploration game that players use Tap to pilot the ship, collect space junk and gather information and story pieces. The game lasts around 20 minutes with two potential endings based on player’s choice.

Game Design Details

We began by thinking how to break the limitation of the interaction through Tap and come up with the idea of using Tap for “routine” interaction while leaving key moment interactions, which are largely story-dependent, to phone’s screen. We set the story somewhere mysterious in the universe and players have to collect energy for warp drive in order to travel interstellar. Initially, we thought about a shared-world multiplayer game that player can freely drop-in and drop-out without damaging players’ experiences; however soon we realize that this idea would be out of scope. As a result, we went for a single-player experience. The story is about find Earth’s space coordinate and go back home. To map out our control scheme, players in the game have two major target: collecting space junks and gathering audio logs scattered within a interplanetary space. In order to avoid long time-span of no required input, we decided to let players manually power the spaceship similar to a “power generator” fashion. Steering was originally locked to 90 degrees per tap, but later changed to 30 degrees based on the feedback we received during playtest. Moreover, we implement a “lock-on” system that player could lock onto the direction of several key destinations. In the end, we made a 4-act story telling rises and falls of an alien civilization on behalf of the finding the Earth’s coordinate.

Sound Design Details

There were two major aspects to keep in mind when designing sound elements for this experience. One of them was to create a harmonic space theme and the other one was to find the balance between the amount the sound and visual assets.

The harmonic space theme was implemented by having the right tone in dialogue, creating interaction sound assets that are satisfying and futuristic, and composing background music that enhances the feeling of outer space.  We used text to speech translators to record the dialogue to obtain the robotic feeling. To resonate with that, our sound effects are created in a sci-fi way and are satisfying but not fatigue at the same time. We wanted our sound to present immediate feedback as the player interact with Tap. We also wanted the experience to be positive in all. So we used neutral sound rather than negative sound for empty interactions.

Since we are developing with Tap as the interaction device, we wanted our experience to lean more on the sound sound rather than visuals. So every interaction and trigger had their own response. Sound was also deliberately designed to echo with the visual assets to make sure the experience works well in all.

UX Design Details

In terms of UI and UX, we iterated a lot and explored mainly two versions.  In the first version, UX is not as complete as it is now, the entire UX is fully functional. The buttons and text boxes are on three different pages, which required swiping to turn. The UI is also very complex with layers over layers to create a sense of cyberpunk space. However, during the playtesting, we found that the complex interface and all those visual elements increase users cognitive load. It also brings a lot of unnecessary confusion.

Based on the experience, we kept ourselves in mind that don’t overwhelm users with too much information. The most challenging part is the onboarding stage, because Tap itself is a new medium, and audio interactive fiction is also relatively new content. In order to make the experience better, we designed a teaching storyline by combining the screen, audio and tap media where the UI elements on the interface are presented to the user one by one. For example, using the audio to tell users to tap fingers, and the interface gradually reveals when tapping. Additionally, we limited what users can do by using interface and removed functions such as AI assistant dialog. Meanwhile, we would also make corresponding adjustments in the audio content in order to remain the richness of the experience.

The UI and visuals are designed to have high recognition and deliver the mystery space feelings. To be specific, since our target users don’t have obvious age and gender difference, so we chose low saturation colors and designed neutral planets. Some animations such as rotating radar and flashing planet are also designed to indirectly guide the users.

In this overall process, we dealt with the screen interface very carefully along with the tap interface and audio interface. We believe that finding the balance between the visual and audio interface is difficult, but it is also the key to making the whole experience fun, enjoyable and intuitive.  

Implementation Details

For Sky of Echoes, we built up a system to organize the level information. From programming perspective, the level information is defined as a series of events. Given that the game has non-linear story lines, traditional state machine couldn’t simply work in this experience. It could be really time-consuming to keep adding new functions with story expanding, and also difficult to change the audio dialogue’s order if needed. To solve this problem, we designed a special system for it and maintained the system via a csv file. In this way, all the work will just be a well-organized system and the remaining work will just be filling the chart. It saved a lot of developing time and make the system more robust.

The final csv chart for this game can be viewed here.

The component of the chart is a series events, each event is defined by 6 sections:

  • Event Name
  • Event Type
  • Trigger Detail
  • Sound List to Play
  • Add Event List
  • Remove Event List

Event name is the identifier of the event. It is unique.

Event type defines how to deal with the event. In our game, the type is a little complicated. There are 6 basic events. Start defines the entry point of the story, which will set up some initial state of the game. Follow defines the event that will simply follow last event from add on list. Tap means the event will be triggered by tap. Trigger means the event will be triggered by in-game trigger. Screen means the event will be triggered by touch input. And End defines the exit point. There are also 10-89 defines many in game change, which means the event will modify player’s attributes. It doesn’t have common meaning, which should be changed to some local script function to make it more universal. OnetimeEvent is the event that will only happen one time because the experience is not linear, it needs this mechanism for special cases. Error is for remove the event from the event table. Simply assign the negative value of the state can make the event state become Error which will in a way realize the function of removing one event.

    public enum EventState
    {
        //Basic Event
        Start = 0,
        Follow = 1,
        Tap = 2,
        Trigger = 3,
        Screen = 4,
        End = 5,

        //In Game Change
        VelocityLerp = 10,
        VelocityLerpTo = 11,
        VelocityTo = 12,
        VelocityLock = 13,
        AngleLerp = 20,
        AngleLerpTo = 21,
        AngleTo = 22,
        AngleLock = 23,
        PositionTo = 30,
        SetCoord = 40,
        ClearCoord = 41,
        RandomSound = 50,
        CollectSpaceJunk = 60,
        CollectPC0 = 61,
        CollectPC1 = 62,
        CollectPC2 = 63,
        CollectMU1 = 64,
        CollectMU2 = 65,
        ActivateEnd1 = 66,
        Tutorial = 70,
        TutorialSkip = 71,
        Task = 80,
        TaskAtMoment = 81,
        TaskAtMomentFail = 82,

        OnetimeEvent = 90,

        //Error Input
        Error = -1
    }

Trigger Detail is different recording to different Event Type. For Follow Event, the detail will be second which indicates the time delay for this event to trigger after last event. For Tap Event, the detail will be one integer which indicates the combination of finger in this case. For Trigger Event, the detail will be the coordinate of the trigger object in game scene, and the radius of the trigger sphere. For Screen Event, the detail could be click, press, release and all kinds of different type, but in our case it is only click, so there isn’t detail for this type of event. For In Game Change Event, the detail will indicate how exactly it will change the player’s state. For example, VelocityLerp Event’s detail is how much the velocity change is. In this case, all trigger detail is defined clearly which will make it clear for the trigger effect.

Sound List to Play is a bunch of sound in a form “s_[file_name]” that has “s_” at the beginning indicating it is a sound info. Followed is the file name that the sound will automatically be loaded to game that won’t require Unity Editor replacement. To play the sound, they are divided into two three types: Narrative Sound, Effect Sound, and Loop Effect Sound. Narrative Sound can not be played at the same time, so there is a stack that controls the logic of Narrative playing. The Effect sound can be played with or without other sound, so each time it will instantiate a new AudioSource to play the new Effect. Especially, when there is Narrative playing, the Effect’s volume will be smaller. The Loop Effect can be stop via certain function, which is slightly different with regular Effect.

Because the experience is not a linear one, so the function of adding and removing events from accessible events list is needed. For example, without certain items, player can’t trigger the event in certain planet.

Add Event List is a bunch of events in a form “a_[event_name]” that has “a_” at the beginning indicating it is an add event. This event will be added to the accessible events list for current state. If the add event is a following event or other in game change event that is an instant working one, it will simply operate after this event is acted. Event like Trigger and Screen will only be set active in game, and to trigger it, player still need to finish the certain move required by the event’s detail. Add will result as set the event type to its positive value.

Remove Event List is a bunch of events in a form “r_[event_name]” that has “r_” at the beginning indicating it is a remove event. This event will be removed from the accessible events list for current state. Remove will result as set the event type to its negative value, which will be error and ends with not operating that event.