The desire to digitize board games often grows out of both admiration and frustration, admiration for the depth of design in certain tabletop systems and frustration with the limits of space, time, and available opponents. After making relatively smooth progress on the solitaire game Phantom Fury, the confidence to attempt something more ambitious began to take shape. The initial plan had been to translate another solitaire design into digital form, one that could be approached in a straightforward and contained way, but the mind rarely stays satisfied with a safe path when a larger challenge beckons. John Butterfield’s well-regarded Battle of Britain simulation, The Hardest Days, seemed at first like a natural next step. Its reputation as one of the finest operational treatments of the air campaign was enticing, but the motivation to keep working on it faltered. Sometimes it is not the complexity or the theme that creates barriers but the inability to maintain long-term enthusiasm. Despite good intentions, the energy that sustains coding sessions and design choices drained away, and the project gradually slid into disinterest. During this period of uncertainty, browsing digital board game adaptations created by other hobbyists rekindled a spark. There was something inspiring about seeing these multiplayer wargames come alive on screen, not only as solo exercises but as shared experiences across distances, and the pull toward creating a multiplayer environment began to outweigh the safety of another solo implementation.
With that inspiration in place, memories of earlier attempts resurfaced. A previous foray into adapting Brian Train’s two-player Third Lebanon War had already demonstrated both the allure and the peril of multiplayer design. The concept was promising, and the mechanics were interesting, but the codebase had become tangled by inexperience. Poor design decisions accumulated, making later development difficult. What had begun as a bold attempt turned into an exercise in fighting against one’s own early mistakes. That lesson remained vivid, and with the rekindled enthusiasm for multiplayer games came the thought of revisiting and rewriting that application with the hard-earned knowledge gained since. Yet the world outside games intruded upon the work. The collapse of the Baathist regime in Syria and the weakening of Hezbollah left the game’s hypothetical scenario feeling oddly detached from the present reality. Wargames thrive on plausibility even when they are not simulations of real events, and the fading resonance of that conflict drained momentum from the idea of revisiting the project. Creative attention began to drift elsewhere, searching for a design that would satisfy the desire to build something meaningful without being trapped in either obsolescence or excess complexity.
This wandering search settled momentarily on an unexpected title. Dawn of Empire: The Spanish American Naval War in the Atlantic, 1898 seemed at first to present a promising balance of scale and complexity. It offered an operational-level naval conflict that integrated command-and-control and logistics in ways that looked appealing. Most importantly, it was relatively straightforward in its mechanics, at least by the demanding standards of wargaming, which promised to offset the daunting complications of writing a networked multiplayer application. The idea was appealing because one could focus on coding and digital interaction without being crushed under rules that required elaborate structures. But appearances can be deceiving. Despite the initial attraction, reading and re-reading the rules created confusion rather than clarity. Certain procedures felt opaque, and implementing them in a user interface exposed hurdles that dampened enthusiasm. Interest waned again, reminding the designer that selecting a project is not merely about matching ambition to feasibility but also about ensuring that the subject matter resonates enough to carry the project forward through inevitable obstacles. The recognition that Dawn of Empire was slipping away created frustration but also opened space for the next idea to take root.
That idea arrived not in front of a computer screen but on a trail during a hike, accompanied by a foster dog named Cal and the voice of an audiobook recounting the history of the USS Oriskany and Air Wing 16 during the Vietnam War. The narrative of Bloody Sixteen unfolded against the backdrop of fresh air and steady steps, and something about that combination created a sudden moment of clarity. The thought emerged with a jolt of excitement: Downtown, the complex but brilliantly designed game about the air war over Hanoi, was waiting on the shelf. It was ambitious, undeniably challenging, yet compelling in theme and execution. Why not attempt a digital version of this masterpiece rather than chase projects that did not hold the same pull? The realization brought with it a mix of trepidation and determination. This was no simple solitaire system nor a lightweight naval campaign; it was a heavy, multiplayer air combat simulation that demanded careful thought. But the very things that made it intimidating also made it fascinating. With renewed purpose, the rules were pulled from the shelf and studied with the intent to understand not merely how the game functioned but how it might be reimagined for a digital platform. It was not just about converting mechanics into code but about entering into a design dialogue with a game that had already earned a place in the canon of serious wargaming.
Having learned from past mistakes, a new approach was adopted. The previous habit of taking sequential notes while reading rulebooks had proven insufficient for complex systems. This time, inspiration from object-oriented programming suggested a better way. Instead of transcribing rules in order, the concepts would be mapped directly into potential classes, complete with attributes, methods, and observations about their interrelationships. This functional organization meant that insights about design structure could be captured immediately rather than lost in a sea of text. For every aircraft flight, terrain hex, or radar target, there could be a sketched class with the data members it required, the functions it needed, and the specific interactions it would be expected to manage. The process created a sense of order that aligned with coding practice while still remaining within the realm of analysis. Alongside this, attention was given to the decisions players would make, translated into command classes that represented distinct actions. Each of these carried not only the definition of the move but also the conditions for its validity under the rules. This meticulous method produced a growing body of organized design notes, which eventually expanded to more than fifty pages, evidence that the new methodology was yielding both structure and insight. For the first time in a long while, it felt possible to bridge the gap between fascination with a game and the daunting reality of writing code to bring it into digital form.
The Beginnings of a Digital Journey into Downtown
The impulse to transform a board game into a digital experience rarely arrives as a single flash of inspiration. More often it grows out of earlier experiments, half-finished projects, successes that gave confidence, and failures that left behind lessons. The decision to tackle Downtown: Air War over Hanoi, 2018–2025 emerged from just such a mixture of threads, a weaving together of previous attempts at bringing cardboard to the screen. The journey began after earlier work on Phantom Fury, a solitaire game that translated into digital form with surprising smoothness. The progress achieved on that project instilled confidence that the skillset had matured, that the complex relationship between rules and code was no longer an impenetrable wall. This success encouraged the idea that another solitaire title might be the right next step, one where the workload could be managed, and the scope remained firmly under control. With that in mind, John Butterfield’s The Hardest Days, a simulation of the Battle of Britain, presented itself as a natural candidate. Butterfield’s designs carry the weight of reputation in the hobby, carefully tuned to provide both challenge and historical feel, and The Hardest Days seemed to offer enough depth to be worth the effort while remaining accessible enough to avoid drowning in intricacy. Yet enthusiasm has a fragile quality; while logic might argue that the project was sound, passion is what sustains late-night coding and problem solving, and somehow that passion faltered. Despite initial excitement, the motivation to persist dwindled, and the work failed to progress. The lesson, once again, was that even promising projects can collapse if they do not spark a deeper connection.
During this period of hesitation, inspiration arrived from a different direction. Browsing through a collection of digital board game implementations rekindled an interest not just in solitaire but in the more challenging space of multiplayer. Watching how other designers managed to bring two or more players into shared digital environments reminded me of the unique potential of such platforms. Unlike a solitaire design, multiplayer coding must simulate not only rules but also the social dynamic of interaction, the push and pull of adversaries across a board. The memory of my earlier attempt at bringing Brian Train’s Third Lebanon War into the digital sphere returned, reminding me of both the potential and the pitfalls. That project had started with great energy, but the design choices made early on had led to increasingly unmanageable code, tangled threads that resisted every effort to straighten them out. It became a cautionary tale, a reminder that rushing into implementation without a framework could doom even the most compelling design. Yet the attraction of revisiting it remained strong, especially with the experience gained since then. The idea of rewriting it with better architecture was tempting. But once again, the outside world pressed in. The geopolitical landscape had shifted, the Baathist regime in Syria had collapsed, Hezbollah had suffered heavy blows, and suddenly the game’s scenario, once a plausible what-if, felt hollow. A simulation without resonance risks becoming lifeless, and so the project was abandoned in favor of searching for a new path forward.
That search turned toward an unexpected historical conflict: the Spanish-American War. Compass Games’ Dawn of Empire offered an operational-level look at the naval struggle in the Atlantic in 1898, with rules that integrated the often-overlooked factors of command-and-control and logistics. What drew me toward it was not only its subject but its scale and accessibility. After wrestling with the heaviness of some designs, the relative simplicity of Dawn of Empire promised a balance. It looked like a game whose mechanics could be digested and modeled without consuming years of work, making it suitable as a vehicle for practicing multiplayer programming. Naval warfare at this operational level carried its own appeal, as it required the management of fleets, the navigation of distances, and the pressures of maintaining supply lines. Thematically it was different from the tactical air battles that dominate many popular designs, and that difference added to its intrigue. Yet when theory met practice, complications arose. The rulebook proved more resistant to comprehension than expected. Certain mechanics felt opaque, as though they were written in a way that made sense on the table but resisted easy codification. Furthermore, when I began to think about how players would interact with the system digitally, user interface challenges surfaced that seemed less rewarding to solve. Slowly, motivation ebbed away once more, leaving behind the frustration of another promising idea that failed to take root. The cycle of attraction, experimentation, and disillusionment seemed destined to repeat itself endlessly.
And then came a different kind of moment, one that did not arrive at the desk but on a trail under an open sky. I was hiking with my foster dog, Cal, while listening to the audiobook of Bloody Sixteen, a vivid recounting of the USS Oriskany and Air Wing 16 during the Vietnam War. The combination of fresh air, the rhythm of walking, and the caffeine in my system brought a rush of clarity. Immersed in the stories of pilots, squadrons, and the deadly challenges of flying over North Vietnam, my thoughts turned toward Downtown, the monumental board game design that captures the air war over Hanoi. The realization struck with surprising force: here was a game of remarkable depth and detail, one that had always fascinated me, and though it was notoriously complex, it was also multiplayer and thematically captivating. Rather than chase projects that failed to sustain my interest, why not take on Downtown directly? The thought might have seemed reckless, given the game’s reputation for intricacy, but it was also liberating. At last, the desire for a project aligned with a subject that stirred genuine excitement. Returning from the hike, I pulled the box from the shelf, opened the rules, and began reading with renewed focus, the decision made to attempt a digital adaptation of one of the most ambitious designs in modern wargaming.
The methodology extended beyond units and terrain. I recognized that the heart of any game lies in the choices players make, so I organized notes on those decisions into what I termed command classes. Each represented a discrete action: moving a flight, launching a missile, splitting a formation, designating a target. These were not just abstractions; they carried within them the logic required to validate their legality under the rules. By writing them out, I created a catalog of player decisions that doubled as a blueprint for the eventual user interface. Menus, prompts, and buttons would follow from this catalog, ensuring that the digital version of Downtown would not be an awkward translation but a system structured around the actual rhythm of player decisions. As the catalog grew, the interplay of actions became more visible, offering insights into potential bottlenecks and conflicts that might otherwise have emerged only in late development. This was design as foresight, not merely recording rules but imagining how players and program would converse in the heat of digital battle.
Alongside classes and commands, I reserved space in the notes for the difficult questions, the issues that had to be confronted early if the project was to avoid collapse later. A central concern was the constant opportunity for the non-active player to interrupt the active one in Downtown. This mechanic, manageable in a face-to-face game by informal agreements and conversation, posed major challenges in a digital multiplayer environment. How could the program manage interruptions gracefully, ensuring that reactions happened at the right time without overwhelming the flow of play? Another concern was the degree to which the digital version should replicate or adapt the tabletop experience. Some steps of bookkeeping, perfectly acceptable in cardboard form, threatened to become tedious when automated, while other procedures could be streamlined to enhance clarity. Capturing these questions in writing ensured that they would not be overlooked, serving as a reminder that adaptation required judgment, not just literal conversion. By the time I completed the second reading of the rules, my notes had grown to more than fifty pages, a sprawling but organized body of analysis that reflected both the complexity of the game and the seriousness of the endeavor.
To bring visual clarity to this mass of text, I turned to Unified Modeling Language. Diagrams allowed me to see the relationships between classes at a glance, reducing the sense of drowning in details. Aircraft linked to flights, flights linked to missions, missions linked to objectives, objectives linked back to terrain hexes and targets; the connections became visible in lines and shapes. Even though I had so far used only class diagrams, the benefits were immediate. The growing web of objects felt less abstract, more like a structured machine that could eventually be built piece by piece. I knew that in time I would need to expand into sequence diagrams and activity diagrams, each adding another perspective on the system, but even these preliminary sketches provided reassurance. They were maps of the digital battlefield, showing that the complexity, while daunting, could be navigated.
Yet despite all this careful planning, the urge to code remained strong. It is difficult for a programmer to remain in the realm of diagrams and notes for long. To satisfy this urge without undermining the discipline of preparation, I chose to focus on a side project that would ultimately be necessary: the terrain editor. Downtown, like all hex-and-counter games, depends on a detailed map, and building a tool to create and manage terrain data was both a practical step and a reward for patience. The editor drew upon previous efforts I had made, expanding them into a more flexible system that could be adapted to different games. By coding it, I could see tangible results without leaping into the main logic of Downtown prematurely. The work on the editor provided both satisfaction and momentum, demonstrating progress while keeping the central promise intact. It also opened the possibility of sharing the tool, since it contained no game-specific intellectual property, even if adapting it required familiarity with C++ and Qt. For now, though, its primary purpose was to lay the groundwork for Downtown, a piece of the puzzle that would make the larger project feasible. With this in place, I could continue studying and diagramming the rules with renewed confidence, knowing that progress was being made on both practical and theoretical fronts.
Building the Framework of a Living Simulation
The deeper I delved into the rules of Downtown, the more it became clear that the project was not simply about transcribing written procedures into code but about imagining how an entire simulation could live and breathe within a digital environment. Board games rely on human intelligence to interpret and enforce rules; players make decisions, perform calculations, manage exceptions, and resolve ambiguities almost subconsciously. A digital version, by contrast, must have every pathway accounted for, every interaction captured in code, every exception reduced to a predictable sequence of instructions. This realization was daunting but also invigorating, because it required a mode of thought that fused two disciplines: the designer’s eye for structure and the programmer’s instinct for logic. The rules of Downtown were a labyrinth of interwoven procedures — detection, missile launches, jamming, flak, maneuver, fuel consumption — but when seen through the lens of object-oriented design, patterns began to emerge. Aircraft were not just counters with numbers; they were entities with properties and states. Hexes were not just colored spaces on a map; they were data objects containing elevation, terrain, and capacity for installations. Missions were not just entries on a planning sheet but systems of relationships linking flights, waypoints, ordnance, and objectives. By conceptualizing each piece of the game as a class, and by mapping interactions through UML diagrams, the chaos slowly resolved into a structured framework that could one day function as a living simulation of the Vietnam air war.
One of the most pressing challenges was to devise a way to model player interaction in a manner that felt natural in digital form. Downtown, unlike simpler wargames, thrives on the constant interplay of action and reaction. The active player plots missions, moves flights, and declares attacks, while the opponent constantly has opportunities to intercept, fire missiles, scramble aircraft, or shift anti-air defenses. This fluid back-and-forth is easy to manage across a tabletop where two humans face each other, but in a digital multiplayer environment it becomes a potential nightmare of interruptions. If the system paused for every possible reaction, the flow of play would grind to a halt; if it ignored them, the simulation would lose its soul. To address this, I began to frame player actions as discrete commands, each with clearly defined windows in which responses could be triggered. For instance, a “move flight” command might open a temporary branch in the flow, checking for possible intercept reactions before proceeding. By treating decisions as encapsulated objects, it became easier to imagine how they could be passed back and forth between players, queued, validated, and resolved without collapsing under complexity. This approach promised to preserve the spirit of Downtown’s interaction while giving the digital version the clarity and discipline it needed.
A related insight came when considering the user interface. Most failed digital board game projects collapse not on the level of rules coding but on the experience of actually playing them. If the interface is cumbersome, confusing, or tedious, players abandon the system no matter how accurate the underlying simulation may be. With Downtown, the challenge was especially acute, because the game’s mechanics involve a heavy amount of tracking — fuel states, altitudes, formations, radar locks, missile ammo, detection rolls. On the table, these are managed through counters, charts, and player memory; in digital form, they could easily become overwhelming lists and windows. To avoid that trap, I committed early on to linking the catalog of commands directly to interface elements. Every possible action a player could take would correspond to a menu option, button, or prompt generated at the appropriate moment. This way, the interface would not present the player with the entire universe of possibilities at once but would dynamically offer only those decisions relevant to the current state. The design echoed the logic of a well-run cockpit, where instruments and switches are arranged so that each is accessible when needed, not as a bewildering clutter. This decision marked a philosophical stance: the interface would be built from the player outward, not from the rules inward, ensuring that Downtown in digital form would feel less like filling out a spreadsheet and more like commanding an air war.
The terrain editor, which had started as a side project to satisfy my coding itch, became a vital piece of this philosophy. Downtown’s map is not decorative; it shapes every decision, from approach routes to engagement zones, from target selection to radar coverage. By building a flexible terrain editor, I gained not only a tool for recreating the Hanoi region with precision but also a foundation for how the game would handle spatial data more broadly. Each hex could be assigned attributes that the code could query instantly: Does it contain a SAM site? What is its elevation? Is it urban, forest, or open? How close is it to a major airbase? By embedding this information into data objects rather than static graphics, the digital Downtown would allow the system to make calculations instantly, reducing the burden on players. It also opened the door to potential scenarios beyond the published ones, since maps could be edited or generated with relative ease. The editor was not glamorous work, but it was essential scaffolding, enabling a future in which the game could expand without rebuilding its foundations. In this way, a practical coding exercise became both a proof of concept and a cornerstone of design.
Even as the framework grew more robust, I confronted the unavoidable tension between fidelity and playability. The purpose of adapting a board game digitally is not simply to reproduce every rule exactly but to capture its spirit while leveraging the strengths of the medium. Some aspects of Downtown’s tabletop play lent themselves naturally to digital translation. Bookkeeping tasks like tracking missile expenditure or fuel states could be automated, removing tedious manual work from the players’ hands. Complex probability tables could be replaced with simple prompts, their calculations performed invisibly by the system. But other elements demanded judgment. For example, in the tabletop version, players often rely on informal negotiation to manage interruptions, deciding when to declare reactions in a flexible way. Should the digital system replicate this informality, perhaps by allowing players to pause and intervene manually, or should it enforce strict windows to maintain consistency? Each decision carried trade-offs, and I noted them carefully, recognizing that premature choices could compromise the integrity of the whole project. The guiding principle emerged: wherever automation enhanced clarity and speed without diminishing agency, it would be embraced, but where automation risked stripping away meaningful decisions, restraint was necessary. This balance would define not only the technical success of the project but its authenticity as a simulation of the Vietnam air war.
Another layer of complexity emerged when considering scalability. Downtown in its full form is immense, capable of modeling campaigns of staggering detail, but not every digital player will have the time or patience for such scope. To broaden its accessibility, I envisioned the possibility of modular scenarios, where players could scale the experience up or down depending on preference. A quick engagement might involve a handful of flights and a limited number of SAM batteries, while a full campaign could span multiple days of sorties, rotations, and escalating defenses. Designing the system with this flexibility required forethought. Data structures had to allow for both small and large orders of battle, interfaces had to scale without becoming cluttered, and performance had to remain smooth regardless of scope. This challenge underscored the importance of the UML work, because without a coherent architecture the code would collapse under the weight of expansion. Scalability was not just a convenience but a survival mechanism for the project, ensuring that Downtown would not be trapped in a single mode of play but could adapt to the needs of different players and contexts.
Ultimately, what kept the momentum alive through these challenges was not just technical discipline but the emotional charge of the subject matter. Reading accounts of pilots flying into SAM rings, of radar operators tracking enemy formations, of the tension between technology and human courage — all of this reminded me why the project mattered. Downtown is more than a set of mechanics; it is an attempt to model one of the most perilous aerial campaigns in history, to convey the drama and uncertainty faced by those who flew over North Vietnam. Translating that into a digital space was not about building software for its own sake but about honoring that drama through interactivity. Each UML diagram, each catalog of commands, each terrain hex defined in the editor was a step toward making that drama playable, palpable, alive. It was this sense of purpose that transformed the grind of note-taking and diagramming into an act of creation. The framework was not just code waiting to be written; it was the skeleton of a living simulation that, if built with care, could allow players to glimpse the complexity and intensity of the air war over Hanoi.
Confronting Complexity and Sustaining Momentum
The third stage of this journey, after enthusiasm had set the course and methodology had laid the framework, was the long, grinding confrontation with complexity. The deeper I went into Downtown’s systems, the more I realized that every rule and sub-rule was not simply a procedural instruction but part of a vast interdependent machine. The temptation was always to underestimate the density of connections. For instance, radar detection might appear to be an isolated subsystem, governed by range, altitude, and terrain. But once diagrammed, it became entangled with electronic warfare, aircraft stealth ratings, countermeasures, weather, and even command-and-control rules for when information was relayed between units. A tweak in one area inevitably rippled outward, disturbing other carefully constructed balances. The danger was paralysis, the feeling that no progress could be made until everything was understood in totality, and yet such omniscience was impossible. To overcome this, I adopted a strategy of scaffolding: isolate one subsystem, diagram it fully, mock its behavior through pseudocode, and only then integrate it back into the larger whole. This approach did not reduce complexity, but it allowed progress by narrowing the field of focus. It became a mental discipline, reminding me that even a vast simulation is built one function, one decision, one interaction at a time.
What helped enormously was the willingness to revisit and revise earlier assumptions. Early sketches of class structures often looked elegant in isolation but collapsed when tested against real interactions. The first model of an aircraft object, for instance, was neat and symmetrical, with attributes for fuel, altitude, ordnance, and morale. But once I began to diagram mission flow, I discovered that aircraft could exist simultaneously in multiple states that contradicted this simple model: a flight could be “in transit,” “engaged,” “under jamming,” and “aborting” all at once. To capture such layered statuses, the model had to shift from rigid attributes to dynamic state machines, where conditions could stack, override, or interact. It was messy, but it was also truer to the reality of gameplay, where a single aircraft counter can represent a dozen overlapping conditions. The willingness to destroy and rebuild, to accept that initial elegance might give way to functional messiness, became a recurring theme. Complexity could not be avoided, but it could be managed through iteration, patience, and the acceptance that clarity often emerges only after wrestling with confusion.
At this stage, UML diagrams became less a formality and more a lifeline. The first round of class diagrams had provided structure, but now sequence diagrams and activity diagrams came to the forefront. By sketching the order of interactions — who calls whom, in what sequence, and under what conditions — I could detect gaps and contradictions that were invisible in static lists. For example, a sequence diagram of a missile launch revealed that I had no clear model for how the defending player’s reactions would cascade: radar lock detection, countermeasure deployment, evasive maneuvers, and the possibility of a second defending unit joining the engagement. Laying it out in temporal order showed that my earlier design had overlooked several timing windows, which, if left uncorrected, would have caused serious inconsistencies in the code. This revelation was frustrating but also exhilarating, because it demonstrated the power of diagrams as a diagnostic tool. They did not merely document decisions already made; they exposed flaws, demanded corrections, and guided redesigns before a single line of code risked being wasted. In this sense, UML was not a bureaucratic layer but the very medium through which the simulation could be made coherent.
Even as the diagrams expanded, the practical matter of coding still pressed forward in carefully chosen domains. The terrain editor, which had proven so useful as a side project, now became a testbed for how data would flow through the system. By feeding the editor’s hex attributes into mock functions, I could simulate rudimentary detection ranges, calculate line of sight, or experiment with altitude effects. These tests revealed limitations in the data structure: some attributes that seemed sufficient on paper proved inadequate in practice, requiring the addition of metadata for hex connectivity, visibility arcs, or elevation gradients. Each modification improved the fidelity of the eventual simulation but also forced reconsideration of storage and performance. Could the program efficiently query thousands of hexes during each detection phase without grinding to a halt? Would precomputed tables of visibility be necessary, or could on-the-fly calculations suffice? Wrestling with these questions anchored the project in the material realities of performance, reminding me that a digital simulation is not an abstract model but an executable program subject to hardware limits. Each experiment with the terrain editor thus became a rehearsal for the larger symphony to come.
As the work deepened, a new layer of motivation emerged: the recognition that Downtown’s digital form could potentially serve not just as a game but as a historical tool. Reading accounts of the air war, cross-referencing maps, and studying photographs, I began to realize how closely the board game itself was already tethered to history. Its counters were not abstractions but specific squadrons, its map not a generic battlefield but a reconstruction of North Vietnam’s defenses. In digital form, this fidelity could be enhanced rather than diminished. The ability to layer real-world data, to create visual overlays of actual pilot routes or confirmed SAM sites, offered possibilities beyond what cardboard could achieve. I imagined scenarios where players could switch between the game view and a historical mode, comparing their decisions to those recorded in after-action reports. Such ambitions lay far beyond the immediate scope, but they infused the project with a sense of higher purpose. I was no longer merely coding a game; I was, in some small way, building a vessel for historical exploration, a bridge between simulation and scholarship. This realization gave weight to the grind of diagramming and note-taking, transforming them from chores into contributions to something potentially lasting.
Conclusion: Toward a Digital Hanoi
Looking back across the arc of this project, what strikes me most is how the act of bringing a board game into digital life reveals not only the intricacies of design but also the intricacies of persistence. Downtown: Air War over Hanoi, 2018–2025 is not a casual game. It was never meant to be. It is a deep, sprawling, detail-heavy simulation of one of the most complex aerial campaigns in history. That complexity makes it daunting, but it is also the source of its fascination. To attempt a digital adaptation of such a title is not a task of convenience but of commitment, a willingness to wade into systems that resist simplification and mechanics that constantly threaten to overwhelm. The first steps — notes, diagrams, editors — may not look like progress to outsiders, but they are in fact the invisible groundwork of creation. They demonstrate the recognition that complexity cannot be conquered through brute force alone; it must be studied, mapped, decomposed, and then carefully reassembled into a framework that can support play. Without such preparation, the project would collapse under its own weight, just as earlier attempts at digital wargames faltered. With it, however, there is at least the possibility that Downtown can one day exist not only on the tabletop but also on the screen, alive in new ways.
The lesson that emerges most clearly from this journey is the importance of aligning passion with process. In the past, projects chosen out of logic rather than love — promising solitaire titles, intriguing but opaque designs, plausible what-if scenarios — all faltered when enthusiasm drained away. Downtown succeeded in sustaining momentum precisely because it resonated on a deeper level. It was not merely a system to be translated but a story worth telling: the story of pilots flying into dense SAM belts, of radar operators straining to read signals, of technology racing against human ingenuity. Every time fatigue threatened to derail progress, the historical weight of the subject reignited the spark. That emotional connection proved as vital as any diagram or editor. It was the difference between another abandoned prototype and a project that endured across months of study. In this sense, the conclusion is not just about Downtown but about the broader truth that creative work, especially in fields as demanding as digital wargame adaptation, must be driven by genuine passion if it is to survive the grind. Passion alone cannot complete a project, but without it, no amount of skill or structure can carry the weight.
Another conclusion lies in the balance between fidelity and playability. Downtown in its cardboard form is already a careful balance: detailed enough to capture historical feel, streamlined enough to remain playable. In digital form, that balance must be renegotiated. Automation offers opportunities to lighten the burden on players, but it also tempts the designer to overreach, to strip away decisions in the name of efficiency. The work of diagramming and cataloging commands made it clear that the essence of Downtown lies not in its bookkeeping but in its decisions — when to commit a flight, when to launch a missile, when to break off an engagement. Preserving those decision points became the guiding star. If the digital version could make the supporting mechanics invisible while keeping the decisions sharp, it would succeed. If it drowned players in automated processes that left them with little to decide, it would fail. This principle, tested again and again during the planning stages, will remain the compass for every design choice yet to come. In that sense, the conclusion is a call to humility: fidelity is important, but it must always serve the experience of play, not overwhelm it.
Equally important is the recognition that large projects require not only skill and passion but discipline and patience. The earlier me, eager to leap into coding, would have burned out within weeks, tangled in contradictions and overwhelmed by missing structures. The me who worked on Downtown learned to delay gratification, to spend hundreds of hours building notes and diagrams before writing functional code. That discipline transformed the project from fantasy to something genuinely possible. It is perhaps the hardest lesson to accept — that progress sometimes looks like standing still, that invisible foundations matter more than visible walls. But it is also the most empowering. By learning to prepare properly, the project became sustainable, capable of surviving the inevitable waves of fatigue and doubt. This discipline is not limited to Downtown; it is a transferable lesson, a way of approaching any ambitious project with the patience required to see it through.
Perhaps the most unexpected conclusion, however, is how personal this journey has been. The long walks with Cal, the hikes that sparked clarity, the nights spent diagramming instead of coding — these are not footnotes but essential parts of the story. Creativity does not happen in isolation from life; it is entangled with the rhythms of the everyday, with the demands of rest, with the sparks that come when body and mind are given space. In that sense, Downtown is not just a digital adaptation but a personal chronicle, a record of how persistence, discipline, and passion intersect with the mundane realities of fatigue, distraction, and renewal. To build a simulation of the Vietnam air war is also to build a simulation of one’s own resilience, to test whether enthusiasm can be sustained across months of invisible labor. That personal dimension, often overlooked, is perhaps the most valuable outcome of all, because it proves that large creative endeavors are as much about shaping oneself as about shaping a product.
And so, the conclusion is both a reflection and a promise. No digital Downtown yet exists for others to play, but the scaffolding stands firm: the notes, the diagrams, the editor, the principles of fidelity and playability. The project is no longer a vague ambition but a structured path forward, one that can survive setbacks and adapt to new insights. Whether it will one day be completed remains uncertain; every large project carries the risk of collapse. But even if it never reaches full fruition, the lessons drawn from it — about passion, process, discipline, and persistence — remain valuable, applicable to any future endeavor. Downtown has already fulfilled part of its purpose by teaching how to prepare properly, how to balance emotion with structure, and how to sustain momentum through cycles of fatigue and renewal. That, in itself, is a form of success.
If there is a final thought, it is this: Downtown in digital form is not just about Hanoi, not just about 2018 to 2025, not just about jets and missiles and radars. It is about the challenge of translating complexity into clarity, of making systems playable without reducing them to triviality, of honoring history through interactivity. It is about learning to respect both the subject matter and the process of creation. And it is about proving, perhaps only to oneself, that what once seemed insane — to attempt to digitize one of the most intricate board wargames ever made — is, in fact, possible with patience, preparation, and passion. Whether the finished program one day appears on screens or not, the journey itself has already reshaped how I understand games, design, and persistence. That is the true conclusion of Downtown: Air War over Hanoi in digital form — not the end of a project but the continuation of a practice, a way of working that can carry forward into whatever battles, real or simulated, the future may hold.