Space Date 15-9-84

The Void

Space is big and empty. I know, everyone is always going on and on about how inconceivable astronomical distances are. If there's one thing everyone knows about space it's that it's bigger than you think. The problem is, when you try to put an incomprehensible idea into context, all you accomplish is driving home how incomprehensible it is. The incomprehensible stubbornly continues to resist comprehension. The incomprehensibility of the bigness of space is overdone at this point. What doesn't get enough attention is how empty space is.

We think of space of being full of amazing things. This is fueled by spectacular pictures taken by powerful telescopes. These pictures of Earth from orbit, Saturn and it's rings, or colorful, far away nebula are beautiful, but that's not what space would look like when if you were there. It looks like the night sky. A flat, black and white field of stars. Even in the asteroid belt, the part of the Solar System that has the highest density of individual objects, the asteroids are so far apart that if you stood on one you wouldn't be able to make out a single additional asteroid. Almost all asteroids would be too far away to see at all. If you have very good eyes, you might see some of the closest asteroids, but they would look like stars. Only with special technics, such as carefully tracking their positions to see which ones move, would it be possible to identify which specks of light are stars and which are objects in this solar system.

Kerbal Space Program does an amazing job of making space manageable. It lets you zoom in and out over huge scales and even gives you control over the speed that time passes. You can zoom out until the whole solar system fits on your screen and you can make the years it takes for your probe to reach the outer solar system pass in moments. It makes the vastness of space comprehensible by letting you make space small. That's not what I want to do.

I want my game to be a way to experience the emptiness of space. When a player is in orbit around Earth, the planet should look huge and take up nearly half the sky. When the player leaves Earth to go somewhere, say Mars, the Earth should shrink quickly to a small ball and eventually just another speck of light. Then there is nothing. For nine months. I want the player's perspective to shift from being in a vehicle that is moving at bone crushing speed to being on an unmoving island floating in an endless void. The unchanging stars become just a background as the player's attention is focused on the ship and the things happening inside it. The whole solar system becomes an abstract idea as the only thing in the player's experience is the ship and the void.

I'm not sure I can deliver on that experience, but that's what I'm going for.

Space Date 15-9-83

New Walls

The 15th year of the epoch comes to a close in less than two weeks. Isn't that something.

I got walls, windows, and doors working. Now you can use the engineering console to place them and they will appear in the 3D space. It's kinda nifty, but they aren't just supposed to appear immediately. Someone is supposed to build them. I suppose I need to implement crew. I need a single robotic crew member to run around the ship. Once it exists, I can make it the construction bot and make it fulfil build orders created on the engineering console.

Space Date 15-7-66

On-board Communication

I'm trying to figure out how to handle collisions with the walls of the ship. Do I need a whole physics system? Should I treat the ship as a 2D map? I don't know. In the mean time, I want to tell you about a weird (and probably bad) idea I had for managing jobs and modeling communication on the ship.

The idea is that when a crew member is working, they would use their personal electronic device to check the chore queue for the ship. They would probably pick the highest priority chore that applies to them and mark that they're doing it so other crew members don't do it. That's probably exactly how micromanagement sims like Rimworld, Oxygen Not Include, and Dwarf Fortress work. It's the obvious way to do it. What I'm considering adding is that if the ship-board network is underpowered, the crew wont be able connect to it. They would wander around aimlessly, or maybe only do chores that are in the same room as them.

It would make sense for individual communication devices to still work even if the ship's network is down. That means that the player could still issue orders directly to crew members, or that crew members could ask each other for help. And asking each other for help is something I think crew should be able to do. Obviously in the case of an emergency, but also as part of more routine tasks. Maybe there are some jobs that are easier to do with multiple workers, like setting up a large machine. A crew member who took on a job like that would ask for help. One or more crew members might drop their own job to come help for a minute. Assisting others would have to be a job category that the player would have the option of disabling or adjusting the priority of. Just like any other job category, such as engineering or hauling.

It might be too confusing to actually work. Or it might make the crew seem more alive and the ship more dynamic. I'm a long way from needing to decide whether to put it in or being able to test it out, which is why I wanted to write it down.

Space Date 15-7-57

Sliding Doors

I'm proud to report that the doors now slide. Open and close and everything. My previous entry called out the two halves of doors as if it was an amazing innovation which would make my life easier. It was a fact a pain in the neck that I was forced into based on some of my previous organizational decisions. I think they turned out pretty cool. The open buttons beside the door don't look like much, but the art debt grows and grows. I wanted it to be little control panels, but I don't think I can make that look good. I really want to work with an artist.

Space Date 15-7-20


The day is the morrow, and I've come to a conclusion regarding my previous issue. I have decided to start on doors. I need doors anyways, but the thing doors give me is the ability to separate rooms. I think a strong concept of rooms will make the engineering console easier. Doors will have two halves, each of the two cubes linked by a door will include their own half of a door.

Space Date 15-7-19

Engineering Console

I've been stuck for a while on this console idea. It is turning out to be complicated. I'm going to right down the major features of the Engineering Console and the Navigation Console as a design exercise. This should help me see what are the common needs of all consoles.

This didn't help. There are too many pieces and I'm still feeling overwhelmed and I don't know where to start. I need to get this organized and find a place to start.

Space Date 15-6-44

User Interface

I never know how to handle the user interface. In my last attempt, I was very proud of my card system, but I don't think it works this time. I don't want movable windows hovering over the 3D world; I want all the UI elements to be in consoles the user has to click on. I want to go for a bit of a modem-punk vibe, with static, blocky UI elements on the side of the screen. Also, I think it's silly to code my own UI elements when I'm working the the browser. HTML is made for this sort of thing. Sort of.

My first UI is going to be the engineering console. It will be a place to view the map of the ship, and view and edit the structure. For now, I'm going to give it panning across the blueprint in all four directions, maybe zoom in and out, go up and down levels, and quit. Panning will be ADSW, the same as moving in the 3D world, but also dragging with the mouse. Zoom will be the mouse wheel. Going up and down levels will be the up and down arrows. I don't know what form the build/destroy option will take, but I've decided to not worry about it for now. I just need to implement these basic controls and put indicators on the screen somewhere. I'm thinking either along the bottom, or in the side panel at the top.

Space Date 15-6-32

Using Computers in a Computer Game

In 2D management games like Oxygen Not Included, interacting with things is very straightforward. You click on things and a little box opens up the corner. If you can see it, you can click on it. In 3D games like Satisfactory, you've got to run up to something to click on it. It's also very straightforward. The smelter has to look like it's within arm's reach for you to take stuff out of it. I'm thinking of going a different way, with a little less straightforwardness.

Here's the plan. There will be very little that you can interact with in person as you run around the ship. You can press buttons and open doors, but the big stuff like building rooms, setting crew schedules, moving the ship, and trading will all be done from consoles. You'll use the engineering console to plan construction projects like adding new rooms and moving equipment. Then, you'll leave the console and wander around the ship watching your crew carry out your orders. You can log into the HR console to check on the status of your crew members and manage their responsibilities. You'll use the navigation console to see your position in space and plot a course to your next destination. So the game will consist of running around and using the different consoles.

Space Date 15-6-26

I Guess I'm Starting Over

I really want the game to be a three dimensional world. I was trying to do it like Dwarf Fortress with z-levels that you can step up and down through, seeing one level at a time. I was thinking, if it's good enough for dwarf fortress then it's good enough for me. Now I'm thinking that dwarf fortress is not a shining example of usability. Dwarf fortress made graphical decisions based on what could be rendered in a console. Which is just text. I have multiple options for 3D engines, even if I want it to be a web based game.

So, it is my pleasure to introduce, the new 3D Safiina! It's live! You can play it now. It's a huge step back, feature wise. There's no robot, no items, no storage, and no construction. You can run around and fall off the ship though.

Everything takes so much longer in 3D.

Space Date 15-6-09

But What If The Space Ship Were a Submarine

I played Objects in Space, it's awesome. It's a little clunky. I turned off my attitude control without realizing it and it took me forever to figure out how to turn it back on. It is really fun.

This one time, the communication console beeped, I click on it at see I'm being hailed, the sender's name appears, but I don't recognize it. It's not a trading port. I check the radar and I can't see them. The long range radar has blind spots, so I spin my ship to try to do a sweep. There's the ship whose name matches the hail coming towards me. I accept the hail. They start threatening me and demanding I drop my cargo or they'll shoot.

I'm carrying like 90 credits worth of hydrogen. Not very much. I'd gladly jettison it. Before I can figure out the controls for the cargo bay, the radar console beeps and there's a torpedo coming towards me. I jump over to the navigation controls and spin around and fire up the main engine, but the torpedo and the pirate are gone from my radar. They're in my blind spot again. I'm about to try a quick spin to check on them when the torpedo shows up in my short range radar. It's still gaining on me. I perform a last minute 90 degree turn, and the torpedo flies right by me and disappears. I was left to figure out how far off course I was and what to do about it. It was slow and tense, and it was a lot of fun.

I love the drama introduced by the limited access to information, and the reduced set of actions. It made me want to buy some sort of anti-torpedo tech. I don't know what's available in Objects in Space. Chaff? Flares? Point defense? They've got to have something.

I also really liked the cyclops piloting in Subnautica. Compared to ships in Objects in Space, the cyclops is a very simple machine. You can move up, down, forward, and back. You can turn side to side. You can turn on and off your lights. You can set the engine at different power levels, including off. That's all the controls you have. As for information, you have the front window with a very narrow field of view. Well, it's almost 180 degrees, but it feels very narrow. Also, there's a simple proximity warning thing styled like a sonar. And there's a status graphic that shows you roughly where leaches are attached to the ship and where hull damage is.

I really enjoyed navigating the caves with the cyclops. It's a very long vehicle, and it's hard to tell how long it is from the pilot's seat at the front. You try to imagine where your tail is, and you watch the proximity detector. If you need to, you can climb out and have a look around. How close are you to to the cave wall? Are you clear to descend at this point, or do you need to swing your tail around first? If you make a mistake and hit something too hard, you have to get out of the pilot's seat and run around using your repair tool before you flood.

Then there are the sea monsters. They're very territorial. I remember needed to pass through a region where one of them was hanging out. I floated at the entrance to the cavern for a while, watching their pattern, trying to plan my route. I heard they were attracted to sound, so I turned the engine to its lowest setting. I creeped toward center of the cavern and began my decent. Soon the view from my window is restricted to just the wall in front of me. The tunnel is small, but I think I've lined it up right, and I'm descending at a steady rate. Suddenly, BANG! The warning light flashes and the sub tilts to the side. The proximity detector is going off on the tail. The health bar for the sub has gone down a little. I must be too close to the wall, but there's no time to repair. I've got to get out of the monster's realm first. I begin turning a little, when there's a bigger crash! I'm thrown across the room. There are fires, and water rushing in, and I see huge, ghostly fins swimming by outside the window. She found me! I'll never know whether that first bang was the wall or the monster. I rush back to the pilot's seat and turn the engine all the way up, the time for stealth has passed. I descend as fast as I can. There are a few more clangs, and the sub looses some more health. Eventually, the attacks stop and I bring sub to a halt. I grab the fire extinguisher off the wall and run around dealing with the flames. Then the same with the repair tool. Finally, as the water starts to drain from the interior of the sub, it's time to drop out into the water and see where I am now.

I'm being dramatic, but I'm trying to record the way these games made me feel. How fun it is to control a huge ship from a little cockpit. How it mixes the mundane and exciting.

Space Date 15-5-67

The Linux Shuttle

My computer died. There was a power outage and the server that I've been hosting off of never turned back on. I recovered the system by plugging the hard drive into a completely different motherboard. Surprisingly, it booted up just fine. I must say, going from a Pentium 4 to an i5 is a big jump. Either way, I pretty much only booted it up to get some data off of it. If the motherboard was old enough to die, then the hard drive probably wasn't far behind.

My new server is running Fedora instead of CentOS, and since it was installed with a desktop environment I'm now developing on it directly instead of through remote access. I'd kind of like to transition to using Linux as my primary home computer for a while.

I've also got art for the shuttle's landing pad. It has giant 'H' on it. I don't like that. The shuttle is not a helicopter. There was nothing else I could think of that would communicate "landing pad". I'll have to live with it till I come up with something better.

Space Date 15-5-54

Flying The Shuttle

Items that are bought or sold will be delivered or dropped off by a shuttle. I finally have a shuttle sprite and I have animated it a little. It flies in and lands and takes off again. It's pretty cute.

Here's how trading will work:

There's a lot to do still, but when shuttles work correctly, that will complete the Trade feature, which will be a big milestone.

Space Date 15-4-93

My Own Watch Function

Most of my display objects also contain all their own state. So far that has worked great. The robot object contains all the information about its own state, and it relies on no other objects for its display.

Menus are different. Menus show lots of data about the game state, but they contain none of the game state. I found myself wanting a 'bind' functionality like you might find in a proper framework. JavaScript had a watch function for a while, but it's ben deprecated and removed. So, I made my own.

Object.defineProperty(Object.prototype, "watch", {
  enumerable: false,
  configurable: true,
  writable: false,
  value: function (property, callback) {
    var descriptor = {};
    if(property in this) {
      descriptor = Object.getOwnPropertyDescriptor(this, property);
    var old_set = descriptor.set;
    var old_get = descriptor.get;
    var old_value = this[property];

    delete descriptor.writable;
    delete descriptor.value;

    var property_alias = "_watched_" + property;

    descriptor.set = function (value) {
      this[property_alias] = value;
      if (old_set) old_set(value);

    if (old_get) {
      descriptor.get = old_get;
    } else {
      descriptor.get = function () {
        return this[property_alias];

    Object.defineProperty(this, property, descriptor);

    this[property] = old_value;

This has a few features which I needed. It maintains the old value. It maintains any existing getter/setter functionality. It allows for multiple watchers.

It turns out this is a common problem. There are many libraries that will solve it for you. Most of them have an unwatch function, which I do not have.

Space Date 15-4-21

I Have Solved Word Hunger

It my simulation at least. The vicious cycles of instability caused by food has been mitigated. Turns out the solution was food storage. I just had to tweak the AI of my citizens so that they would prefer to keep a large stockpile of food (half a dozen days worth). Now when they start to run out and try to buy more, the market has a few cycles to react before the citizens loose productivity.

I should be able to start integrating the economy into the game now. The API is up and running for loading prices of goods, and I added a few goods to the simulation that I want the game to have access to. I'm hoping to get back to more frequent contributions and updates. We'll see.

Space Date 15-3-79

We Can Run the Economy, Captain!

I ported my old economy simulator to python and added it to this project. This is one of my least practical design decisions, and I want to talk about it.

It was always part of the plan to use the simulator on the backend, even when I started the simulator back in vestian year 13. It individually simulates thousands of citizens who manufacture, buy, and sell all goods. Each citizen has their own stats and preferences so what each citizen wants to make and own is different. Prices emerge as an equilibrium of supply and demand. I always intended the simulator to be the backend of a computer game's economy. I wanted players to buy from and sell to the citizens in the simulation directly.

I'm now thinking it will play a more passive role. The game client will download prices from the simulator. In that way, it serves as a pseudorandom number generator. When the player makes trades within their own game, those trades will be submitted to the simulator. The simulator will eventually incorporate them. This is the asynchronous multiplayer aspect to my game. For example, When a lot of players are bringing food to Mars, the price of food on Mars should drop and that will be seen by all players.

There are some problems.

Space Date 15-3-67

The Vestian Calendar

One space year is about 1157 Earth days. If something had a circular orbit around the sun with a period of that length, it's orbit would be in the asteroid belt. Naturally, I wanted to find out which asteroid had a year exactly equal to a space year. Of the 50 largest asteroids, I was disappointed to find that all of them orbit the sun too slowly. The major asteroid with the orbit closest to a space year turned out to be one of the largest asteroids, Vesta. Based on that, I want to call my space calendar the Vestian Calendar. That would make one of my vestian years 15% shorter than a year on Vesta, which you would also want to call a vestian year. This is extremely confusing. Still I'd rather talk about how vestian days than space days.

Space Date 15-3-61

Card Nests

I'm liking my decision to make a card-based UI system. It's not too surprising it's working well since it's similar to application windows in operating systems. I have successfully expanded the system to support tabbed cards and columnated cards. Both use frameless cards as sub cards. My first use of it is in a "Market" card. It has tabs that can be selected one at a time. Each tab is a columnated card with multiple columns. Each column is one of my "interaction" cards which have rows of basic UI elements such as text, buttons, etc. I might have cause to allow a row of an interaction card be another card. Nesting cards is fun.

Space Date 15-3-57

More Useful Cards

Trading is going to be a menu heavy feature. You'll select your purchases in a menu, monitor their progress in a menu, and watch prices in a menu. My current card system is not good enough for all the things the trading menus will need. This is the sort of thing that would be much easier to do in HTML. Arranging words, text fields, buttons, and other display elements is what HTML is all about. I'm finding myself in the awkward position of reproducing some of that capability from scratch.

The first things I'm going to want are numerical selector that lets you type in a number or increment/decrement by clicking, tabs, pictures, and columns.

Space Date 15-3-53

What's Next?

Alright, I got the logic for logging in and out working. It's a little clunky, but it works correctly. At least as far as I know. There could be bugs.

Before, I thought I would do trading next. That would involve getting the economy server up and running and creating lots of new dialogs and menus. It would take some new art and animations for shuttle ships and landing pads. It would be a lot of work, and at the end, you can buy and sell stuff. Is that fun? Maybe you can make a profit trading at a single port, and that will give you materials to build more storage. That's not such a bad gameplay loop, but it's not a very fulfilling loop all on it's own. It a better loop when you can travel from planet to planet and the bigger your ship is, the more cargo you can take and the bigger your profits are going to be. I think it's a supporting gameplay loop, not a core gameplay loop. I want the next feature I add to the game to be more fun than that.

Let talk about some of the games I like and see how they do it.

Rimworld and Dwarf Fortress

The first mechanic you encounter in these games is meeting the needs of your colonists. You have to build farms, kitchens, beds, heaters, and lights to feed everyone and keep them comfortable. You want more people so you have more labor to get everything done, but they consume more resources. Later, they do better if they have medicine, entertainment, and other comforts. Keeping everyone happy and working with the amount of labor available is a challenge. It's more satisfying to take care of the little people because you empathize with them a little.

Then there's the raids. You want more weapons and soldiers so you can defend yourself better, but the wealthier your group is the larger and more frequent the attacks are going to be. There's this weird dichotomy, where you're encouraged to grow and then punished for it. It's worth pointing out that in both of these games, growing is not a decision you make. New colonists appear periodically and are basically dumped on you.


Factorio is all about automation. The big loop is to automate processes to get materials to automate more processes to get even more materials. The satisfaction comes from designing and setting up a system and than watching it work. The pieces you have to work with are robust and varied enough that you can set up complicated systems. I spend most of my time in Factorio watching my factory and making little tweaks.

Surviving Mars and Banished

Both of these games will put you in a downward spiral if you run out of something important. They challenge you to use limited starting resources to get into a sustainable economic situation.


This is one of those "one more turn" games, but without actually being turn based. You never want to quit playing because there is always something that's about to happen. Ship that are about to arrive, a building is about to finish, or a research is going to get done. There's always something. Research enable better ways to generate minerals and you can use minerals to speed your research. Where Stellaris really shines, though, is in the stories it tells. Run away imperialism. Societies made of multiple alien species. Clashes of great space navies. Archeology to uncover the secrets of long extinct alien races. The roles of religion, biological modification, and artificial intelligence in high tech societies. There's a lot going on, thematically.


As I see it, none of these games have a single, core mechanic. The games only work with the combination off lots of systems. They have two or more systems that reinforce each other in a positive feedback loop, but growth is limited by some sort of diminishing returns. My conclusion is that there is no single mechanic I can add to make the game fun. It's also not going to work to just add systems until something interesting happens. The interplay and advancement of systems needs to be carefully thought out. I'm pretty confident that trading and interplanetary travel are going to part of the final game, so I might as well add them. It will give me more fertile ground for developing further systems. I'm going to go ahead and dive into trading.

There was an interview with Toady One, the creator of Dwarf Fortress. He described how he creates new features within the game. He will start with a story that he want to be possible in the game. Then he will add mechanics so that stories like that will be possible. Sadly, he didn't give an example. I think I need to start thinking of stories that I want to show up my game. Terraforming Venus might be a good place to start.

Space Date 15-3-47

The Login Prompt Again

Well, it's been 35 space days since I last made an entry in this blog. I haven't worked on the project much since then. I have to admit, I'm stuck on the login prompt issue.

I don't know how it's supposed to work. I want people to be able to start without logging in. Later, if they want, create an account. That's the part that has got me stuck. So, let me talk through it here.

It might be nice if there wasn't even a dialog box when the game loads the first time. But, only the first time, if you're coming back to continue your save, then you'd rather login so your ship can be loaded. So, I am making a dialog box that pops up right after the game has loaded. It has options to "Login", "Create an Account", and "Continue as Guest". That gives new players a really obvious way to jump right in and skip the nonsense and see what Safiina is all about. It also gives returning players a way to get back to their previous ship. It sort of takes the place of the title screen in traditional games. Maybe I should make sure the title appears when that script is displayed. Those title screens usually have options like "Play", "Continue", "Load", "New Game", "About", and "Settings". The home page will contain the "about" information, and there aren't any settings that can be changed yet.

This means that there are two different ways they could be playing the game, either they're logged in or they aren't. If they are logged in, I can save their progress periodically. If they aren't logged in, then I need to give them the option to login at any time. If they login to an existing account, then I will load the ship associated with their account. I probably should warn them that their current, on-screen ship will be deleted if they login to an existing account. If they create an account, then I will just save their current ship to the new account.

In a lot of ways, I am putting the cart before the horse. It's kind of silly to worry about different corner cases of user behavior when I don't have any users at all.

Space Date 15-3-12

The Login Prompt

A friend of mine tried to check out my game, but they saw the login screen and didn't go any further. It seems like the login prompt is more trouble than it's worth. It impedes my efforts to show the game to people. So far, the only reason people load my game is because I ask them to. I say, "Hey, look at what I made!" and people do me favor by checking it out. It should be easier for people.

I still need a user account to save the game, but most users aren't going to want to save. There not enough game to play to make anyone want to save their progress. I can just pop up the login form if a user clicks the save button.

Space Date 15-3-04

Construction is Working

I started on this game just under one earth year ago. (I know it sounds so stupid to say "earth year", but I've been labeling these post with a made up calendar and that means I have to specify which year I'm talking about) I just barely got construction working. It's the first major feature. At this rate, the James Web Space Telescope is going to launch before the game is worth playing.

I'm going to take a diversion to implement the minor feature of robot charging. It will be the first crew "need", and will be a prototype for biological needs like food and sleep.

The next major feature will be trading. It will require a couple new menus, a landing platform for a shuttle, a working delivery shuttle, and probably a few new item types including money. With trading, it will finally be a game. There will progression as you will be able to gain wealth and materials to make the ship bigger. There will be decisions to make as some trade options will be better than others. It will be a simple and pointless game at that point, but I still consider it an important milestone.

From there, the next thing will be to make the ship more like a space ship. Things like pressurized compartments, airlocks, interplanetary navigation, and perhaps most importantly, biological crew.

Space Date 15-2-99

VS Code

I'm giving Visual Studio Code a second shot. I got ftp-sync to work for me, though I'm still having some trouble with it.

These are my complaints:

There's a few more FTP extensions. Is it worth my time to evaluate those? After all, ftp-sync is working.

Space Date 15-2-95

This Blog

When I started this journal I had an idea that it would be a way to get people interested in this game and to share the development experience. I know that I really enjoy reading about the development of games that I play. Unfortunately, I don't think it's going to serve that purpose. It's not just that no one reads it, it's more that it's not very good. This poorly written, un-edited, rambling train of thought style is not very useful for communicating technical ideas. I'm afraid I veer back and forth between boring and confusing. I'm not going to fix it. It would take too much time to do it right. I'm not a talented writer. It's a good thing that these journals serve another purpose. They aid development by giving me a framework for thinking about problems I'm having. And to a lesser extent, giving me a place to record ideas I have that I don't have time to implement. So, I'm going to keep writing.

Space Date 15-2-81

Visual Studio Code

I tried out Visual Studio Code today. I somehow got the idea that it was the next new shiny text editor. It's another editor along the lines of Sublime. It does seem like it has some neat features. I especially like that the explorer bar has separate sessions for file system and opened files. Unfortunately, it has a single, fatal flaw: VS Code sucks at FTP. There are a whole host of FTP extensions, but none of them are great. The first one, "ftp-kr" is hard to use. The second one, "ftp-simple" is the only one I actually got to work, but I couldn't stand it. In order to actually see the files in the explorer bar, you have to download the remote directory, but the remote directory has thousands of files in it. Most of them are images. It would be great if I could configure the extension to ignore all files in the "img" folder, but the include paths only seem to apply to uploading.

Anyway, I'm back to working with Atom using the "remote-sync" extension. It's fine.

Space Date 15-2-63

Missed the Release Date

You may have noticed that the release date has come and passed. I did indeed miss the release date. I have done almost no work on this project since I set the date. I have been spending more time working on a machine learning project. It's been fun, but it's not as good for showing to people. One of these days I'll take the project back out again.

Space Date 15-2-29

Artificial Gravity

I really like the concept of artificial gravity caused by constant acceleration of a space craft. If you ignore the question of whether or not a rocket could manage it, it is a really cool idea. Especially when you consider space walks. I imagine an astronaut climbing around the surface of a space ship like it was a building. If they slip, they fall a short distance and are caught suddenly by their safety line which slams them against the side of the ship. If the line fails, the ship witnesses the unlucky space walker plummet into a bottomless pit. The astronaut experiences the sensation of falling briefly, but as soon as the ship is out of reach his perspective changes. He sees himself a floating in silence while his ship speeds away from him. Can the ship rescue him? It depends on lots of things, especially how fast the ship can react. Each second he gets farther away. It's not enough to cut the engines. That stops the acceleration, but the astronaut is still moving away from the ship. The ship needs to accelerate toward the astronaut, close the distance at a safe speed, match speeds when the distance is small enough, and pull the astronaut back into the ship. How much time does that take? How far off course are they? How much fuel did they burn? Can they even make it to their destination anymore? It's entirely possible that such a maneuver could doom the ship. It's not like a car trip where a ten minute pit stop just adds ten minutes. In interplanetary travel, the amount of fuel needed to correct your course increases exponentially the further off course you get. It's entirely possible that the ship lets a single fall victim die in space rather than risk the entire ship and crew. They could be in range for radio contact long after the window for rescue had closed.

Space Date 15-2-23

Cards Aren't Working

It turns out I need to refactor cards. I feel like I spend more time refactoring thing's I've written than writing. At least I'm not debugging.

Cards were designed to be tightly coupled with buttons. When you click a button the card pops up and the button is highlighted. When you click the button again, the card is closed and the button goes back to normal. When you close the card, the button needs to return to normal. This seemed like a straight forward interaction that was going to be pretty common. All buttons had a card and all cards had a button. That seems like a mistake now.

I ran into problems a while ago when I needed buttons that do things other than bring up cards. Some buttons perform a single action, and others put us into build mode. To deal that, I made buttons flexible, they could have cards, or they could have callbacks. By default, buttons toggle when pressed, unless the callback resets them.

Now, I'm trying to create cards that aren't tied to buttons. They pop up when you click on a part of the ship. It doesn't seem reasonable for the ship to be a button.

I need to properly decouple cards and buttons. I'm not sure how I'm going to handle all that. UI is hard.

Space Date 15-2-18

Release Date

To motivate myself and to measure my progress, I have decided on a release date. It's a completely arbitrary date. The game wont be done, but it is supposed to be in a playable state. It'll be something I can tell people about and try to get them to play it. It'll have a dedicated production server so the stable game will always be available. The dev server will still be live, but when I break it I can still point people towards the production server. I'm planning a reduced feature set. There will only be two of the main systems at work, trading and construction. I feel like that will be enough to make it a game instead of an animation. From that point I can start adding some of the other main features I have in mind, like travel and crafting. Also, I will have to start trying to make it fun. The planned release date is 15-2-61. Because of course I'm making plans in space time.

Space Date 15-2-08

To Swizzle or to Unswizzle

The part of my project I have rewritten the most is the serialization. I keep designing a system that is just capable of representing the current features and every time I need to implement a new feature it turns out the system is insufficient. And so, here we go again.

I was using a tree structure, where every object was inside of the object it is related to. It turns out that's insufficient because I'm introducing objects that have relationships to more than one object. For example, a construction job. The job itself is an object. It need to know which structure it's building, which crew member is working on it, and which materials are reserved for it. If I were to use a tree structure, then which of those objects contains the job? The structure, maybe? Alright, then how does the crew member relate to the job? Does the crew member move from a member of the ship to a member of the job when they start the job? That's confusing, but it could work. Can we do the same with the item? It was a member of the crate where it was stored. If being set aside for the job means becoming a member of the job object, then how do we remember that it's inside the crate? Not by simply being in the same square as the crate. I want to allow free floating items to drift around the cabin in zero gravity, so items might float into the same square as a crate.

I think it's clear that a pure tree wouldn't cut it. I considered an impure tree for a while. It would still be a tree, with objects being members of the object they are most related to, and then links to some unique identifiers of the other objects they need a reference to. I'm not going to do that.

I'm going to make a single object store. It's going to be a big long array of objects. Each object's index in the array will be the identifier for that object. Every reference to any object will be its index. A crate's inventory will be a list of indexes where you can find the representation of those items.

Serialization will happen in two steps.

  1. Swizzling. We iterate through every object and give it an index.
  2. Serialization. We iterate through every object and generate its serialization. We use the index of referenced objects that we just calculated.

Similarly, deserialization will happen in two steps.

  1. Deserialization. Create an incomplete object for every entry in the array.
  2. Unswizzling. Complete all the objects by filling in the links they have to other objects.

The biggest change I'll need to make is for the deserialization step. Each object needs to be creatable as a stub with no outside references and then initialized at a later time.

Space Date 15-2-05


First, is it clear that these entries are more of a brainstorming/design journal than a development diary? I bet it's clear by now.

The game need to have items. These are different from other entities in the game in several ways. Most prominently, items don't always have proper locations. Crew and structures always have an integer position on the grid, and items can have that too if they are just set on the ground, but items can also be carried by crew or be inside furniture. So, perhaps they are represented as properties of those entities. Crew can only hold one item at a time, and that item is drawn on top of the crew icon. Furniture, such as crates, have an inventory which can contain a certain number of items. In the raw file, items will be saved to the ship if they are left sitting around, or inside the crew or furniture item if that's where they are.

Space Date 15-2-02

Deliveries and Pick Ups

When the player trades for materials and items, how do they get on and off the ship? I guess the player is actually trading with some sort of orbital warehouse. It probably makes the most sense for the player to dock with the warehouse, but I don't think that's going to happen. It's the most complex to animate, and it doesn't allow the player to make a stationary space station. It's got to be shuttles that come to the player's ship. The most Dwarf Fortress style thing to do would be to make the player build a docking bay which only works if it meets some basic requirements. It will have to be large enough and exposed to outer space, probably with an unobstructed straight path to outer space.

Space Date 15-1-87

Terraforming Venus

There's an idea that if we introduced massive amounts of hydrogen to the atmosphere of Venus, we could reduce the atmospheric pressure, remove greenhouse gasses, reduce the temperature, and create giant, planet-spanning oceans. All in one go. This is because the hydrogen can pull oxygen out of carbon dioxide and form water, letting elemental carbon fall out. On earth, we build ovens to do this, but Venus is already super warm. I imagine ships dropping iron-nickel capsules that both deliver the hydrogen to the surface and act as the catalyst to the reaction. An observer from the surface would see shooting star-like lights which streak through the sky leaving behind black clouds of carbon. It would look cool.

It wouldn't quite make the planet habitable, though. The new atmosphere would have no oxygen, the land would be covered in graphite, and it would still be way too hot. Maybe even hotter than it was before, since the H2 + CO2 reaction is exothermic. If the planet ever did cool down, then the water vapor would eventually rain down, covering 80% of the planet in water. That water would absorb the natural sulfuric acid in the Venusian atmosphere, making a huge ocean of acid.

I think this is the sort of project a civilization that has colonized Mars might undertake. I could have some entity in the game who offers to pay players to deliver hydrogen to Venus. It will take a huge amount of hydrogen, something like 4x1019 kg. Since that's so much more than a single ship could reasonably ever do, this would be an interesting application of my asynchronous multiplayer. I can let all players contribute to the total, and once enough hydrogen has been delivered, Venus can change for all players.

Space Date 15-1-77

User Interface of Cards

What if the user interface revolved around menus that pop up in little windows, more like cards? It's what Banished does. Everything you can click on and interact with brings up a card. The cards can't be resized, but they can be moved around. Cards closed when any click happens outside of them, unless they've been pinned, then you have to click the X. Moving a card pins it. Since they aren't windows, they don't have frames. The title is in the body, so is the X. The border is just there to make the edge stand out.

Space Date 15-1-50

A name for the game

I've been wishing I had a good name for this game for a long time. I've been calling it "my space game" when I talk about it, but never really as a title. I purchased the domain "", so I guess that's my working title, but I'm not really happy with it. It's kind of dumb, and it has nothing to do with what the game's about.

The game is about a space ship. It's not about the captain or the crew or the planets, those things come and go. The camera focuses on the ship, and so does the gameplay. I'd love if I could name my game "Space Ship", but since this is an online game, it needs a good URL, and I can't buy I've been exploring words for space ship in different languages. Here are some of the ones I like:

These are all based on some form of "room ship" (their words for space all have the same root as the English word 'room'). None of those words are actually available, but I could use some amalgamation like romshift, ramskiff, or raumskip. It would be a word that could be 'space ship' in a language that is related to these languages, but isn't actually a word in any real language. It could be made easy for English speakers to spell even if they aren't going to recognize it as meaning anything.

Another option I like a is 'safina'. It's a transliteration of the Arabic word for ship. It's a pretty word. I'd have to use some variant of it, because I am stuck with URLs that are actually available. I could add a silent 't' or 'h' to the end. I could use a 'ph' instead of 'f', I could use a double 'f' or a double 'i'. All of those make it a little less pretty and a little harder to spell. For now, I'm running with Safiina.

Space Date 15-1-31

Is Atmosphere Necessary?

If I want to have a playable game as soon as possible, then maybe atmosphere isn't worth working on right now. I need to have at least one core game play loop as well as enough quality of life features that game play isn't awful. Then it would really be a game instead of a weird animation. I could ask people to play it and give feedback. I should get to that point as quickly as possible, and maybe I can do that with robots running around in a vacuum. The core gameplay features I have in mind are:

Out of these, I can build several game play loops. There's the travel/trade loop and the closely related trade/craft loop. The ship is expanded or reorganized to have mores space for crew, storage, or crafting. Crew has to be kept happy and healthy and able to do tasks around the ship.

So, which things can I cut out of the first prototype? Crew management becomes easier if the crew doesn't need food, air, or entertainment. Travel might also be unnecessary. Every other aspect could be done in a stationary space station. Crafting would be the next to go. That leads me with just trading and building. Building might be fun, but doesn't make much sense without being able to buy new materials.

That leaves me with trading and a simple crew of robots. Robots who only buy things they can't use doesn't sound like very much fun, but the goal at this stage is playable, not fun. I still want to add all the other stuff later.

There are several features that aren't related to the simulation that the prototype must have as well. So far I can think of:

Space Date 15-1-28

The Scarab

¤ is the symbol I'm using to denote currency. The name of the currency is 'marks', but the currency has the same nickname as the symbol: scarab. For example, you might sell a unit of water for 13.4 marks, and the price would pop up as 13.40¤.

Space Date 15-1-26


I may be getting ahead of myself, because there's many things to do before I'm ready implement airlocks, but I've been thinking about them. I need to have them, obviously. I have an idea for how to do it, but I'm not sure it will work.

I would make "airlock door" as a special kind of door. Unlike a regular door, the airlock door needs to equalize the pressure on both sides before it will open. If two or more airlock doors are on the same room, then that room can function as an airlock. Since an airlock doesn't work if both doors are open, airlock doors need to have a mutex with any other airlock doors in the same airlock so only one can be opened or trying to equalize pressure at a time. Of course, there should be a way for the player to override the airlock mutex and open both doors to vent the ship. If that's what they want to do.

I could have airlock doors be linked up automatically, when a new one is built it can discover airlock doors that it shares a new room with. That seems better than making the user link them together. It would be possible for a airlock door to be a member of two separate airlocks. This might not be a useful configuration, but I feel like it needs to work anyway. It would also be possible for there to be regular doors into airlocks. This might cause the airlock to not function properly.

In order to equalize pressure, airlocks doors would need to know which side of the door to match. Preferably, they should change the inside of the airlock to match the outside. For airlocks doors that are part of two airlocks, since both sides of the door are inside an airlock, it would attempt to adjust both sides at the same rate. The size of the airlock would affect the cycle time, since it takes longer to move larger volumes of air. I want to allow for airlocks to conserve air, meaning we don't just vent it to space, we pump the air into tanks, probably recycling it back into the atmosphere maintenance machine. If the airlock is not connected to a working storage system, then it will just vent the higher pressure side into the lower.

There is also the problem of multiple crew members. If two crew members are trying to enter the airlock at once, only one will be successful thanks to the mutex. If one crew member is already inside the airlock, then that crew member needs to get out before any other crew member can get in. The mutex isn't enough in that case. I could end up with many crew members standing in the same square all using the airlock at the same time. I'm reminded of Dwarf Fortress where infinity dwarves can occupy the same square as long as infinity minus one of them are lying down. Every solution to the crew collision problem has problems. It's pretty silly to allow lots of crew to occupy the same square at the same time. If I don't let crew occupy the same square ever, then pathfinding becomes a problem. Dwarf Fortress's solution is awkward, and is not actually less silly than letting crew pass through each other like ghosts. Or a super fluid.

Space Date 15-1-24

Space Time

In what is almost definitely my silliest decision so far, I have a new time system for Space Planets. I call it "Space Time". The system we use in real life is called "Earth Time" in the context of my game.

Space time is a decimal time system, meaning it is completely base ten. Many decimal time systems have been proposed over the years. None have been adopted because people seem to think that changing the time system everyone uses would be stupid. Most decimal time systems keep the size of the day constant and divide the day into 10ths 100th etc. Mine keeps the length of the second the same, since it is an SI unit. From there I derive the length of hours and days. The length of a space day is just under 28 Earth hours, which makes it just 15% longer than an Earth day. That's close enough that I think humans could adapt to it without problems. Days are divided into ten hours, additionally I divide the day up into 4 shifts. Each shift is 2.5 Space hours (about 7 hours). Crew members will generally work a double shift and then have two shifts for personal time (relaxation, hygiene, entertainment, etc.) and sleep.

Seconds Space Time Earth Time
100 s 1 Space Minute 1.66 Earth Minutes
10,000 s 1 Space Hour 2.77 Earth Hours
100,000 s 1 Space Day 27.7 Earth Hours
1,000,000 s 1 Space Week 11.6 Earth Days
10,000,000 s 1 Space Month 116 Earth Days
100,000,000 s 1 Space Year 3.17 Earth Years

Space time is also compatible with the unix epoch. Both start on Jan 1, 1970. If you take the unix timestamp and write it out in decimal, like this: 1512420765, then add dashes, colons, and a space in the right places it turns into 15-1-24 2:07:65. That's the current space time. Drop the hours, minutes, and seconds to get the space date: 15-1-24.


The belters adopted space time as a form of rebellion to emphasize their independence from Earth. It was originally implemented for political reasons rather than practical ones. Paradoxically, many space travelers see it as an apolitical alternative to either Earth time or Mars time.


All this talk of belters and politics makes me think I should watch The Expanse. I still haven't seen it, but I know it has belters.

Space Date 15-1-22

Implementing Construction

Construction is implemented! This is exciting. Now the little constructor bot will move to the site, bob there for a while, and then the structure will turn solid. There is no constructing animation, I imagined some sort of welding sparks, but there is no such thing. There are some weird bugs where new construction jobs are being ignored after some point. I guess fixing that is next.

Space Date 15-1-21


I've been thinking about construction. Specifically about how to represent incomplete structures on the ship. Visually, I could draw planned, but unbuilt structures with some transparency so they look ghostly. That will probably work. Logically, though I'm not sure. I've decided to try giving structures a property that represents how complete they are. Then I will just create the object as soon as it's planned and increase its completeness as it's worked on. I like this better than having a "ghost" version of every structure piece.

Space Date 15-1-19


Today, I learned about the VASIMR engine. It is similar to an ion engine in that it uses electric energy to accelerate a monopropellant. The difference is that the VASIMR engine works much better at larger thrust. It also seems that VASIMR works better with any available gas, while ion engines only work well with heavy elements such as xenon.

I'm still thinking that the play will begin with a chemical rocket, but I'd like to later give them the option to upgrade to a VASIMR engine. The VASIMR could use any liquid or gas as propellant, while chemical engines need an oxidizer and a fuel. (which are modifiers I imagine chemicals will have when I get that far) The VASIMR engine consumes a lot of electrical energy, possibly requiring a nuclear reactor. This might be a way of unlocking continuous thrust transfers which will be faster and will also provide an artificial gravity aboard the spacecraft.