DUOLABS
Work

Virtual-space social service

We developed the regular app screens of a virtual-space social service where people dress up avatars, gather in themed spaces such as a conference hall or an outdoor stage, and hold talks, meetups, and performances there. The 3D space is handled by a 3D engine and the service screens, such as account, home, and room entry, by the app, so both sides touch screen transitions and app state. When that boundary slips, what the user sees and what the app believes its state to be drift apart. The work spans the service screens, the boundary between the 3D space and the app screens, and collaboration with a team of more than 100 people.

Launch
2022
Client
A Korean telecom carrier
Type
Media & Community
01 / 04

The 3D space to the engine, the service screens to the app

The virtual-space social app holds, in a single app, a 3D space where avatars move and regular app screens such as account, home, room entry, events, and settings. Users pick their avatar's outfit and build, then open a room with a chosen theme or join one someone else opened, where they share materials and talk. The roles were split so the 3D engine draws the 3D space and the app draws the service screens itself. Picking a room from home, entering it, leaving, and returning home were arranged to flow naturally even as they cross between the two areas.

The 3D space to the engine, the service screens to the app
02 / 04

The seam where the 3D space and the app screens meet as you enter a room

In the virtual-space app, entering the 3D space, switching app screens, the connection session state, and the app going to the background and back all happen on different sides. When the four coincide they can collide, so the boundary where the 3D engine and the app meet was adjusted. Alongside the app-side feature work, this segment was handled so the roles of the 3D space and the app screens never blur.

The seam where the 3D space and the app screens meet as you enter a room
03 / 04

Screen state that can be followed whatever order the signals arrive in

In the virtual-space app, login state, room entry state, network responses, and the moment the 3D engine finishes starting up all arrive at different times. Every screen was built on the same frame, separating user input, server responses, and screen state changes into inputs and outputs, so whichever signal arrives first, you can trace where the screen state changed. That frame later became the standard for designing screen structure in other projects.

Screen state that can be followed whatever order the signals arrive in
04 / 04

Areas of ownership and interfaces settled first in a team of over 100

The virtual-space social service was built by a team of more than 100: app developers plus 3D, server, planning, and QA. On a single platform alone there were seven or eight app developers. For features whose changes spanned several platforms, ownership areas and the interfaces between them were divided first and development followed, with differences in behavior across platforms reconciled along the way.

Areas of ownership and interfaces settled first in a team of over 100

Highlights

01

Service screens for the virtual space: account, home, room entry, events, and settings

02

A boundary tuned so entering the 3D space and switching app screens never collide

03

Screen state that stays traceable when login, room entry, and 3D start-up arrive out of order

Insights

Read the blog