Tabletop to Desktop

by Peter Willington
November 6, 2017

Making video games is a challenging and fascinating creative endeavor. I'm going to take you through some of the complex problems we faced while designing the digital adaptation of Ogre, how we resolved them, and most importantly why they needed to be solved in the first place. As a bonus, I'll throw in some behind-the-scenes documentation and images.

A snapshot of the early stages of production. Lots of preparatory work must be done to ensure the game feels cohesive.

Ogre was a project of passion at Auroch. Studio owner Tomas Rawlings made these when he was just 9 years old...

My hope is that by reading this article you'll gain a better understanding of the differences between making boardgames and making video games, while also seeing areas of Ogre's design you're very familiar with from an angle you might never have considered.

Meta-gaming – just who is this game for, anyway?
Before we could begin the project, we had to answer one crucial design question: who is the audience for the Ogre video game?

We had a brief from the team at Steve Jackson Games: replicate O6E as a video game, as far as was appropriate. But how much of that game we could adapt was a source of debate: Did we want to make our Ogre feel more accessible, as if it was designed from the ground up to be a modern video game with all the creature comforts gamers have come to expect? Or did we want to focus on making a wholly "boardgame, but digital" experience, with all 40 years of Ogre's history feeding into it?

Players of the video game version will immediately notice that we changed the map style during development.

We could have massively streamlined some of the rules, or even cut them out completely, so an audience less familiar with the game wouldn't get bogged down by the details. When you're making a video game with a six-figure budget, a game that's going to take over a year of development and absorb a huge chunk of your total development team, it's not unreasonable to simplify that game to appeal to the widest demographic. After all, while Ogre certainly has a decent-sized audience of loyal fans, it isn't even as popular as some other strategic boardgames, let alone in the dizzying heights of popularity that many top-tier AAA strategy video games achieve.

But that phrase – "loyal fans" – was something we kept coming back to when thinking about what Ogre should be. We collectively decided to make it as faithful to the source material as we could, to ensure that those fans – the people who had kept the game's spirit alive for so many years – would get a game that really felt like Ogre, rather than a game that simply looked like Ogre.

This. This is who we made Ogre for.

Our rationale was this: If we make a good game for the fans, they'll rave about it to their friends. If their friends pick it up, they'll see what a great game Ogre has always been, talk about it with their friends, and so on and so forth. We wanted to inspire that long-term virtuous circle of discovery and recommendation, building to, we hoped, a larger fan community and another two decades of Ogre gaming.

With 40 years of Ogre gaming history, what do you include and what do you leave out?
After deciding to make a faithful adaptation, our next question was this: which Ogre material should make the cut into the final game?

In the end, we chose to include the following play pieces:

• Infantry
• Marines
• Light Tank
• Heavy Tank
• Missile Tank
• GEV
• Superheavy Tank
• Howitzer
• Mobile Howitzer
• Command Post
• Mobile Command Post
• Hardened Command Post
• Reactor
• Admin Building
• Strongpoint
• Train
• Mk. II
• Mk. II
• Mk. III
• Mk. IV
• Mk. V
• Mk. VI

Do enough measuring of Ogre play pieces...

... and you end up with a scale to use for the 3-D models.

We chose to stick to "official" play pieces, rather than dip into community-made content, for three reasons:

1) Using the original stats that drive the Ogre tabletop game to drive our game engine allowed us to avoid the need for stat balancing. We know official units will play smoothly with every other unit; they've been put through their paces for 40 years. Unofficial play pieces might not have gone through that level of playtesting and that's going to make for a disappointing video game experience. We could have separated non-official pieces from official ones to avoid over-powered pieces, but then we'd have to devise whole new sets of rules of what can play against what and where they could appear, and we didn't want that added complication.

2) We wanted to create a feeling of authenticity and that's something the official play pieces bring to the digital version. We also wanted the campaign to feel cohesive, and fan-made creations would have undercut that. Again, we could have left them out of the campaign, but with a limited budget and schedule, that would have forced us to make the campaign less diverse.

3) If we just cherry-picked everything we wanted to include, not only would the game have taken many more years to build, but we wouldn't have anywhere else to go with the game's development. As massive fans of the original, we're in this for the long haul; we want to be supporting the game and releasing new material for years to come. Our thinking was, sure, we could squeeze the Ogrethulhu in at launch as a standalone unit in a very cut-down fashion, but wouldn't it be better to do something bigger and cooler with such an iconic model, if the game performs well enough to justify more content...?

Do we ever plan to allow fan-made content so players can design their own units? On this question we were conflicted: we know that awesome stuff has been made by fans – we've looked through a lot of it as part of the creative process – and we know that this spirit of creativity is part of what has kept Ogre going all these years. But we also know how hard customization is to implement effectively. It's a huge technical challenge to add that kind of feature, and it may end up being more effort to use than most players would find convenient. Also, with mod support comes a need for content moderation that is simply not possible for a small team like ours. Ultimately, we wanted to maintain full creative control over the game, and keep our budget and schedule in line, so we decided against supporting fan customizations.

As a compromise, we created a suite where players can take the assets from the game and use them to make their own scenarios and maps, which can then be shared. This option provides a way for fans to get creative and put their stamp on the game we've made, while giving us the control we want over the product.

A selection of the user-generated maps available via Steam Workshop.

Why choose a single platform at launch and why PC via Steam?
Choosing a platform is a big decision that impacts every element of a game. It's not a decision that we made lightly. We chose to launch on: a) PCs, b) running Windows, c) via Steam.

PCs because this is a strategy game with a user interface (UI) that we knew would have multiple levels to navigate, which works best when you can rely on a player having a mouse and keyboard. We also knew that tooltips (the little boxes that pop up to provide contextual information) would be vital in conveying the finer points of the status of the game, which is something fairly straightforward to implement with a keyboard and mouse setup.

Early look at how the UI might have looked.

Windows because, and I'm sorry to break it to you Mac and Linux fans, the data we have doesn't suggest people play that many games on those platforms. There's a vocal minority that do, for sure, but the vast majority of PC gamers are running Windows. If bringing the game to various operating systems were as simple as clicking a different export button in Unity, this wouldn't be an issue, but there's always a good deal more work involved in porting across OSs.

Steam's official OS usage data here shows that the majority of players of all games on Steam in September 2017 were running Windows.

And Steam because the platform makes it easy to implement asynchronous multiplayer. A lot of people will assume we went with Steam because they have digital rights management, but honestly that wasn't even a consideration. We chose Steam because Valve made it easy for us to include asynchronous play that worked reliably, with turn notifications and a friends system for people to chat during games.

A smattering of strategy game owner data, via SteamSpy.

None of the above precludes Ogre coming to other platforms in the future . . . in fact, the port to Mac should be out by the time you read this! We chose to delay releasing Ogre for Mac because we wanted to get the game up and running smoothly on PC before hitting another platform. Each new platform requires the same amount of testing as was needed for the first platform. Two platforms, two sets of testing, double the hours and work.

The game could come to touch devices or consoles as well. But removing Steam (which is only available on PCs) means re-making the multiplayer back end, dealing with other online servers, and splitting a playerbase we'd prefer to keep together until it becomes more robust.

Consoles and touch devices have other challenges – making a UI that works well requires approaching the game from a different perspective depending on whether you have a controller or a touchscreen. And mobiles and tablets have so many different screen sizes and architectures that time spent testing and maintaining the codebase is magnified many times.

All the contextual menus in the game. As you can see, Ogre's UI is complicated.

For all of these reasons, we settled on using one platform to launch and refine the game before we even considered moving on to others.

Faithfulness to the tabletop version comes with a cost
Edge cases, exceptions, and rules clashes – these are things that automated rules systems handle poorly. They're also things that course through the veins of a lot of tabletop games, including Ogre.

Video games are essentially automated rules systems; any derivations from the overarching rules structure have to be accounted for with their own subsets of automated rules, and that introduces complexity and risk into a project.

For an idea of how complex this can become, forget Ogre for a moment and imagine the following scenario:

In front of you is a deck of standard playing cards, face down. The goal is to keep drawing new playing cards until you reach the end of the pack. You keep drawing cards, turning them over when taking them into your hand so you can see their suit and value. You get to the end of the pack and you win. Easy.

Now you add in a rule: if you pick up a red card, put it into a separate pile on the desk. Again, you get to the end of the deck. This is an exception to the main rule, but it's a fairly simple one.

Add another rule: whenever you pick up an Ace, if you don't pick up another face card (an Ace, Jack, Queen, or King) within five draws, you have to shuffle the red cards back into the deck. This is a slightly trickier exception to remember, but it's not impossible.

Keep adding exceptions and see what happens to the complexity:

• If one of the face cards is upside down in the deck it doesn't count.
• If you pulled a black Ace but a red face card, it gives you five more attempts to pull another face card.
• If anyone comes into the room while you're doing any of this, flip the deck over and start counting from there instead.
• And so on...

You can see that, even in the physical realm of games, this is getting to be a pretty unwieldy set of instructions for the player to remember and navigate. Now imagine the complication that is introduced when you add the layer of abstraction that comes from converting an analogue process into a digital one.

First, you need to program an engine to understand properties like game start, game end, objective, deck, top of the deck, bottom of the deck, hand, pile, draw, card, black card, red card, face card, card orientation, face up, and face down.

You then need to program in the rules that govern how all of these elements work with one another: for example, "you draw a card from the top of the deck, it moves to your hand."

Can you see what happens when you start to combine these exceptions? Here's an example: "you draw a card from the top of the deck, and it moves to your hand except when you have picked up an Ace five turns previously and you haven't drawn a face card of the opposite color to that Ace (in which case you have +5 more draws remaining) and no one has entered the room causing you to draw from the bottom of the deck (in which case you should flip the deck and draw from the bottom of the deck instead of the top and repeat this logic) and you haven't . . ." etcetera, etcetera, etcetera.

Now try to imagine the kind of logic required for Ogre. Think about infantry and the properties they have and consider some of the exceptions these might generate;

• How many infantry units are there?
• What tile is the infantry in? Does it have any effect on the unit? Can the unit submerge?
• Is the infantry mounted? Is that mounted unit disabled? Is that mounted unit on a train?
• Has that unit moved this turn? Has the unit combined this turn?

And that's just infantry. And that's just the logic in the game engine.

Faithfulness to the tabletop version, continued
When you're playing with cardboard pieces on a table, all the gameplay is either physically represented in the room with you, or in the more ethereal mechanics and statuses that are analyzed and resolved in your mind (which is also in the room with you, we hope).

With digital games, everything has to be represented on the screen. While this might initially seem like an easy part of the game transition, visually representing these substanceless rules and systems and telegraphing them to the player is very tricky. When you add exceptions and edge cases, it becomes even harder.

Ogre has 2,200 test cases to ensure everything is working correctly, due to the number of different components. Ramming alone has almost 300 different tests.

Representing an infantry unit of 2 is fine. It's two soldiers on a hex grid. Add more statuses to this unit and things get very complex. How do you represent an infantry unit of 2, that has done all of its movement, and is in water, and is submerged, when the player is attempting to combine it with another unit that it can't be combined with? Conversely, how do you represent an infantry unit of 2, that has done all of its movement, and is in water, and is submerged, and is on the same hex as another friendly unit, when the player is attempting to combine it with another unit that it can't be combined with?

Think infantry are straightforward in terms of gameplay? Think again.

It's questions like these that keep our graphic designers up at night.

No but seriously, faithfulness to the tabletop version is hard
Not to put too fine a point on it, but this faithfulness to the tabletop version has yet more considerations.

Does a map have a one-off rule, like "the Ogre cannot enter this specific hex"? The engine has to take that into account and the player must somehow be visually reminded of this stipulation.

An extremely early version of the editor we used to create the maps in-game.

Does the scenario state that you can only deploy a specific set of units? That also has to be designed and conveyed to the player.

Does the game have a rule that basically boils down to "players sort out how this resolves between the two of them?" Well gosh, computers are rubbish at that.

I could go on endlessly about the multitude of angles and questions and permutations that crop up in getting the rules onto the screen, but I think you've got the idea by now. Let's move on to some of the social aspects that must be considered by game designers.

Bringing fans together can be divisive
The "social contract" is a term that's been discussed in the context of games a lot in recent years. Broadly speaking, it means the formal or informal rules agreed upon or mutually understood between players of a game. Not upending the dining room table you're playing on just because you lost, or not bringing weighted dice to play with, are both examples of common social contract rules, which are obviously important for the better enjoyment of a game.

When playing in the same physical space, the social contract is more readily adhered to because the punishment for not doing so is immediate and long-lasting – we all know someone from the hobby store no one wants to play with because they're a sore loser. Video games have been unfairly criticized in some quarters for not featuring this "social contract." The anonymity of internet play is often blamed for allowing players to do away with the social contract entirely, which can ruin the enjoyment of others.

But in my experience, that's not true.

Maintaining a social contract online requires the same constraints as in real life: a) ensuring that the space created doesn't encourage players to break the social contract for personal gain, and b) moderating the player base so that rule-breakers are punished (or at the very least, marginalized).

When we created our adaptation, we made the rules very clear. They are enforced by the rules system, which is authenticated by the server. But strategy games with other players are much more than just their rule sets; they're also the environment of competition they create. So we also had to consider how two players, potentially in totally separate parts of the world, would interact outside of the rules system.

We made Ogre's multiplayer in such a way that it's not possible to finish a multiplayer game without winning, losing, or conceding, which ensures that players participating in Ranked matches always get a satisfying conclusion to their current game – you win, or you lose, which raises or lowers your ranking. And it all happens within a maximum amount of time; multiplayer turns must happen within a set period, so that players cannot attempt to wait out their opponent, hope they get bored, and win by default.

We also want the online community to be, to a large degree, self-sustaining with minimal interference from us as moderators. However, we also want to ensure that the space is safe and fun for everyone. Because of this, we decided not to include text or voice chat.

This may seem counterintuitive: one might suppose that giving players more ways to communicate would make for a better multiplayer game, but we've found that Steam's built-in communication tools are more than enough for when friends want to talk. Community members keen on playing with one another can organize themselves to speak with each other using this platform, too. Randomly matched opponents at best don't have much to talk about ("good roll," "nice move," etc.), but at worst have some pretty terrible things to say to one another ("you're cheating," "you suck," etc.). Leaving out direct text or audio communication helps to prevent insults and harassment without undue policing from our mods.

Smooth online play demanded slight changes to Ogre
While we're on the subject of online play, it won't have escaped the notice of veteran players that we had to make minor changes to Ogre's gameplay to make it truly asynchronous.

Asynchronous play is important because it allows us to do truly turn-based gameplay – i.e., you go, I go. It means that someone in a time zone halfway around the planet doesn't have to be awake at their computer screen for the entire duration of their Ogre match. It also allows for a player to have multiple games of Ogre in progress simultaneously.

Generally the Ogre tabletop game is asynchronous, but there are a few instances where this is not the case. For example, Overrun.

Overrun isn't a situation most players are going to enter lightly. Because the defender gets the first attack and double strength for Ogres and infantry, you only go into Overrun when you're sure you can win. This isn't much fun for the defender, especially if the combat goes on for a while, as they have to sit there taking pot shots while knowing full well they're just there to watch their units die. In addition, Overrun can potentially last quite a while, especially when Ogres are involved. It could in theory go on forever, but even in a rational universe it could last 5-6 rounds, which in a play-by-post game could mean several days for a single combat instance.

In situations like this, we decided that in service of the desire to have a fully asynchronous game, we would automate these moments where an opponent player has a decision to make during another player's turn. We use AI to resolve Overrun; it chooses targets according to a prioritization system that follows the entire AI decision-making process. An AI can do the job of losing just as well, and spares the player time and frustration.

This is one of the rare occasions where we deviate from the rules of the boardgame, but in practice it's not much of an issue. Automating the process provides the best result for both parties and it makes for a much faster multiplayer experience that works better for Ogre in the medium of a video game.

To RNG or not to RNG
Digital adaptations of tabletop games, especially when they're tabletop games with dice, use Random Number Generation (RNG) in place of the act of physically rolling dice. Lots of other strategy games that didn't begin as boardgames also use RNG to decide the outcomes of interactions between play pieces. But games with RNG run up against a persistent problem: when things are going well for a player, the dice are "fair," but when luck favors the opponent, suddenly the dice are "weighted" and "not really random." There are many psychological studies about why this happens, mostly centered around theories of confirmation bias.

To avoid this happening, some games today deliberately skew the RNG at opportune times; you might have had a streak of unlucky rolls, so the game artificially makes it more likely that you'll roll well for a set period of time to make up for it. This isn't truly random and it's not something we ever wanted to include in Ogre, as we wanted to remain faithful to the spirit of the original game. Luck is a part of that.

Unfortunately, Ogre's dice receive some of the most persistent criticisms of the game to date by both press and players, who believe it is coding rather than fortune that has turned against them. Which isn't true at all. But that is somewhat cold comfort when we're faced with negative comments and accusations of game bias, because of a fundamental design decision in the original game and the psychological complexities that brings when translating it to digital. These are risks we knew about before we began making the game; we're confident in our choice, and we're sticking to our guns.

As of September, Ogre commands a "positive" rating on Steam, lending support to our belief that doing right by the fans would in turn encourage the fans to do right by us.

Wrapping up...
Despite all the difficulties, we do feel very privileged to have worked on Ogre – the granddaddy of sci-fi strategy games that still holds its own as one of the best boardgames ever created. Of course we're biased in that view, but then we wouldn't have poured blood, tears, and radioactive oil into the project if it weren't important to us. It was and it is.

I hope you've enjoyed this look behind the curtain of our development process. There's much more we could say about how we made the game, and I hope in the future we'll get to share some more insights in another article.

In the meantime, if you have any further questions about how we translated Ogre into a video game, drop us a line on the Steam Community Hub.

---

The Ogrezine PDF, combining all of these articles with additional new material, may be purchased on Warehouse 23.