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.