game design by risk analysis

I don’t know if this is a real thing or just a stupid idea, but I was watching some folks talk about giant robot stories (in the context of giant robot games) while also working on a customer risk assessment and I suddenly wondered if we could use one in the context of another?

Currently I work making giant robots safe and secure, so I already know robots in the context of risk analysis works. But what about risk analysis as a tool for game design? So there are lots of methodologies for assessing the risk (and determining how to mitigate it) for systems but one I really like because of its collaborative and practical nature is the French government’s EBIOS 2010 system. We won’t dig into it in detail nor discuss my professional variations on it, but rather look at it from a very high altitude and see if it makes a game. More correctly, if it identifies the parts of a simulation that are fun to model in a game. Maybe we get some new giant robot direction!

So the first step is to identify the assets of the system. Now, this is often naïvely interpreted as the physical objects of value in the system but this is not how this works. The assets of the system are the elements of the system that are critical to its correct and safe operation. They might be things but they might also be functions.

assets

So what kind of assets to giant robots have?

  • integrity of their armour — if the armour is busted, that’s bad
  • safety of the pilot
  • ability to destroy an opponent
  • ability to navigate difficult terrain
  • security from extreme environmental threats (radiation, engineered, disease, poison)
  • ability to function in a wide range of temperatures
  • ability to function in extremes of shock and vibration
  • ability to detect threats (enemies in this context)

I’m sure there are more, but this is a pretty good list to start with. So the next step is to determine just how bad your day gets if these assets are compromised. Since this is subjective we don’t want really fine granularity — let’s just say it’s zero if nothing bad happens, 1 if it’s a pain in the ass, 2 if the system becomes useless, and 3 if the pilot dies.

So integrity of the armour. Let’s call that a 1 because we have pilot safety and basic functions somewhere else. We don’t really care much if the armour is damaged if nothing else happens.

Pilot safety, that’s a 3 obviously. Note that in a real assessment here is where we would argue about the dollar value of a life — is it really more important to keep the pilot alive than anything else? And we might change the severity definitions based on this discussion. Anyway, and so on. Let’s summarize:

  • 1 — integrity of their armour
  • 3 — safety of the pilot
  • 2 — ability to destroy an opponent
  • 1 — ability to navigate difficult terrain
  • 2 — security from extreme environmental threats (radiation, engineered, disease, poison)
  • 2 — ability to function in a wide range of temperatures
  • 2 — ability to function in extremes of shock and vibration
  • 2 — ability to detect threats (enemies in this context)

Next we need to talk about what threatens these assets. What are the threats?

threats

So normally we’d brainstorm these and get lots of ideas and then winnow them down to essential and unique threats. But let’s short circuit that since you can’t respond very quickly to this and I’ll just list a few.

  • enemy weapons damage our weapons
  • enemy weapons damage out mobility subsystems
  • enemy weapons damage our pilot cockpit
  • environmental temperature is very high or very low
  • weapons use creates too much heat
  • weapons malfunction
  • mobility system generates too much heat
  • subsystem breaks down from lack of maintenance
  • enemy weapons damage sensors

I think already we can see a game system come together though I’m not blind to the fact that I am thinking about game systems as I generate this list. It’s a bit of a cheat so I’m not sure it proves much. Maybe if I started with a topic I don’t know well?

Anyway the next step is to decide how likely each threat is. Let’s say 0 is amazingly unlikely. 1 is unlikely, 2 is common, and 3 will happen pretty much every time you get into a fight. Let’s quickly go through that:

  • 2 — enemy weapons damage our weapons
  • 2 — enemy weapons damage out mobility subsystems
  • 1 — enemy weapons damage our pilot cockpit (because it’s small compare to everything else!)
  • 1 — environmental temperature is very high or very low
  • 3 — weapons use creates too much heat
  • 1 — weapons malfunction
  • 2 — mobility system generates too much heat
  • 2 — subsystem breaks down from lack of maintenance
  • 2 — enemy weapons damage sensors

risk matrix

Now we just multiply these to find out how much we care about each scenario. If a threat doesn’t impact any asset we don’t care. So for example, let’s look at “enemy weapons damage our weapons”. That seems to affect only our ability to damage opponents, which has an asset value of 2. So the risk for this threat is 2 x 2 = 4. We’d normally make a risk appetite grid to say just how bad a 4 is. Something like:

Severity ->
Likelihood0123
0who careswho careswho caresmaybe bad
1who caresmaybe badworryingbad
2who caresworryingbadvery upsetting
3maybe badbadvery upsettingunacceptable

So a 2 x 2 is BAD.

Let’s look at something with multiple asset impact. Enemy weapons damage our pilot cockpit. Now clearly this affects our pilot safety, our mobility, frankly almost all of our assets. So we pick the most severe one: pilot safety. So that’s a 1 x 3 — BAD.

As we go through this we start thinking about mitigations. For each scenario that’s, let’s say, worrying or worse are there mitigations we can put in place that reduce either the severity or the likelihood of the event? So, for example, we could add armour to the cockpit and maybe reduce severity by one step. That’d be nice. But we need to also consider the ramification (cost) of the mitigations.

Because I want to talk about it in the next step let’s also look at weapons use creates too much heat (3). We will now have to invent the impact of heat on the robot and now we’re also designing a game — we’re imagining features of this robot and its world context. So let’s say we think that a hot robot is an unhappy robot. That most subsystems degrade. Certainly the weapon but also mobility and maybe pilot safety ultimately. So that happens with a likelihood of 3 and pilot safety is the biggest deal of all the impacts. 3 x 3 is unacceptable.

mitigations

So a mitigation is a recommended change to the system that reduces the risk level of a given threat scenario. And this is where we start getting a game I think because when assessing a mitigation we have to consider its cost and that’s where we start to get at least robot construction rules.

We have an unacceptable scenario up there — weapons overheating can kill the pilot. That would be bad. It can also do lots of other things, so even if we solve the pilot problem we still could wind up with a 3 x 2 that’s very upsetting. So we’d really like to bring down the likelihood of a weapon overheating. We could:

  • prefer weapons that do not generate much heat (like rockets, say)
  • add heat dissipation equipment to weapons (sinks, heat pipes)
  • add heat dissipation equipment to the whole system
  • … and so on

Now from a game design perspective what’s interesting here is not how we make a giant war robot safer, but the detail that we are adding to the system. Now we know we want to track heat, maybe by component. We know that some weapons generate more or less heat. We have a new subsystem (heat sinks) that could also be damaged and create cascading trouble.

discussion

What this seems to do is to give us a big pool of credible detail — elements of a fictional universe that have some justification for existing. Ultimately a good (or more often bad) risk analysis is what drives pretty much everything in the real world: nothing is perfect and so we need to decide how much imperfection we can tolerate. A lot if not all complexity comes out of this thought process, and trade-offs like that are also a Good Trick in game design: they create diversity in approaches to playing the game well.

afv

I had the urge to do several things.

  • Buy some tiny tanks and paint them.
  • Play a tabletop wargame with tiny tanks.
  • Use a new font.

So obviously I wrote a tiny game for myself. This hasn’t been tested yet but please feel free. It’s essentially a very pared down version of Striker. I intend to play some of this tonight so expect more revisions. When it’s golden brown and a skewer comes out clean I’ll post it on itch. In the meantime, help yourself and see if it goes boom.

Sequence

Player A

Movement

  • If you have a stopped marker, remove it and go to Fire.
  • If you have a ready marker, remove it.
  • If you have a suppression marker, you may move full speed directly away from the enemy and remove it. Otherwise move up to your maximum movement rate and change facing to your direction of travel.
  • If you move zero, place a ready marker.
  • If you move half or less, place your direction marker perpendicular to your new facing.
  • If you move half or more place your direction marker in the direction of your facing.

Fire

  • You can shoot at anything in line of sight. If a recon unit has spotted an enemy out of LoS but in direct fire (no hills between you, just trees or other concealment) you may shoot at it.
  • If you have a suppression marker, you may fire at the nearest enemy revealing yourself to all opponents and remove the suppression marker.
  • You may fire once for each weapon system on your unit.

Player B

Same thing, clearly.

Units

Infantry

Infantry and their jeep.

Standard infantry

  • Move: 10cm (5mph)
  • Special: Only affected by anti-personnel attacks
  • Special: When in line of sight only spotted 50% of the time (1-3 on d6)
  • 3 hit, 0 pen, 15cm short range

Heavy weapons team

  • Move: 8cm
  • Special: Only affected by anti-personnel attacks
  • Special: When in line of sight only spotted 50% of the time (1-3 on d6)
  • 3 hit, 1 pen, 20cm

AT team

  • Move: 8cm
  • Special: Only affected by anti-personnel attacks
  • Special: When in line of sight only spotted 50% of the time (1-3 on d6)
  • 0 hit, 6 pen, 20cm 

Degraded infantry

  • Move: 10cm
  • Special: Only affected by anti-personnel attacks
  • Special: When in line of sight only spotted 50% of the time (1-3 on d6)
  • 0 hit, 0 pen, 10cm

Recon

Utility vehicle

  • Move: 80cm, 20cm rough terrain or mud
  • Armour: 1
  • Special: anything they spot everyone spots
  • Special: can carry 1 infantry team
  • 3 hit, 1 pen, 20cm

Light armour

Fast Cannon carrier

A tank.
  • Move: 60cm
  • Armour: 3
  • 0 hit, 9 pen, 40cm

ATGM carrier

  • Move: 60cm
  • Special: can only fire on a turn that has AND starts with a stop marker
  • Armour: 3
  • 0 hit, 12 pen, 30cm

Fighting Infantry Vehicle

  • Move: 60cm
  • Special: can carry 2 teams of infantry
  • Armour: 3
  • 3 hit, 3 pen, 30cm

Medium armour

Standard AFV

  • Move: 40cm
  • Armour 6
  • 0 hit, 9 pen, 40cm
  • 3 hit, 1 pen, 20cm

Tank destroyer

  • Move: 40cm
  • Armour 3
  • 0 hit, 12 pen, 50cm

Heavy armour

  • Move: 20cm, 10cm on soft terrain
  • Armour: 9
  • 0 hit, 9 pen, 40cm
  • 3 hit, 1 pen, 20cm

Move

You may move your movement rate each turn. After moving, place a direction marker to indicate your direction of travel. If you did not move, place a READY marker instead. You may choose to move evasively — if so, move ½ your full rate but place you direction marker perpendicular to your actual path of movement (you zig-zagged).

Shoot

Roll 2d6 + hit for each weapon. Each weapon may engage a single target. Hit on 8+, 11+, 14+, 17+, &c.

Is there line of sight? No? Forget it then.

Did you move and you’re not infantry? -2

Did they move laterally (>45 degrees from straight towards you)? -3 if they are light or recon, -2 if they are medium, -1 if they are heavy or infantry.

Are they infantry in cover? -2

Are they in your short range? +0

Are they in your long range? -2 (5x short)

Are they in your distant range? -4 (10xshort)

For each hit, subtract pen from armour and roll 2d6

2d6 Result human Result vehicle

2: nothing nothing

3-5: stopped (no move next) superficial

6-8: suppressed external component destroyed (lights, antenna)

9-11: degraded, suppressed degraded move ½ or shoot -2

12-14: destroyed stopped or no weapon

15+ destroyed destroyed

Stopped infantry get a STOPPED marker.

Suppressed infantry get a SUPPRESSED marker

Degraded infantry get a SUPPRESSED marker and act as the DEGRADED INFANTRY unit type.

picks and locks

I am always looking for a new skill to learn. It’s usually something technical, something work related, but the levels of anxiety in today’s world demand something more meditative. I’ve watched a lot of YouTube finding strange solace in my mechanics restoration videos. But I’m not building a machine shop any time soon.

Then I stumbled on LockPickingLawyer. He picks locks. Easy locks, hard locks, ancient locks, techno locks. And he blows through them with amazing ease. And then, most of the time, he guts them and shows off their innards. Now, mechanical bits like this have always interested me — how does the interplay between tiny components make a lock lock? Or more interestingly, unlock? So I decided to try my hand at picking locks.

There’s a great Canadian company called Sparrows that has a bunch of material for locksmiths and amateur pickers alike. And it’s not very pricey, really. That’s a pretty good criterion for a new passtime that may or may not last. So I got some stuff.

I got a couple of cutaway practice locks. Part of what’s difficult (and fun) about picking a lock is that you can’t see what’s going on. You can only hear and feel it. When you’re starting out that’s a hell of a hurdle to get over but a cutaway lock lets you see the pin positions and correlate that with what you’re feeling. I got two — one with normal pins and one with serrated pins. Serrated pins are a kind of “security pin” — the serration will generate what’s called a “false set”. That is, it will feel like the pin is clicked into position to unlock the lock when actually it’s just been trapped by one of the serrations. It feels subtly different than a real set but you need to experience it. A couple hundred times.

So those are fun. Heavy, small, brassy. Industrial feeling. It’s ticking my boxes. Then I got a pick set, just an assortment of basic picks and levers. Now I have enough to try picking.

Well I opened the practice locks pretty fast. Being able to see in the window is a pretty big advantage but the early victory is a great moral booster. So I grabbed a real padlock I had handy, a little 4-pin Master brand padlock. No window to look in, you just gotta feel and listen. But only 4 pins so it’s not a long reach or a weird angle. Should be easy, right?

Turns out it kind of is. Ten minutes for the first pick and I literally shouted out loud for joy. Giant rush from that. Was it a fluke? Five minutes on a second pick. Under two minutes now. The lock went from a giant looking obstacle to far too easy in an evening. I should note that these are the locks I used on my airgun cases until just now.

Yeah an evening. You don’t need to see what you’re doing, so this is something you can fidget with while watching TV, listening to an audio book, whatever. It’s almost meditative as a puzzle but the buzz you get at the solution is huge. Part of it’s puzzle and part of it is the physical feedback: the pop, the sudden release of the lock tension, the shift as the shackle opens. These are all rewards.

Take those where you can get them folks.

…in space!

Usagi_02I remember my wife bought me a copy of Space Usagi in the distant past and I was very excited — after all, I love science fiction and I love Usagi Yojimbo! And I read it and I was bitterly disappointed.

You see, what they did was just paint the science fiction on. They had ray guns and fought aliens on alien planets, but the tropes were largely the same as the non-sf version and the imagery was the same but with space-bits glued on. Japanese fortresses hovered in space. Space armour looks remarkably like samurai armour. They have laser katanas.

This felt like, well I want to say “betrayal” but that’s pretty harsh, but I did feel betrayed. We have a masterful storyteller and artist and it feels like they just didn’t put the work in to really adopt an alternate genre. They just painted the old one a new colour. There is no attention to how technology changes things. There’s no effort to understand the differences between Edo era Japan and some distant future. And so the stories are completely transplantable: there is nothing new or exciting here other than amusing new space art.

This lack of intentionality happened a lot in early popularized science fiction as well — surely we all recall mentions of technologies like “space pills” and “space wrenches”. This just lacks effort and it’s kind of insulting.

So anyway, what I never ever want is for my science fiction gaming to be that. When I choose science fiction for play I am not choosing it because I want space ships and lasers. I am choosing it because I want to explore a world impacted by the fact of space ships and lasers. It’s not enough to say you can easily change your physical body, growing a penis or a vagina at will. You have to address how this makes the place different from where we are now. And, at least as importantly, how it’s the same. Or at least how it’s relatable, how it’s an extension of where we are now. An important question I want to ask is “how did we get from here to there?”. And what were the costs?

This is why the cluster generation system of Diaspora (and the upcoming Diaspora Anabasis) is what it is: we create random solar systems with various technologies, resources, and environments and we ask at least these questions of you: what does this society look like given its attributes? How did it come to this? How does this affect its relationship with its neighbours?

My thinking was that if you start with making sense of these things — and likely making sense of apparent impossibilities like very low technology and very low environments — then your stories would necessarily start in a place that is not just a paint job over a place you know already. It might wind up caricatured that way (we all get a little lazy) but it doesn’t start that way and you are not invited to imagine it this way. You have all the cues you need to wonder about how technology affects a world (and not our world) and how it creates power imbalances and how those gradients affect every other system.

And I think this is the heart of the paint job problem: when the setting begins as something totally familiar but with lasers, there is nothing to grab on to and wonder about. If you’re even slightly lazy then you are stuck at the bottom of a false minimum, a place that’s easy to get to but not nearly the best you can do.

Thermodynamic_stability_EN.svgAnd since — oh! shiny! — we’re on to false minima…. A false minimum is a low spot on a curve that is not the lowest spot but is surrounded by increasing values, so if you are using a simplistic algorithm to try and find the minimum point on the graph, you can get stuck there. Sometimes they are stable (there is no easy way out) and sometimes they are unstable (a minimal effort would need to be put in to find a lower minimum. So you have points that are “metastable” (in thermodynamics, anyway) which are false minima — you need a lot of energy applied in a direction you don’t want in order to get free. You have points that are unstable (curvature around them slopes flat or down) and require only a small amount of energy to go one way or another. And you have stable points where there is no lower to go no matter how much energy you spend.

We think of low as bad but low here is good.

The reason this gave me an oh shiny moment is because it might be the case that our universe is in a metastable vacuum state — that is, the vacuum of space might be at a very low energy state but not at the lowest possible energy state. We call this a false vacuum because the real one is at the lowest energy state. If this is the case, that we are in a metastable universe, then it is possible for changes in local energy to push us out of that trough to plummet down to a lower energy state — possibly a stable one but also possibly just another false minimum. If this happens then we get “bubble nucleation” and the laws of physics may change (a little or a lot) in a bubble that expands from that point at the speed of light. And at the speed of light means there’s nothing you can do about it — you will literally only know about it when it happens to you.

The effects of a shift from a low vacuum energy to an even lower vacuum energy are speculated to vary between unnoticeable (which may have happened before) to survivable (which also may have happened before) to catastrophic. A bubble nucleation could end not only life, but the very form matter takes.

Now that’s exciting!

questions about the ∆v diagram and aerobraking

I also had some excellent questions about this diagram:

Delta-Vs_for_inner_Solar_System

Specifically, the places where aerobraking can occur to assist (decrease the ∆v cost). The first thing we need to understand is what these places even are.

Well, they aren’t all places, per se, and that’s where it gets confusing. They are orbits. GEO, for example, is a “geostationary orbit” meaning it’s an orbit at an altitude such that you are moving around the Earth at the same rate the Earth spins, meaning you hold your position apparently stationary over one place on the planet. Sri Lanka is fine; that’s where Arthur C. Clarke put his space elevator in Fountains of Paradise. Since there’s no air there and there’s no air on any direct path to its links (GTO, L4/5, and LEO) there’s no opportunity for aerobraking.

You would guess from this diagram that GTO is further away than GEO. But that’s an artifact of the diagram which is not showing distances at all. GTO is a “geostationary transfer orbit” which means it’s an elliptical orbit with one end in a potentially geostationary position. The other end will be much closer to the Earth:

aero1
Approaching the GTO orbit from C3=0 and using aerobraking to reduce the cost of that burn.

So we can see that if you were entering GTO from somewhere else (say, C3=0 which we’ll explain later), you could enter at the shallow end of the orbit and use the atmosphere to slow down enough to complete the burn for the orbit and wind up in GTO.

C3=0 is the escape orbit of the planet (Mars or Earth in this diagram). This is the velocity at which you are no longer orbiting the planet but rather are now orbiting the sun while in the rough vicinity of the planet (or not, but that’s where the transfers take place).

aero2
The blue dot is Earth. The little spaceship is your little space ship. It is no longer orbiting the Earth–its orbital velocity is past Earth’s escape velocity but less than the Sun’s. This is C3=0.

So if you wanted to burn into a GTO around Earth you need to slow down. Nothing’s stopping you from doing that so your vector passes through the atmosphere, using that friction to make the burn cheaper. However, going from GTO to C3=0 needs more velocity not less, so aerobraking is no help and that’s why the arrow only goes in one direction on the chart. It’s only useful to go through atmosphere when you’re slowing down.

Similarly, in “deep space” at your Mars transfer orbit you want to enter the C3=0 of Mars. While there’s no air there, you can plot your path such that you pass through some air on the way. Why would you want to though? If you have an elliptical transfer orbit you probably want to speed up to reach C3=0. I am guessing that they mean that you could be on a longer elliptical orbit for transfer such as:

aeri3
Earth is blue, Mars is red, and you are clearly in way too much of a hurry to match up with Mars’ orbit so you are going to plan a path way past it and brake in the atmosphere as you pass.

 

In this case you want to slow down or possibly change direction and it seems like there’s an opportunity to use Mars to do it. I’m not sure I see exactly how that would help, but you certainly can pass through Mars atmosphere from a transfer orbit. I’m just not sure why.

Although the atmosphere at Mars is much much thinner, at high speeds and with a high cross section, it will still slow you down a bunch. The Odyssey mission, for example, used aerobraking to slow down. They burned from capture orbit (the orbit at which they just start to move slower than the escape velocity of Mars and so are now orbiting Mars instead of just the sun) to what they called an “aerobraking orbit” which was designed so that every time the craft passed through the short side of the orbit the vessel would slow down, slowly circularizing the orbit until it was suitable for the mapping work.

Over at the moon there’s no atmosphere at any of the adjacent nodes to lunar orbit so there’s no aerobraking. At the moon you have to do all the work. It’s also pretty cheap to land and take off from though!

Thanks to Pierre Savoie for the questions that spawned this

questions about the ∆v science

20190602_010436

I got some excellent questions on the last few articles and the answers deserve some space, so here’s that space.

I’m about to reveal how clueless I am about these topics, but these are making me reflect on recent sifi fiction. Could weapon recoil provide ∆v significant enough to be strategic (assuming weapons use power that doesn’t steal from thrust capacity)?

This will become clearer in a later answer but the short version is: probably not. Ships are going to be very hard to move due to their mass. Additionally, you probably don’t want a weapon that costs you ∆v unless you point it in exactly the right direction: the odds of that being both the direction of your target and opposite your desired vector change is mighty small.

Could you use weapons as thrust in an emergency? You could probably use some weapons to rotate the vessel rather than apply ∆v. Rotating your ship is comparatively cheap! In fact any weapon with recoil probably has a compensating jet to avoid this. I believe this is the case with the Rocinante in The Expanse! From the entry on PDCs in the fandom wiki:

They also utilize thrusters on their rear to counteract the recoil of the firing cannon, that would otherwise knock the ship off course.

To be clear, though, it probably wouldn’t affect the ship’s course, but it would rotate the ship. And I suppose if you’re burning the drive while firing that would indeed knock you off course.

Or nearby detonations (does space conduct shockwaves)? It’s intriguing to weigh the ∆v cost of any sort of space confrontation or skirmish.

Since there’s no atmosphere in space (by definition) there’s nothing intrinsic to transmit a shock wave. There will be some shock from the expanding plasma of the explosion of course, but we normally call that “damage”! And maybe a little photon push as well. Nothing that you would want to use as thrust.

However! If the explosion is energetic and close enough (and ideally shaped for the task), you can indeed propel your space ship with nuclear bombs. This would be a very poor ad hoc solution to a problem, but not an infeasible design. Obviously there are significant drawbacks to the design.

How does starship mass impact ∆v strategy? I’m probably wrong but I’m assuming greater mass requires greater thrust to achieve the same vector, and more thrust requires more fuel or efficiency, which all rolls into a single measure of total ∆v capacity.

rocketChartThumb
I’ve only put the thumbnail here because it’s massively detailed and you should go to Winchell’s site to read about it and download the whole thing.

You are absolutely correct! For any given drive capability you can calculate the ∆v of the whole system by estimating the proportion of reaction mass (the mass you store only so you can shoot it energetically out the back) to the payload mass (the mass you have to keep). This is because of the “rocket equation” which I’m not going to go into, but Winchell Chung has an awesome chart showing ∆v for any given hypothetical drive type and any given mass ratio! It’s the basis of the game design that’s emerging here.

So yes, one of the joys of using ∆v as the core resource is that it encapsulates all kinds of information about the ship.

But would reducing your mass increase ∆v capacity through fuel efficiency?

IMG_0711
The Marie Therese before ejecting the spin-grav luxury cabins and swimming pool.

Essentially yes! Let’s say you were the players in my last Diaspora campaign and were escaping in a luxury liner with a huge rotating spin-gravity living space. And you’re being chased. Ejecting that useless mass (which was huge) would change your r-mass:p-mass ration substantially, and give you a ton of spare ∆v.

Mass also impacts gravitational vectors, right?

Nope. The force you experience is dependent on your mass, but the acceleration you experience is not — it’s pretty much 9.8 m/s² for everything on Earth (but an elephant gets a lot more harm falling from a height than a mouse does — that’s the force). But not everywhere, and certainly not at different altitudes. But that’s way more detail than we need.

Does anything in space provide opportunity for aerobraking other than atmospheres?

Atmosphere is all I can thing of. Most interstellar gas clouds are way too tenuous to be interesting at this scale. Doesn’t mean you can’t invent one though!

Renewable sources of ∆v reserves look increasingly important (e.g. rechargeable solar vs consumable fuel?).

Well, basically your ∆v is going to be based on how much and how fast you can throw something out the back. So renewable is pretty tough unless you have a way to convert energy into mass. At least for rockets anyway. Remember for a rocket we’re not talking about power (although you might need some power to run the rocket, and that power supply will have its own energy needs which might include solar) but rather reaction mass.

Many thanks to Adam Minnie for the questions!

ray tracing

When I was just a scamp in my 20s I used to ray trace high resolution (320×200) 24-bit colour depth images on my 286. Don’t panic, I had a 8087 math coprocessor in there so it went super fast. A day or two per image.

Now you might very reasonably wonder what renderer you could get in those dark days in the 80s. What sort of interface would you have available? Surely Blender wasn’t around yet, right? AutoCAD 3D maybe?

In those days we cranked out images with POVRay.

POVRay is what is known as a “constructive solid geometry modeller”. Whereas these days (and even a lot of those days) we render meshes of triangles and use a surface normal function to fake the reflection of light rays into curves (yes, a modern rendered sphere is actually a mult-faceted gem and the renderer lies to you about its smoothness), a constructive solid geometry (CSG from now on) modeller uses primitives like spheres, cones, cylinders, boxes, and toruses that are described by their analog functions. So no impure faceted surfaces (unless you want them). Your light ray returns are pure. You are not being lied to.

The difference to the eye of course is uninteresting. But there’s a lot of joy in purity for some nerds, like me. Hell when gaming I don’t even like the d10 because it’s not a Platonic solid.

But what can you do with such appropriately named “primitives”?

Just about anything, as it turns out (though partially because one of your primitives is a bicubic patch but that’s for another time). The reason you can do plenty is because of the “constructive” part. If you know set theory you probably know what’s coming. Because in addition to placing cubes all over the place, you can perform constructive operations on them.

So, for example, you can take the intersection of two objects — what’s left and therefore rendered is the volume that exists only in both shapes. Or the difference: take a sphere and cut chunks out of it with boxes and cylinders. Or the union of course, just gluing them together. With these functions you can do an enormous amount of work before you even get to the tricks of texturing and colouring and finishing. Here’s what I’m working on right now with what is really the same POVRay I used in 1988.

asymptote small
That Jupiter image is a JPL image enhanced by the amazing Sèan Doran. I licensed it from him for use in Diaspora Anabasis a while ago and it sits nicely here. The ship is from our current Diaspora game — that’s the Cinderella.

That’s still a work in progress, as I say, but largely complete. Just needs some work on lighting and colouring.

But what, you ask, does the interface look like? Is it at least better than Blender?

Well hell yes it is. While there are third party interfaces that glue on to POVRay (which is super easy as you’ll see in a sec), the input into POVRay is a descriptive language. Like my other love, PostScript, POVRay uses a scene description language: you just type your description of the scene into a text file and then drive the renderer over it. Your image falls out the bottom.

That “just” is a little flippant. Here’s the code for the crew module of that ship:

#declare cabin_xlate = -25;


	  merge {
	  	
	     difference {
	       sphere { <0, 0, 0>, 2 scale <2,1,1> translate <cabin_xlate,0,0> }
	       cylinder { <-28,1,1>, <-24,1,1>, 0.3 }
	       cylinder { <-28,-1,1>, <-24,-1,1>, 0.3 }
	       cylinder { <-28,1,-1>, <-24,1,-1>, 0.3 }
	       cylinder { <-28,-1,-1>, <-24,-1,-1>, 0.3 }
	       
	       box { <-23,10,10> <-23.1,-10,-10> }
	       box { <-25,10,10> <-25.2,-10,-10> }
	       box { <-28.5,10,10> <-28.6,-10,-10> }
	     }
	
		difference {
			sphere { <0, 0, 0>, 1.95 scale <2,1,1> translate <cabin_xlate,0,0> }
			cylinder { <-28,1,1>, <-21,1,1>, 0.3 }
	       	cylinder { <-28,-1,1>, <-21,-1,1>, 0.3 }
	       	cylinder { <-28,1,-1>, <-21,1,-1>, 0.3 }
	       	cylinder { <-28,-1,-1>, <-21,-1,-1>, 0.3 }
	       
			texture {
				pigment { Black }
			}
		}
	
		object { plate translate <cabin_xlate,0,0>}
		object { plate rotate <90,0,0> translate <cabin_xlate,0,0>}
		object { ring translate <cabin_xlate,0,0>}
		
	     cylinder { <-25,0,0>, <-24.8,0,0> 2 }
	     cylinder { <-24,0,0>, <-23.8,0,0> 2 }
	     #declare store_texture = texture {
	     			normal { ripples 1 scale 0.2 }
				pigment { color rgb <0.2,0.15,0.1> }
	     			finish {
	     				ambient 0
	     				diffuse 0.2
	     			}
	     		}
	     	#declare fasten_texture = texture {
	     		 pigment { color rgb <.2,.2,.2> } 
	     		 finish {
	     		 	specular 0.8 roughness 0.001
	     		 	reflection { 0.4 metallic }
	     		 }
	     	}	
	     	merge {
	     		sphere { <-20, 0, 1>, 1 texture {store_texture} }
	     		torus { 1, 0.1 translate <-20,0,1> texture {fasten_texture } }
	     		torus { 1, 0.1 translate <-20,0,1> rotate <90,0,0> texture {fasten_texture } }
	     		}
				merge {
	     		sphere { <-20, 0, -1>, 1 texture {store_texture} }
	     		torus { 1, 0.1 translate <-20,0,-1> texture {fasten_texture } }
	     		torus { 1, 0.1 translate <-20,0,-1> rotate <90,0,0> texture {fasten_texture } }
	     		}

				merge {
	     		sphere { <-20, 1, 0>, 1 texture {store_texture} }
	     		torus { 1, 0.1 translate <-20,1,0> texture {fasten_texture}}
	     		torus { 1, 0.1 translate <-20,1,0> rotate <90,0,0> texture {fasten_texture}}
	     		}

				merge {
	     		sphere { <-20, -1, 0>, 1 texture {store_texture} }
	     		torus { 1, 0.1 translate <-20,-1,0> texture {fasten_texture}}
	     		torus { 1, 0.1 translate <-20,-1,0> rotate <90,0,0> texture {fasten_texture}}
	     		}
	
	     	merge {
	        cone { <0,0,0> 0.2 <-40,0,0> 0.001 rotate -45*z rotate 90*x translate <-25,0,0> }
	        cone { <0,0,0> 0.2 <-40,0,0> 0.001 rotate -45*z rotate 180*x translate <-25,0,0> }
	        cone { <0,0,0> 0.2 <-40,0,0> 0.001 rotate -45*z rotate 270*x translate <-25,0,0> }
	        cone { <0,0,0> 0.2 <-40,0,0> 0.001 rotate -45*z rotate 0*x translate <-25,0,0> } 
	
	        texture {
	           pigment { color rgb 0 }
	           finish {
	              ambient 0
	              diffuse 0.2
	              specular 0.9  roughness 0.0001
	              reflection { 0.6 }
	           }
	        }
	     }
	
	     texture {
	        pigment { body_pigment }
	        finish{
	           ambient 0.0
	           diffuse 0.3
	           specular 0.9 roughness 0.001
	           reflection { metallic 0.4 fresnel 1 }
	        }
	     }
	     
	    translate <-4,0,0>
	  }

Yeah okay that makes my “just” seem like a bit of an over-reach. But besides the nerdy joy I experience writing any kind of code, I adore the precision of this: things go exactly where you want them because you tell the machine exactly where it goes. No nudging of objects in the modeller’s mesh preview. No snapping to grids. Everything goes exactly where you say you want it. It gives me a rush every time.

Now I don’t expect anyone else to get off on this, but consider: this renderer I’m running is essentially the same today as it was 34 years ago. A few little features go in as processing improves (though it hasn’t been updated in some time now) but the renderer is basically complete. I can render a file (if I had a floppy disk drive) from 1989 without change. That’s like getting a WordPerfect file to load (and I was TODAY years old when I learned that WordPerfect actually still exists so bad analogy, Brad).

Anyway, I’m not trying to sell you on this dinosaur but rather explain the little joys I get from using it. The naked code, the purity of concept, the precision, and, of course, the nostalgia.

asymptote
Here she is at 320×240 by the way. Some things do get better.