Seeing the forest for the trees, and the Tycoon in my RTS

Ten years. I’ve been at it for ten years in some capacity.

Iris Burning, a longstanding game project of mine, has existed in some capacity–assuming you count “things I’ve had in my imagination” as part of it–since 2015. I first attempted to actualize on it later that year, and in 2016, for my undergrad senior project, I turned in an exceptionally broken copy of it that lacked most of its core features. To be honest, I shouldn’t have graduated with it, but I did. I kept working on it until I got sick of the codebase being a war-crime, and after one particularly awful playtest session, I decided to reboot the codebase in 2022. The current codebase is based on this reboot.

This isn’t about code, though, it’s about a misgiving I have about my own game design. For the last ten years, I’ve misunderstood what I really wanted out of this game, because I have let expectations of the RTS genre color what I think it ought to be, instead of what I wanted it to be. I always said that I was developing a game for myself rather than anyone specific, but somewhere along the line I managed to stop listening to my gut and started just developing. Not a care in the world–and a whole lot of ignoring red flags I should’ve noticed sooner. So, what changed? When did I become so clairvoyant, and for what?

Iris Burning is a game about resource management, and it’s taken me this long to realize it. It’s got the corporatist parody anarcho-capitalist coat of paint that tells players to make a ton of money and win–but the reality is, the game wants you to exploit the land, because that’s how the money is made. The problem is that doing this fucking sucks.

A tedious progression

Players generally do five things:

• Prospect (scout for a resource)
• Harvest (get the resource from the point, and put it in your inventory somehow)
• Hack (find a spaceport to launch from, hack its computer to give you the opportunity to launch)
• Haul (send a truck full of stuff you harvested to the spaceport/launchpad)
• Launch (send product offplanet for cash, at risk of someone capturing it and nuking your profits)

At various stages of gameplay, the player gets to streamline parts of this process, but the thing that sucks about this is the early-game. This isn’t great, because the early game is the first impression of the core loop that the player gets. If they have to do tons of busywork, they aren’t going to stay interested for long. Strategy gaming in general tends to edge closer into busywork, yes, but not like this. Not like the level of tedium I have subjected players to.

Let’s expand on that tedium a bit. What does the player actually do to get from “never made a buck” to “small profit of a million dollars?”

Prospect

The player must find a resource point. The map generator guarantees there will always be at least one modestly profitable resource point to harvest from. The player still has to go find it. This can be done with a scout unit, or if you’re ballsy, just send your Harvester out there, defenseless, to scope it out. You’ll need a Motor Pool or equivalent to produce either of these units.

You’ll also need a Launchpad, from which you can sell the stuff you find. I’ll expand on this part later.

Harvest

Cha-ching, you found a resource point. Tear it up, and bring it home. What exactly is “home?” Is it your HQ building? No, it’s a Warehouse. The HQ doesn’t hold things like the Warehouse does. The Warehouse is a building that serves as a compartmentalized inventory. Harvesters tear stuff up, bring it to the Warehouse, drop it off, and go back if there’s more to harvest–same as Starcraft harvesters, generally.

Hack

That stuff you harvested? You can wholesale it, right now. That kinda sucks though, because you lose 80% of your potential profit if you do that, the idea being that some poor fucker has to land on Iris, pick up the payload, then launch back into space themselves. They won’t do that for market-rate goods, but they’ll do it for a good deal, and in Iris Burning, that’s 80% off the actual value. You need a Hacker to take over a Launchpad you can launch from, to get around this epic shafting of profits. (You also need to find a launchpad. If you made a scout unit while prospecting earlier, you can go find a launchpad that way).

Assuming you have a Hacker, and you’ve found a Launchpad, you can go send the Hacker to take over the computer system of the Launchpad and give you the ability to launch.

Haul

Rev up that Motor Pool again, you’ll need a Hauler. A Hauler is a giant semi-truck-looking guy that picks stuff up from your Warehouse and sends it to a Launchpad of your choosing. Once it drops off to the Launchpad, it goes back to the Warehouse for the next payload (assuming you told it to).

As stuff accumulates in your Launchpad via the Hauler, you’ll see Pending Profits appear in the UI, which is finally what you want.

Launch

Select the Launchpad you captured and loaded up, tell it to initiate the launch, and watch the countdown. Also, defend it. Enemy factions and even some mobs on the map might try to hack it and take it back from you. If you don’t own the launchpad when it launches, you don’t get the profit it makes. Also, everyone on the map knows when you start a launch, and they know exactly where it happened. Best of luck!

A bunch of overcomplicated bullshit

That seems straightforward, right? No, unfortunately, it kinda blows. I could probably write a wall of text as to why this is tedious, but if you lay it out visually, it becomes clear how unclear this system is.

For starters, players need to know about their prerequisites. They cannot proceed without at least a Motor Pool and Warehouse. They must at least have a Harvester, Hacker, and Hauler. They must find a resource point, and find a launchpad to launch from. They must hack that launchpad to acquire control of it. They then have to harvest, store, load, unload, and launch, in that order.

Jesus fucking Christ, what a mess. No wonder it felt like I was going through motions when I’d test it. It was a series of chores to do to get the dopamine hit of “I just made money!” Which, by the way, is the entire goddamn fucking point of the game. God help me. What have I done?

The game is a logistics game. Encounters are defined by combat, which serves to provide forward adversity to the player… specifically when doing logistics things. I’ve spent all this time developing intricate systems and behaviors for units, mobs, and enemy faction AI, when I could’ve been spending it developing the fucking logistics game. Because that’s what Iris actually is. Amazon makes their money as a logistics company and web service company, I could stand to learn from one of the many examples I’m parodying.

It’s an RTS with tycoon elements. Tycoon RTS, as one player put it. I’ve rolled with that two-word elevator pitch for a long time, and yet I haven’t really taken it to heart. As it turns out, I am describing Transport Tycoon if the resource points were dispersed in a way that require players also handle the role of the industry buildings in that game, and if the enemy companies were trying to kill you. That’s what this is. How the fuck did it take me so long to see this reality?

How do I unfuck this?

OK, we understand the problem. We understand the nature of what is going to upset players most (it’s busywork). What can we do to address these impedance mismatches between what I want players to do (interact with capturable points on the map that force interaction between factions, mobs, and players, and facilitate large profit margins for the player) and what players want to do (make a bunch of money and blow some stuff up in the process)? I’m promising the latter, and trying to do it by executing on the former, but the execution needs work.

I know I’m technically competent, so this obscene blind spot had to come from somewhere, and I think it comes from wanting to replicate player expectations of RTS games. Players have the same intelligent monkey-brain that I do. They like big boom, and they like ordering little dudes around making big booms on each other. That, with some other mainstays like basebuilding, is what people fundamentally associate with the RTS genre. The strategy involved in appropriately big-booming your enemy is, for most players, RTS.

I realize as I look at this… [gestures broadly at flowchart] thing, that I have been going about it the wrong way. In Iris, RTS is the interaction layer. Logistics is the core layer. I need to reinforce this relationship, and that means sitting the fuck down, shutting the fuck up, and analyzing what I can do to make the logistics systems feel slick as hell. Iris is a strategy game. It might be correct to say Tycoon RTS, but if I ignore the Tycoon part, then what I have left is a halfbaked RTS. That’s no good. I need to analyze what’s missing.

I learn through example. I need to examine a game that did this right, and ape its concepts a bit. I am intimately familiar with Transport Tycoon, due to it being the first big hit of RollerCoaster Tycoon maverick programmer Chris Sawyer. Let’s look at that first. What makes it a good game?

Autistic train games

OK, first of all, before the greater ND community demolishes me: yes, I did get a diagnosis. I get to make fun of myself a little bit. Transport Tycoon is definitionally an autistic train game.

Transport Tycoon plops you onto a randomly generated map. Scattered about are various industries and towns that you, the player, must connect via road, rail, plane, or ship. You must build stations for these vehicles to stop at, and depots for them to stop for repairs occasionally. You tell the trains where to stop, pick up, and drop off. Power stations accept Coal deliveries. Cities to cities produce and accept Passengers and Mail. Farms produce Grain and Livestock, which is accepted by the Factory to produce Goods that can be used to grow cities.

What did Iris do here? A few things. Some of them are RTS-specific, some of them are headass decisions made by yours truly.

1. Fog of War – In Iris Burning, points (industries, in TT terms) are not immediately apparent to the player. In Transport Tycoon, you have the whole map available to you. You can see where to pick up and drop off anything you want, so you can plan how to best build your train routes. Contrast to Iris where you must go out of your way to find the pickup points, but you get to set the dropoff points yourself, via warehousing.
2. Warehousing – Transport Tycoon is entirely point-to-point. There is no warehousing or stocking up of goods. You solely provide the logistics service of moving some kind of Stuff from A to B. Iris basically gives the player the ability to store items they find, and at present, straight-up expects them to. If your harvester has nowhere to go with what it finds, it does nothing after picking up the item it harvested.
3. Sales – Profit in Transport Tycoon is realized the instant a payload gets dropped off. You get cash for however much you moved, and how far you moved it. You, the player, are unconcerned with what happens to the goods after you drop them off. In Iris, you sell by wholesaling, or by putting it in a launchpad and defending it, as a means of tying the logistics subgame to the RTS subgame.

The recurring theme here is that Transport Tycoon provides a more streamlined experience because all that matters is plotting a route, building it, and setting a vehicle to run that route. Iris has vastly more going on. I’ve fixated on the complexity of it, but really, it’s best to look at what the player needs.

What does the player need to not feel overwhelmed by the micromanagey nature of Iris’s early game?

The macro

There’s big, sweeping changes to make, and there’s also small ones. There’s no magic bullet in either macro or micro, but I think the important thing to do here is to approach it from the lens of the player, and adjust accordingly. I’ll look at the big stuff first.

1. Reduce number of things needed to be built and done. Players should be able to launch stuff offplanet without a launchpad, but there should be limits. The HQ has a built-in landing pad in the model I wasn’t using yet, I could conceivably make the HQ into its own warehouse, with a significantly limited capacity for storage, but the ability to also launch stuff quietly offplanet. This reduces the number of buildings the player needs. I should also make the HQ capable of producing earlygame units, perhaps just a bit slower than a dedicated building, eliminating the need for the Motor Pool in the early game.

   

2. Cordon off the launchpad system at first. Launchpads shouldn’t be the only way to make money. The wholesale penalty should be softened. A little under half-price should be fine. I can adjust it later as needed. It might need a cooldown, but I won’t bother yet. The need (or not) will be indicated by playtesting. Assuming I go with the HQ being able to launch, I could even keep it relevant by making it so that despite launchpads being loud and proud (everyone on the map gets notified when you countdown and where it is), HQ launches are silent to the other teams, providing a guaranteed “safe spot” for players, and raising the stakes of protecting the HQ building. HQ also shouldn’t get the full profit, maybe like 75%, but that’s an improvement from wholesale.
3. Implement a slick way to manage which storage-capable building the harvester stores at. It should be simplified, but obvious. A route between the currently-being-harvested resource cluster and the intended dropoff point should be drawn to the screen when the player selects a harvester.

OK, we have our early game macro. What does the flowchart look like now?

Now that’s an improvement. Let’s inventory what happened:

• Only need 1 unit, technically: A scout unit can defend itself, but if you want to be a cheapass, you can send out a harvester to prospect and then harvest what you find.
• No launchpads to hack, just bring it home: “Home” for a harvester is now also the HQ.
• No trucks, no moving items: You no longer have these truck routes in the way, you immediately have access to selling these things for a greater profit as soon as they get dropped into the HQ.
• No buildings: The HQ doesn’t count, because it’s built for you at the start of the game. No more building two buildings first.

One unit, one building that already exists on your behalf. That’s so much simpler, and such a better introduction to the game.

Here’s the thing: I don’t hate the concept from earlier. I don’t even want to eliminate it from the game entirely. I just think it’s too complicated for players starting out. For the micromanagement to work, it should be a little more midgame. Moreover, it should behave predictably while also giving you the ability to customize it to really scratch that Autistic Train Game itch, but with RTS stakes.

That brings us to the micro.

The micro

The micro needs more fundamental changes, but a lot of it boils down to quality-of-life. Before I can broach that, however, there is the matter of addressing what secondary effects these mechanics were supposed to have in the first place.

When designing, it’s important to examine things from the lens of “does this actually help the game” instead of “does this justify the existence of a feature?” As such, here’s what enhancements to the experience I had intended from the more complicated design:

• Everyone knows when there’s a launch happening at a launchpad. I wanted the launchpads to be chokepoints, and for those encounters to be functionally like a tower defense minigame. They force players into specific geographic locations—an essential part of gameplay to pit enemy factions against each other, and cue players in to when they can opt in to a fight. Hostile mobs are configured to be interested in the sights, sounds, and actions associated with launching, creating guaranteed adversity the player must overcome.
• Having resource items change hands constantly creates a varying risk profile for the player. A harvester and a hauler unit are relatively defenseless and require escort. (Or you can be a cheap bastard and not bother.) Warehouses and other buildings provide the capability to stockpile items, opening the door to resources that can be consumed for, as an example, building certain types of buildings, increasing the intrinsic value of an item—but are, themselves, risky. They become loot drops and are therefore worth fortifying. Launchpads being able to change hands also shifts the risk from the loss of resources to the loss of profit.
• Hacking is supposed to be a greater-impact mechanic. There are other captureable points on the map that don’t do what launchpads do, but provide, for example, the ability to build satellite HQs so you can build outposts in the Irisian wilderness. There are ideas I have kicking around for hacking and capturing opponent buildings, though other considerations will have to be made for this to work.

A lot of the game’s features and late game design revolve around the assumption that these secondary systems exist and can be, or are, leveraged by the player. Much of this can be improved by simply ensuring the player has the information they need to make a good decision, ideally without overwhelming them. Finally, and perhaps most importantly, altering the systems so they automate better, so that the player mostly just has to set up stuff, will help bring some of that Tycoon streamlining into the fold.

Inform, streamline, automate. That’s how we make what was formerly the early game, now the midgame, more slick. This, too, requires elaboration.

At this point, if you’re still reading this, you either really like my game design diatribes, or you’re committed to the end.

Streamlining

I’ll subheading each change to make it a little easier to read.

Warehouses, Hauling, and Harvesting

Warehouses are kinda like little micro-bases or depots. Players should be able to refer to them as such and interact with them as such. Since both directions of a resource transaction (harvest -> dropoff, load at warehouse -> unload at launchpad) involve interacting with the warehouse building, it’s only fair that they be the centerpiece of the design.

• The association between haulers, harvesters, and warehouses should be made more apparent. Right now, it’s a loose association, but more tightly coupling the three makes it so that it’s almost like a warehouse represents a ‘squad’ of resource-managing units, and this can greatly streamline and simplify how players interact with the system.
• The warehouse buildings need to be able to produce both harvesters and hauler trucks. It should not be faster than the Motor Pool at doing this, but it should be capable of it.
• Harvesters and haulers need an obviously exposed way of indicating their current routes. They should show, in the UI, where they intend to go, in both directions.
• Warehouses should provide parking for the units that deliver to and pick up from them. This sounds weird, but having a visual, on-map explanation for what is associated with a particular warehouse provides a spot for units to go when they’re done with whatever they’re doing–a sort of rendezvous point or rally point, in RTS terms. Right now, these units complete what they were doing, and just kinda sit there afterwards. The player does get a notification that their task was completed, but that’s it. You still have to order them back somewhere else.
• Haulers need their orders to be made more configurable. At present, they will attempt to load and unload either one specific type of cargo, or all types of cargo, stored at the warehouse they are associated with.  This should be possible to do at an individual level in the unit’s order panel, but also be configurable from the warehouse’s inventory window.
• There should be a global inventory listing. You should be able to see, grouped by warehouse or by resource type, what you have in storage, across the entire map. I imagine players will have multiple warehouses and having to click into each one will get annoying.

This all boils down to:

• Strengthen the one-to-many relationship between the warehouse and its child units. Make the association more concrete and fully centralized around the warehouse.
• Make the warehouse able to produce certain kinds of units.
• Add some more order buttons to the units for things like “return to warehouse,” “snap to warehouse,” etc.
• Make it so that units can ‘park’ at a building they are associated to.
• Modify the warehouse inventory window to accommodate a UI exposure of all these different features.
• Assuming the aforementioned changes to the HQ building get added, make sure the HQ is also capable of parking units and showing associations. The capacity should be greatly limited relative to a warehouse.

When described that way, it’s actually not a lot of work. Probably 5-8 days of free-time work if I’m able to devote several hours a night, as I have to be up late for my new-dad duties anyways.  I’m sure I’ll notice some flaws in this roadmap as I go along, but that’ll be a future post I think.

Hacking

The hacking system is actually pretty OK as it is. What I want to do with it constitutes an expansion of capabilities, not a simplification. It’s already an insanely simple system for the purposes of how you interact with launchpads. There’s one QoL change that needs to happen, though:

• There’s no real visual indication as to who owns a hackable thing, launchpad or otherwise. This should be exposed in-world as some sort of lighting change, logo being shown to reflect faction ownership, or something to that effect. I’ll need to come up with something, but specifics are unimportant as long as it makes sense.

Launching

At this time, I don’t see a specific issue with the launchpads. I think they’re OK. It’s everything in the leadup to them that’s tedious and painful to interact with. They will need additional playtesting to confirm their funness.

Tying it all together

I don’t really have much else to add here. I’m embarrassed that it took me this long to realize how tedious yet underbaked the early game experience was.

I’ve been focused on combat units and mobs the last few days I’ve worked on the game, and it’s abundantly clear this is the wrong choice. I’m hoping this helps me pivot to something better, so I can go back to agonizing over the combat encounters to make sure those stay as varied as I’ve strived to make them so far (also, another post worth making in the future).