Two perspectives, one shared emergency, and the engineering behind a real-time evacuation simulation.
A fire evacuation is not just a problem of finding the nearest exit. It is also a problem of understanding what is happening across a building, communicating information, and coordinating people who see the same emergency from different perspectives.
We wanted to explore that problem through a browser-based simulation.
CampusEvac was our attempt to turn an evacuation drill into an interactive, real-time experience. One participant navigates the building as an evacuee, while another observes the scenario as a warden. Both interact with the same simulation, but neither sees it in quite the same way.
We built CampusEvac during First Commit, a WeMakeDevs hackathon, and our project was recognised in the Best UI track.
This is a look at the problem we chose, the architecture behind the application, the design decisions that shaped the experience, and what building a real-time product taught us.
Why Build an Evacuation Simulator?
Emergency preparedness involves more than documenting procedures. People need opportunities to understand their environment, practice decisions, and become familiar with how an evacuation might unfold.
Physical drills serve an important purpose, but organising them requires coordination and a suitable environment. We wanted to explore how a browser-based simulation could provide another way to practise and understand evacuation scenarios.
That led us to a question:
What if two people could participate in the same evacuation drill from completely different roles, directly in their browsers?
The answer became CampusEvac.
Instead of creating a static building map or a conventional monitoring dashboard, we designed a two-player experience with a shared environment and role-specific interfaces.
The project had three central requirements:
- A navigable building environment for the evacuee.
- An overhead monitoring interface for the warden.
- Real-time communication so that both participants could interact with the same evolving simulation.
These requirements shaped both our interface design and our technical architecture.
Two Roles, Two Different Interfaces
One of the most important decisions was to avoid treating the evacuee and warden as two versions of the same user.
They have different responsibilities, different information needs, and different ways of understanding the building.
The evacuee: navigating the situation
The evacuee interacts with the environment from a first-person perspective.
The interface needs to keep the building and navigation experience central, allowing the participant to understand their surroundings and make decisions without unnecessary interface clutter.
The warden: understanding the bigger picture
The warden sees the building from an overhead perspective.
Rather than navigating from ground level, the warden needs to understand the broader scenario and observe what is happening across the environment.
That calls for a different information hierarchy, a different layout, and controls designed around monitoring rather than first-person movement.
Why the distinction matters
A role-based application should not simply change a heading or swap a few buttons when the user changes roles.
The interface should reflect what that person needs to accomplish.
For CampusEvac, we treated the two perspectives as complementary parts of the same experience. The evacuee focuses on navigating the environment; the warden focuses on observing the wider situation.
This principle extends to many other applications, from collaborative tools to logistics dashboards and real-time monitoring systems.
The Real-Time Problem
Two browser windows showing the same building do not automatically create a shared simulation.
When participants interact independently, the application needs a way to communicate changes, manage connections, and keep the experience coherent.
For CampusEvac, we used AWS AppSync Events for real-time communication and Amazon DynamoDB for application state.
At a high level, the architecture consists of three main parts:
| Component | Responsibility |
|---|---|
| Browser application | Provides the evacuee and warden interfaces |
| AWS AppSync Events | Enables real-time communication between connected participants |
| Amazon DynamoDB | Stores application state persistently |
The distinction between real-time communication and persistent state is important.
A message can communicate that something has changed, but a message and a durable record of application state are not the same thing. A robust implementation needs to define which information is persisted, how updates are propagated, and what happens when a participant disconnects and returns.
These questions become especially relevant in collaborative applications, where the experience depends on multiple clients interacting with shared state.
Our architecture gave us a foundation for combining a browser-based simulation with AWS-managed real-time communication and persistence.
Why UI Was More Than Visual Polish
The Best UI track gave us a reason to look closely at what makes an interface effective in the first place.
It is tempting to equate good UI with gradients, animations, typography, and polished components. Those elements can contribute to the experience, but they do not replace clear interaction design.
CampusEvac has an additional challenge: the interface needs to communicate a situation that changes over time.
The evacuee needs an interface that supports navigation. The warden needs an interface that supports observation. Both need to understand that they are participating in the same simulation.
That makes several design considerations particularly important:
Role clarity. Participants should be able to understand their responsibilities from the interface they are using.
Information hierarchy. The most relevant information should be easy to distinguish from secondary controls and status indicators.
Contextual feedback. Changes in a shared environment need to be communicated clearly enough that participants can understand what has happened.
Functional consistency. The interface should remain understandable while the application is running, not merely in a static screenshot.
The central idea is that UI quality depends on how effectively an interface supports its intended task.
A visually polished interface is useful. A visually polished interface that also communicates the system's behaviour is more useful still.
Building Under Hackathon Constraints
Hackathons require teams to make decisions quickly. There is limited time to explore a problem, choose a stack, implement the main experience, integrate services, test the application, and prepare a demonstration.
For CampusEvac, we concentrated on the core interaction: two roles, two perspectives, and one shared simulation.
We also incorporated AI coding agents into our development workflow.
These tools helped accelerate implementation, but generating code was only one part of the process. The application still needed architectural decisions, integration work, and testing across its different components.
A component can render correctly on its own while the complete application behaves incorrectly when two participants interact simultaneously.
That distinction matters particularly in real-time systems. Testing an individual interface is not a substitute for testing the relationship between connected clients.
Our experience reinforced a useful principle: AI-assisted development can reduce implementation effort, but it does not remove the need to understand the system being built.
The quality of the result still depends on defining the problem clearly, making sound decisions, and verifying that the pieces work together.
What We Would Improve Next
CampusEvac gave us a working foundation, but a simulation of this kind has several areas worth exploring further.
Some possible directions include:
- Larger building scenarios: More detailed environments that allow for varied evacuation routes and layouts.
- Clearer monitoring interfaces: Better ways to communicate the overall state of a drill without overwhelming the warden with information.
- Reconnection handling: More robust behaviour when a participant leaves a session and later returns.
- More extensive real-time testing: Testing concurrent interactions, changing connection states, and the consistency of shared information.
These are potential improvements, not claims that every feature is already implemented.
The broader challenge is to make the simulation useful beyond a successful demonstration: predictable behaviour, understandable interfaces, and a system that remains coherent when real users interact with it.
The Result: Best UI at First Commit
CampusEvac was recognised in the Best UI track at WeMakeDevs' First Commit hackathon.
For us, the project brought together several areas of engineering: interface design, browser-based interaction, real-time communication, persistent state, and AI-assisted development.
The recognition was a milestone, but the process was equally valuable. It gave us an opportunity to think about how design decisions affect a product's functionality and how architectural choices influence the experience users ultimately see.
I'm grateful to WeMakeDevs for the opportunity to participate, and to my teammates Afreen and Akshay for building CampusEvac with me.
Try CampusEvac
The best way to understand the project is to explore the two perspectives and see how they fit together.
- Live demo: Explore CampusEvac
- Demo video: Watch the walkthrough
- wemakedevs: showcase
CampusEvac started with a simple idea: make an evacuation drill interactive and shared. Building it taught us how much work goes into connecting the interface, the underlying system, and the experience of the people using it.
That is what made this project worth building.
Built by Abhishek M. Shivanagoudar, Afreen, and Akshay for WeMakeDevs First Commit.
Top comments (0)