Dear readers,
This week, we’re excited to introduce a new learning tool and coding project our lab has been working on! The U.S.-China Trade War Simulation teaches students how domestic politics shapes international bargaining through an active learning model. Students step into the middle of the 2018–2020 U.S.-China Trade War and experience firsthand the challenges of negotiating across both domestic and international political constraints.
In this post, we’ll walk through how the simulation works, how we’ve designed it to fit into the classroom, and what we learned building the web app that now brings it online. At the end, we’ve also attached a sample lesson plan for instructors interested in bringing the simulation into their own classrooms.
Interested in the research behind the simulation? We are also using the simulation as a research tool to study bargaining, issue linkage, and the conditions that contribute to bargaining failure. Our paper, “Issue Linkage and Bargaining Failure: Experimental Evidence from a Trade War Simulation,” examines the experimental data generated through the simulation and is currently under review. If you’d like to learn more about the research behind the project, you can read the print here.
At a Glance
· It works best for intro IR, IPE, U.S.–China relations, or bargaining courses.
· Expect about 2 to 4 class hours depending on format, plus 1 to 2 hours of prep.
· Runs in person, over Zoom, or as a hybrid.
· The class needs at least six students, though it works best with around twelve.
· Instructor prep is minimal. Just read through our briefing slide deck and get familiar with the web app.
· Students should do a short role briefing, watch the Frontline documentary, and can write an optional policy memo.
· All you need is a web browser. No special software required.
· It’s free.
· You can explore the simulation at simulation.tradewarlab.com.
How the Simulation Works
The simulation unfolds in two rounds.
Round 1, Domestic Politics. Students are divided into U.S. and Chinese teams. Within each country team, students are assigned to an interest group representing a different domestic constituency, either a Globalist, a Protectionist, or a National Security Hawk. Each group receives a policy document outlining its priorities, including which issues, such as tariffs, market access, and technology transfer, matter most to them. Groups then negotiate among themselves and aggregate their preferences into a position paper that becomes their team’s mandate for international negotiations.
Round 2, International Negotiation. Armed with that mandate, the U.S. and Chinese teams sit down across the table from each other’s negotiators. They bargain over a joint statement, trading asks and concessions on a shared points scale and trying to reach a deal before time runs out.
Why It Teaches Bargaining Theory
This structure is built around two foundational IR ideas, two-level games (Putnam) and bargaining theory (Fearon). In a two-level game, negotiators must simultaneously satisfy international counterparts and domestic constituencies. Bargaining theory asks why actors sometimes fail to reach agreements that would leave both sides better off than conflict. Fearon’s model was developed to explain military conflict, but the same bargaining logic helps students understand why mutually costly trade disputes can persist.
Every negotiator in a two-level game is effectively bargaining at two tables at once, one with their international counterpart, the other with constituencies back home. For most students, these are ideas first encountered as abstractions in an Introduction to International Relations textbook. Here, they get to experience them instead of just reading about them.
That experience is what makes the constraints of international bargaining tangible. The tension of international politics becomes apparent when the demands of a domestic coalition leave a negotiator with little room to make the concessions necessary to reach an international agreement. A bargaining range is easy to draw on a whiteboard, but much harder to locate when your own side refuses to move. Students watch their bargaining position take shape in real time, seeing how domestic constraints can narrow the potential range between two teams, and when negotiations end without a deal, they see firsthand how the disappearance of mutually acceptable agreements can lead to bargaining failure. In this way, the simulation transforms bargaining theory from an abstract concept into a problem students have to navigate themselves.
What the Web App Does for Instructors
Classroom simulations have a long history in international relations teaching, and for good reason. They’re one of the best ways to turn abstract concepts into something students actively experience. That’s not just an impression from the classroom. A recent experimental study tracking three years of an Introduction to International Relations course found that sections using simulations showed measurable gains in both engagement and objective academic performance compared to sections that used debates and discussions instead. But anyone who has run one knows they can also be a headache. Instructors have to distribute materials, track negotiations, calculate outcomes, collect student decisions, and make sense of it all afterward. We wanted to build something that took that burden off instructors’ plates, a tool they could pick up, run with their own students, and reuse semester after semester without reinventing the wheel each time.
The instructor dashboard handles the administrative work. Role assignments, bargaining positions, votes, scoring, and final outcomes are all recorded automatically, so instructors spend less time tallying points and more time facilitating the simulation and leading the debrief.
What running it actually looks like. Instructors create a class and get a unique class code to share with students, who use it to sign up and create their own accounts. From there, the instructor assigns each student to an interest group and country. There’s no random sorting, so you can build balanced teams or hand a role to the student best suited for it. Once assigned, you control when each round opens and closes, and can watch negotiations unfold live on a progress dashboard rather than circling the room guessing who’s stuck. Scores are calculated automatically the moment a deal is struck in Round 2. If a student is absent, you can simply pull them out of that round’s role play without disrupting the rest of the class, and separate class codes let multiple sections run their own simulations at the same time. When the negotiating is done, the debrief is where it all comes together, the moment the synthesis of active learning actually happens.
The app also comes stocked with everything needed to run a full lesson. That includes briefing documents for each interest group, an optional NotebookLM that students can query for background material, and a link to the Frontline documentary that originally inspired the simulation. Our goal was simple. We wanted to make something engaging for students and practical for instructors to actually use.
On data and privacy. Data handling is covered under our terms of agreement and IRB consent policy.
A Sample Lesson Plan
Instructors have asked how the simulation can fit into an existing syllabus, so here’s a four-part structure we’ve used with success.
One week before the simulation, assign roles. Students receive their interest group assignments and a week to research their role. We recommend having them write a short policy memo outlining their group’s priorities and potential concessions before Round 1. Here is a briefing slide deck we created to help your class prepare.
Class 1, Round 1, Domestic Politics. (~50 minutes.) Interest groups meet, negotiate internally, and aggregate their preferences into a team position paper.
Class 2, Round 2, International Negotiation. Teams sit down with the opposing country and bargain over a joint statement using the mandate they developed in Round 1.
Class 3, Debrief. Connect the simulation back to the real U.S.–China trade war and use the experience to reinforce foundational concepts in international political economy and bargaining theory. A few questions that work well to anchor discussion.
Did the two teams have a bargaining range?
Which domestic constituencies constrained negotiators most?
Did negotiators accept agreements that some members of their coalition disliked?
Why did some negotiations succeed while others failed?
How did your experience resemble or differ from the actual U.S.–China negotiations?
The structure is flexible, too. The core simulation can be completed in about two hours in a single extended class session, or spread across several standard 50- or 75-minute class meetings. We’ve also run it many times over Zoom, so remote and hybrid classes are no obstacle.
Want to Try It in Your Classroom?
You can explore the simulation at simulation.tradewarlab.com. We’ve also put together an instructor guide, student briefing materials, and a sample lesson plan. If you’re interested in using it in a course, or would like us to walk you through the platform, get in touch with the Trade War Lab.
Behind the Scenes: Building the App
Everything above is the view from the classroom. But building the platform that makes it possible was its own kind of negotiation, between what we wanted and what we could actually ship. Below, Henry, the student developer who built the app, reflects on what that process taught him.
The web app grew out of a problem we ran into with the original, paper-based version of the simulation, where groups of students split into different rooms to negotiate. It worked, but it created real headaches for instructors. Tracking each team’s progress was difficult, collecting data afterward meant hours of manual work, and the whole format assumed everyone could be in the same room. As we ran more iterations, including remote versions over Zoom, those limitations became harder to ignore. Eventually it was clear that instead of forcing an existing platform to fit the simulation, we needed to build our own.
That gave us control over every part of the experience, letting us change the rules, adjust the interface, and respond directly to what we learned from each round of testing. The app runs on Vercel, Next.js, and Supabase, a stack simple enough for a small team (essentially one developer) to build and maintain while Supabase handled authentication, real-time updates, and the database behind the scenes.
Since we’re a research lab, though, the app also had to make the simulation easier to study. We built it to automatically record student decisions and the values they assign to different trade items, with everything exportable as a CSV. We also made final votes anonymous after early testing showed students were less likely to reject a bad deal when their name was attached to it. Anonymity lets students vote their actual judgment instead of caving to whoever negotiates the loudest. They can still see whether a deal passed unanimously, just not who voted which way. These priorities shaped the technical choices, too. We wanted the app to feel professional without becoming one more piece of software students and instructors had to learn. That’s part of why we chose Supabase’s relational structure over something like MongoDB. The simulation itself is inherently relational, with teams, interest groups, trade items, proposals, votes, and outcomes all connected to each other, so a relational database could handle those relationships directly instead of us recreating them throughout the app.
Building it wasn’t as clean as the plan made it sound. One particularly frustrating bug had students seeing final scores for both teams, but wildly skewed. After a lot of digging, the culprit turned out to be Supabase’s row-level security, not the scoring logic at all. Specific database policies were quietly blocking certain users from the rows with the correct point values. A good reminder that the most frustrating bugs aren’t always in the code you suspect. That bug, and plenty of others, reinforced our biggest lesson. You learn full-stack development fast once real people start using what you built. Beta testing surfaced problems that hours of solo testing never would have. Features that felt obvious to us confused first-time users, and workflows that worked fine with two test accounts broke the moment a whole class used them at once. We also learned a development plan can almost never be too detailed. It’s far easier to think through constraints up front than to reconstruct those decisions after something breaks, and a detailed plan makes it much easier to tell which features genuinely improve the simulation and which just add complexity.
In a way, building the app became an extension of the simulation itself. We wanted students to feel the real complications of bargaining, and building the software made us navigate our own version of the same tradeoffs. Simplicity versus flexibility, research versus teaching, what we wanted to build versus what we could realistically ship. What started as a paper-and-pencil classroom exercise is now a teaching tool, a research platform, and an ongoing coding project we keep developing alongside the instructors and students who use it.