Unreal Engine 5.5 · Team of 2 · Third Year
A narrative trading game about wealth inequality. I rebuilt the trading system, the ratings went up, and the game got worse.
Start with a paperclip. Trade your way up through a Canadian city by talking to people, each of whom has a reason for wanting what you're carrying. The brief was a game that makes a player feel something about wealth inequality. I was the only programmer on a two-person team, so every system on this page is one I designed and then built.
I nearly didn't write this one up, because the honest version of it ends with me being wrong. Halfway through the project I found a real problem, built something that genuinely fixed it, measured the improvement, and in the process quietly deleted the reason the game existed. I've ended up getting more out of that than I would have from another one that went fine, so it's what this page is about.
A complete arc, in order: what the game was for, what we built, what the first playtest said, the rebuild I'm technically proudest of, what the second playtest measured, and the thing neither playtest was asking about.
The course was about running a project properly and then measuring what came out of it, so we owed devlogs, playtest reports and a post-mortem. The game also had to be about something rather than just existing. We went with wealth inequality, and the way in was the paperclip challenge, that real story of someone trading a single paperclip up to a house through a chain of people who each agreed to it.
What we added was that every trade is a conversation with someone who has a reason for wanting what you've got. You're not clicking through a shop menu, you're getting told in a couple of lines why this person needs your pen, and then the thing you climb is made out of other people's situations.
What we were actually going forBy the end of the game the player should have noticed whose hands all this stuff came out of. Trading up is how you spend your time, but the noticing is the bit that mattered. Worth holding onto, because I lose it around step 05.
Scope we wanted versus scope we had. The pitch was six to nine levels, each a different real city, New York through Toronto, Dubai, Tokyo, Cairo, so the same paperclip would be worth different things in different economies. That was the whole thesis in level-design form.
Two people. One programmer. One semester. We shipped one city and a subway transition. Cutting that was correct and I'd cut it again, but it is worth naming that the strongest expression of the theme was in the part we couldn't afford.
Before I could do anything interesting, the game had to reliably know what the player was carrying. My first inventory made items up on the spot inside whatever Blueprint happened to call it, so an item's price and icon and name all lived in whichever graph spawned it. If I wanted to change a price I had to go find it. If an NPC needed to refer to an item I was more or less guessing.
So I rebuilt the whole thing around a data table. Every item is a row now, with a name, a value, an icon, a category, a trade value and a flag for whether it can be traded at all. The inventory looks rows up by name and fills an array of structs. It's not a glamorous change and none of the rest of this would have been possible without it, because after that the game and I were finally talking about the same objects.
The problem that took longestItems vanished across level transitions. I solved it by mirroring the inventory array into a standalone game instance on every write, and refreshing the player's local array from that instance on spawn. It was my first time using instances and it took a while to understand. The payoff is that a save system is now one variable rather than a rewrite.
Five testers, matched to our target audience of 15 to 25 year old players who like dialogue but don't have much time. Mostly in person, two remote. Full build, no rules explained, no developer intervention, headphones required, screens recorded. Average playthrough was three to four minutes.
The good. The NPC voice landed. Testers specifically called out the slang, said it felt like talking to a person, and there were laughs in the recordings. The core loop read clearly: every tester went for the glowing paperclip, talked to the first NPC immediately, then explored. One detail I still like is that players checked both ways before crossing the road without being asked to.
The bad. The trading system averaged 4.6 out of 10 on how essential it felt. Player dialogue options were too long to scan. The subway had nothing to do in it. And in our own executive summary, sitting in the problems column: misunderstanding of the theme.
The fork in the roadTwo problems were flagged. One was the mechanic scoring 4.6. One was the theme not landing. I went after the 4.6, because it was the one with a number attached, and a number is easier to argue with than a feeling.
The trades felt restrictive because they were. Every single one was written out by hand. Brenden always takes the paperclip and always gives you the pen, because I sat down and typed that. When testers called it linear they weren't being vague, they were describing exactly how it was built.
So I built a dynamic trading system. When a dialogue option requests a trade, the game reads the NPC's wealth class, multiplies the player's current item value by that class's range, and filters the full item table down to what qualifies.
Broke: up to 0.8x your item's value. A bad trade, which you'll usually refuse and walk away from. That refusal is the point: it's a choice about whether to help someone at your own cost.
Normal: 1.1x to 1.8x. Most NPCs sit here. A fair climb.
Rich: 1.8x to 2.0x. Roughly double, from people to whom the difference is nothing.
The filter then strips anything outside that band and removes the item you're already holding, and a random roll picks from what's left. Item pool is 20 to 30 entries spanning $1 to $120,000 and up, so the same NPC can give different results on different runs.
The system running. A $2 pen has just become a $4 highlighter. That is a clean 2.0x, which means this NPC was in the Rich class and rolled the top of the band. Nothing about that exchange was authored. The game read a value, read a class, filtered a table and picked.
It took ten to fifteen hours across a couple of weeks and it is the single piece of programming I'm most proud of on this project. It also unlocked something we needed: with authored trades we were capped at five or six NPCs per level, because each one was hand-written. Dynamic trades meant the NPC count could grow without the authoring cost growing with it.
Ten testers, ages 13 to 26, half of them 19 to 22. Same protocol, in person, our own gaming laptops and headphones, minimal intervention, survey after. We asked them to rate the old trading system and the new one.
The resultThe old system's ratings were scattered from 2 to 6. The new system landed at 5 to 7, clustering at 6 and 7, with nobody rating it below 5. On the question I had set out to fix, the rebuild worked. It is a clear, measured improvement and I would make the same technical call again.
What I hadn't thought about was the writing. With hand-written trades I always knew which item was changing hands, so Brenden's dialogue could be about the pen specifically, and about Brenden, and about why someone in his situation needs one. The trade and the story were the same thing.
Dynamic trades killed that. If the game picks a highlighter at runtime, the dialogue can't mention the highlighter, so all of it had to get vaguer. It didn't become bad writing exactly, just writing that couldn't point at anything. The part every single tester had praised, and the part carrying the entire reason we were making this, got flattened out so the mechanic underneath it could work better.
The finished vertical slice conveys almost none of the wealth inequality message it was built to carry. We over-focused on the trading mechanic, made it genuinely better, and lost the game in the process. The improvement was real and the trade was bad.
The uncomfortable part is that the alpha told us. Misunderstanding of the theme was in our own problems column before I wrote a line of the new system. I read two findings, picked the one with a score attached, and spent the rest of the project making the other one worse.
Gate features against the goal, not against the complaint. Before building the dynamic system I should have asked one question: does this serve the thing the game is for? The answer was no, and it was available for free, before the ten to fifteen hours. I now try to write the one sentence a project exists for somewhere I have to look at it, and hold each feature against that sentence rather than against the loudest piece of feedback.
Don't fix what isn't broken. The authored trades were not broken. They were narrow, and testers described narrowness as linearity, and I heard linearity as a defect. The underlying want was more variety in the fiction, not more randomness in the maths. A shop of authored trades three times the size would have scored better on both questions.
A metric only answers the question you asked. The 4.6 measured how essential the trading mechanic felt. Nothing in either survey measured whether anyone left the game thinking about inequality, which was the only outcome that mattered. If I had instrumented for the goal instead of the feature, the second playtest would have caught this while there was still time.
Scope to the team you have. Six to nine cities was never real for two people in one semester. Committing to that early meant every later decision was made under pressure created by a plan we had already abandoned.
The setting landed without a single landmark. We never showed the CN Tower. We wrote Toronto slang and put a Presto card and transit signage in the player's hands, and testers placed the city immediately. Specific, ordinary objects located the fiction better than a skyline would have, and that is the lesson from this project I have reused the most since.
The technical foundation also held. Data-table items, instance-backed persistence and a dialogue system built for branching are all still the right calls, and they are why one programmer could ship a coherent slice at all.
Two people, one semester, one programmer. How it actually ran.
Version control as a safety net for risk. Everything lived in a GitHub repo with a separate branch for experimental work, so I could attempt something like the dynamic trading system without putting a working build at risk. On a two-person team with a hard deadline, that branch is the only reason attempting it was reasonable at all.
Playtesting had a hardware problem. An Unreal Engine 5 build needs a decent machine, which ruled out sending testers a link and hoping. Every session was run in person, at campus and at libraries, on our own laptops with our own headphones. That is slower and it caps your sample size at five and then ten, but it also meant I watched every session happen.
Where Blueprints ran out. Most of the game is Blueprints. The trading logic needed a few operations that were awkward or unavailable as nodes, so I wrote custom C++ nodes and called them from the graph. Reaching for C++ only where Blueprints stopped being the faster option is a habit I've kept.
Testers said the trades felt linear. That was accurate and the fix I derived from it was wrong. What they wanted was a richer world, and I gave them a better random number generator. I now try to treat a complaint as the start of a diagnosis rather than the end of one.
Every number I collected was about the mechanic. Nothing measured whether the game did what it existed to do, so the thing that broke was invisible to my own instrumentation right up until the post-mortem.
A Presto card and the right slang placed the city harder than any skyline would have. When I want a player to know where they are now, I reach for the small ordinary object someone who lives there would have in their pocket.