There are now shadows from the sun in the game. They fade in and out based on time of day, move across the ground, don’t shade indoors, come from people and small objects as well as large structures, project to varying heights, and change color slightly to complement the color of the sky.

This involved creating a whole system for roofing as well – it tracks which areas are roofed, shows you when you create a new roof, and collapses unsupported sections.

It’s always amazing how many times one simple system demands that you model something that seems almost unrelated. The logic of the world is very interconnected; it’s tough to simulate one thing without simulating the things it interacts with.

On the gameplay side, I’ve been working on the power system. So look forward to solar and geothermal plants, power surge and explosions, power cables, battery stacks, and solar flares to shut down your machines.

I’ve created the IndieDB page for Rimworld. Take a look.

First, some new screenshots from a game I played last night. Raiders attack:

The fight’s aftermath, with raiders buried.

The base:

And a pseudo-3D shot of what the game looks like in the editor, just for fun.

I’ve been working on the electrical system recently. Now, various machines including doors, air generators, gun turrets, lights, and food dispensers require power to work. You can generate power via  couple means including solar panels and geothermal plants. But each generation system has downsides – solar panels are large and don’t work at night (requiring power storage), and geothermal requires you to have a plant on top of a geothermal vent, which may be far from your main colony and tough to defend.

Without power, machines don’t work. Lights turn off, doors must be opened and closed manually (which is slow) and food doesn’t dispense.

Long ago, I got my start in game design modding games like Unreal Tournament. So I’ve been setting up Eclipse Colony to be moddable for others as well.

For the most part, this just means keeping game data in text files instead of locked up in code. For example, here’s a short section of XML describing a couple of the character histories that people can have in the game.

You can see the titles, written history (which adjusts for character name and sex in-game), skill bonuses and demerits, work disables, and so on here. I’m going to use a similar method to describe animals, buildings, and many other things in the game.

Adding data to the game is as easy as writing an XML file and putting it in the appropriate folder. On startup, the game just reads out all the data from these folders into the databases it uses during play. So, if you write your persona history as a character background, you’ll be in the game’s library, and you might spawn in as a pirate or slave or visitor.

You can also put in images. So, you could make a special animal with a weird diet and a custom graphic, just by putting the appropriate files in the right folders.

It should be pretty simple to come up with a basic interface for switching between or layering on different mods. That way, people can create their own file structures in parallel with the game, distribute them, and then players could enable and disable different combinations of mods.

All this is pretty far in the future, of course, but I’m pretty excited about it. It’ll feel good to be the one enabling others to try their hand at game design, after having started out on the other side of the equation so long ago.

I’ve been working hard on improving the look of the game.

Here’s a shot before the latest improvements. This is tester screeching_goat fighting hard to survive a tough raider attack (she failed). This shot one has an early version of edge shadowing in it – see if you can tell the difference from later shots.

The graphical improvements have come in four subsystems.

Character graphics

Previously, every character was represented by a colored dot. Now, each person has a body model that corresponds to their key adulthood history item. So, an ex-farmer oaf will be a big fat dude. An ex-scientist is a thin figure wearing a suggestion of a lab coat. A noble wears purple. These characters have three frames of animation (front/side/back) that they switch between as them move around to give a sense of interactivity to their movements.

Heads are tracked separately and chosen randomly for each character based on their sex. So the overall identity of a person decodes visually as: Body shape indicates archetype, head indicates individual identity.

I hope players will be able to get to know their characters more easily this way. I think people respond well to classical archetypical characters and I want your colonists and enemies to express these. It’s as much about expressing personality as it is about telling characters apart or looking pretty. Because this game really revolves around character.

Edge shadows

This was a straightforward system, but worth mentioning. Edge shadows now wrap around the base of every tall object in the game. To do this, the game generates a mesh that wraps around the edges of tall objects every time the world changes. The vertex colors of the mesh are set to be dark near the object, fading to transparent, so it creates a nice subtle shadow over the background. Since it only uses vertex colors, it can be updated quickly without any texture maps ever being involved. It fakes a bit of the global shadowing effect that tall objects have on the ground around them and makes things feel a lot more grounded.

Lighting overlay

This one was a bit of a project, and it’s still ongoing. The game now tracks the light level of every square in the game, and how much of that light is contributed by on-the-ground lighting instead of from the sky. As the day progresses, the color of the skylight shifts from daytime white through twilight orange into midnight blue. In the day, you can’t see your ground lights because the whole world is fully lit anyway. But at night, they become points of light in the darkness.

Making all this work was a fun exercise in shader writing and mesh generation. As with the edge shadows, the whole system is driven by changing vertex colors. These vertex colors are fed into a shader that overlays a light color over the map. The light color is determined by the vertex colors (which are driven by ground lights) and the sky light color (which updates every frame based on time of day).

Figuring out how ground lights spread was a fun challenge. I actually ended up using a pathfinding routine called Dijkstra’s Algorithm to make the light spill around corners properly. This simulates a sort of radiosity in a 2D tile-based world, and looks far better than just doing everything by straight line of sight.

Lighting isn’t just a visual effect. It affects gameplay.

• Characters don’t like to be in the dark
• Darkness affects their ability to do things.
• Plants need light to grow.

I’m hoping we’ll see things like:

• Players building over-brightly-lit hydroponic grow ops like something from a pot dealer’s basement.
• Players setting up combat-field floodlights to illuminate the enemies they want to shoot.
• Players freaking out when an electrical storm knocks out their power in the middle of a medical operation (causing critical mistakes) or an attack (depriving the defenders of light to shoot by).
• EMP weapons could create these effects deliberately.
• Some characters could be afraid of the dark and have extreme reactions to it.

Here’s some lighting shots from a simple base I made. The first is at night, the second at dawn, the third is a detail of the first.

Terrain modification

Whereas before terrain was basically just a big fake alpha-blended map that meant nothing, now each square has a specific terrain type.

The visual challenge here was figuring out a way to get every kind of terrain to blend properly with every other kind in arbitrary combinations. This is actually a bit of an open problem in game coding, ad you’ll see if you try googling it.

The system I’m working with now involves giving each terrain type a layering precedence, filling each square with its appropriate terrain type, and then blending neighboring squares in when their precedence is greater than your own. As with the lighting, this is all driven by a set of layered generated meshes that I update when the terrain changes. This way, sand will spill over a concrete walkway a little bit at its edge, while concrete will but up against bricks in a hard edge.

But terrain modification is really as much of a gameplay improvement as anything else. With unambiguous knowledge of terrain, we can do things like:

• Have terrain affect what can be built where. E.g. you can only farm on soft earth, but you can’t build some kinds of heavy constructions there until you dig them out and change them to concrete.
• Have terrain affect movement speeds (e.g. you want to build a road to your mining operation)
• Have terrain affect people psychologically

Hope you enjoyed the update. Work continues at about as fast a pace as is possible without me going insane. I’m loving it.

I had one of those stupidly-obvious-but-massively-valuable insights that make me smack myself on the head and wonder why I didn’t do it sooner. The mountain.

The map no longer generates with random little rock outcroppings here and there. Now, one side of the map (could be any cardinal direction) is randomly filled with rock. This makes the mining-driven basebuilding strategy viable. Tonight I built the first mountain colony. Instead of spending time mining minerals to build metal structures in the open, I just mined into the rock. It’s good to see the game growing new strategies and offering new choices on the kinds of places you want to build.

In addition, since I finally solved our reachability problems, I’ve been able to push map sizes up. Even the modest jump from 200×200 to 250×250 creates a huge amount of extra space (just over 50% more). The world starts to feel damn big when a character takes more than a minute to walk across it. As map sizes increased, I’ve had to solve other problems. The game no longer saves every block of rock as an individual object, but compresses them into a single bitmap. This brought save game times and filesizes down by 20-fold, so now the game saves so fast that it’s hard to notice the “autosaving” popup.

This is the entire map of that mountain fortress (the above shot is at max zoom-out in game; I took this one in the editor)

To flesh out mining I brought back my old cut fog of war system. Only now, it only fogs the insides of rocks. Exploratory mining, hooray.

And there have been other new features, not all of which I want to give away here.

PS: Just to see if I could, I tried a 500×500 map. In the middle of the mountain edge you can see I designated several medium-sized rooms off a hallway in the mountain. These environments can get big.

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.