Yesterday’s helpful playtester screeching_goat produced this colony using some of the newer features of the game. Note:

• The dumping area for scrap metal produced by various disasters destroying chunks of the colony (as well as falling from the sky as your destroyed ship deorbits bit by bit).
• The small but growing graveyard in the top left. Thankfully they’re all dead raiders.
• Some dead raiders laying around the perimiter, yet to be buried.

Screeching_goat was having trouble recruiting one of her prisoners, so she sold him into slavery. Charming!

In other news, today I’m working on character histories. Each person, whether colonist, trader, or raider, now has a few lines of personal history covering the stages of their life before they arrived at the colony. So now you can see why that raider you recruited was so good at farming.

One of the classic problems with the A* pathfinding algorithm that Rimworld (and nearly every other remotely similar game) uses for pathfinding is its behavior when there is no path from source to destination. It tries to find a path to the destination, and just keeps trying, scanning square after square, until it has covered the entire map and finally realizes there is nowhere else to go. This massive computational burden causes a performance dip which manifests as a hitch in gameplay as that one frame takes ten times longer than the others to render.

This can become a serious problem in EC. Say you put a weapon in a room with no entrance. Raiders attack. Your colonists, looking for a weapon, try to path to the inside of the closet. And they fail, and fail, and fail, and the game grinds to a halt.

This problem is finally solved in EC.

Every walkable square in the map is marked with a zone index number. We use an optimized flood-fill algorithm to go over the map and fill out each walkable region with the same zone index. As long as we keep our region indices updated, all a colonist has to do is check that the region index where they’re standing matches the one where they want to go. If they don’t, don’t try to path. We thus avoid the A* performance hit on unpathable destinations. The regions look a bit like this (created with random walls for testing purposes):

As a comparison, here’s a version with an earlier visualization. The more I learn about game programming the more I understand that writing good visualizations for yourself is key. It takes a while, but the payoff in ease of debugging is worth it.

And as a random bonus shot, here’s what it looks like in the Unity editor view. EC actually renders in 3D, and sometimes looks snazzy that way. I may end up exploring the 3D angle more.

Now the key challenge is making sure these regions stay updated. I can regenerate them all in about 5.5 milliseconds right now on a 200×200 map, which isn’t bad. But that’s not good enough to do every frame and forget about it. I’ll need to detect changed conditions like walls being built or blown up and regenerate the local reachability indexes. The world of EC is rather unstable, what with the constant threat of colonist psychosis and marauding pirates. So I expect reachability to change a lot.

It used to be that a game of Eclipse Colony would start with the player spending skill points to build the skillsets of their starting characters. This didn’t work that well (and, in fact, was always a temporary solution). People didn’t really know what the skills did, and all the numbers were a bit overwhelming for the starting moments of a new game. It needed to change.

I’ve been inspired by how tabletop RPGs handle characterization. One of the ways some pen-and-paper RPGs do character creation is by having players create histories for their characters. You choose from a library of childhoods, a library of adolescences, and a library of adult experiences. Each one comes with a chunk of story, some skills learned, and perhaps some other effects. The finished product is a character who isn’t just a bundle of statistics, but is a story of the cause of those statistics.

Since Eclipse Colony is really about story generation, I thought this was a good path to take. This is the first version of the new character maker:

Currently you only choose a childhood and an adolescence, and the library of choices are quite small in each case. For now, this suffices. It hopefully won’t overwhelm playtesters with choices (as I suspect would happen with 3-5 life stages, each to be chosen over three characters). RPGs can get away with more complex systems because people expect to spend hours making characters, and you only have one to make. I’d like to keep it more lightweight to start with.

But there are obvious ways to expand. I’m considering special effects that history items can apply (physical disabilities, phobias, special abilities), additional history sections, auto-generated histories. As always, the endless possibilities are tantalizing and difficult to resist exploring.

But there are still lots of other parts of Eclipse Colony that need to get made.

We’ve finally got an encyclopedia in the game. I’m calling it the Codex. As always, we’re starting with the plain but functional look. Prettification comes later, after the design solidifies.

It would be really nice to have a game where this wasn’t necessary – where absolutely everything was obvious, or invisibly taught to the player using some genius adaptive training system. And I get as close to this as I can. I work hard to make sure things are clear and comprehensible and pleasurable to interact with. I drop a lot of design ideas just because there’s no good way to express them, or interface with them. But despite all that, I think this is still the kind of game where people need to be able to just look stuff up when they want to find out how something works.

For a while, I thought the game could teach players all the game systems on-demand, as necessary, in a semi-adaptive training sequence that would teach you things as by watching the game and deciding what you needed to learn next. I’ve discovered that this isn’t a complete solution. Sometimes, it’s just impossible for the game to figure out what the player wants or needs to learn. The system can tell when the player has no food source and needs to be taught about producing food. But I can’t tell when they’re, say, confused as to why their air is leaking out because they don’t understand the air system (because the game never taught them).

There’s just one more major piece left in my recent usability push. I haven’t added much in the way of new world simulation in a while – it’s been all about making what’s there accessible. Hopefully after this next thing I’ll be able to get back to making the simulation deeper. I really want to get corpses in there, because there are so many interesting things that can happen with corpses.

In today’s game, a nice little raider assault on my southeastern flank, which lacked heavy auto-turret coverage.

Thankfully, I’d traded with a passing combat supplier a few days earlier, so I had an M-24 sniper rifle at my disposal (in use by Daft in this image).

It’s amazing how the detail work of getting something right can take so much longer than the baseline work of getting it functioning in the first place.

Today I spent the entire day working on the commodity trading interface. And I’m pretty sure I’m not even done. But, at least, I think we’re improving.

Now traders can pay and offer different prices when buying and selling commodities. They’ll always offer to pay less when you sell to them than they’ll demand when you buy.

In addition, traders have a stock that depletes. This stops some absurdities in gameplay, and means it”ll be important just who visits your struggling little colony. If you’re depending on food from the stars, you better hope a farming vessel happens by.

Here’s the old interface:

It got the job done, but there was some weirdness. What’ that second column mean? And what’s it mean when the trading number is negative? And, of course, the aforementioned issues with traders having an infinite supply of everything. The exploits got extra fun when there were two traders in the system at once, one trading a commodity for less than the other.

Here’s the new interface:

I’m not worrying much about making things pretty at all. These days it’s all about making things clear, bug-free, and compelling from an interactivity standpoint.

It’s still not as stupid-simple clear as I’d like. But it expresses the concepts I need, I think.

There’s a lot to deal with that the screenshots don’t show. How do you handle players trying to set up deals that they can’t afford? Or trying to buy more than the trader has? Do you stop them immediately? Where and what do you flash to indicate something was wrong?

I mixed the solutions – if you or the trader don’t have enough money to fulfill the deal, I still let the player set it up, and only give the rejection notice if the player tries to execute the deal. This makes it easier to move the numbers around towards the final deal that you want. Before this, players would constantly hit the money limits of themselves or the trader when only trying to setup a deal they knew would work.

Stock limits I handled differently. If the player tried to set up a trade where they or the trader didn’t have enough stock to cover the deal, the system would immediately stop them.

I think this mixed solution feels best. You’re not constantly being blocked while setting up deals, but there’s only one variable (final balance) that you have to ensure lines up before the deal will go through.

You’ll also notice the data in that second column from the first screenshot is gone. That’s because it’s rolled into the player totals. What the old “purchased” column indicated was the number of the commodity that the player had bought but had not yet been delivered. You could “un-buy” these by selling that commodity. I ultimately decided it was unnecessary; now the game just tracks the totals of everything you’ve traded since you opened the trade screen. Only when you close the screen does it resolve who got what, pull resources from your bank to go to the trader, and spawn drop pods to deliver what you’ve bought.

And working this out took all day. I love it. As always, it’s those endgame details that get you. Hopefully this solution will hold for a while.

Ludeon Studios exists.

Its purpose: to design and sell unique and fascinating story-generators (also known as “games”).

Its first project: the deep space colony simulator currently known as Eclipse Colony.