LIAM JOHN DAVISON

Modeling the Solar System

Liam Davison
link herschel games space

I've never wanted to be a computer games programmer. It's always struck me as requiring a lot of mathematics, an artistic bent, and an awful lot of spare time. Nonetheless, for the past couple of months, I've been experimenting with a game idea I am calling Project Herschel. It was born from a flash of inspiration while walking one day, pondering something which has often annoyed me with the computer games I like to play.

I like to play strategy games, such as Civilization. Big, expansive, turned-based 4X games which start small and build to empires. Key to all of these games is a technology tree - in Civilization's case, a progression from pottery to the wheel to the trebuchet to the computer and beyond. Researching a technology unlocks new game units, structures and rules. It all makes sense.

Except... it doesn't, really. Did early man sit down and say, "this pottery is great, so next let's work on the wheel"? I struggle with the idea of choosing the next technology to research as if there was a clear roadmap for civilization. The clock transformed western society; when it first arrived in China is was considered a curiousity, not a revelation. Technologies have been lost to us, such as Greek fire. The ancient Greeks even had a precursor steam engine, the Aeolipile. How different history could have been if the Greeks had the material science and precision engineering required to put this toy to productive work? Steampunk is a genre of science or fantasy fiction which imagines, for instance, a Victorian England transformed by steam-powered flying machines and analogue computing machines inspired by Babbage's analytical engine; it may be a fantasy, but not such an unlikely one.

So I have wanted to explore a game idea where the player cannot choose what technology to research, and that each play through will be different because the tech tree is different each time. Not radically so, but enough to give a different flavour to each run. Rather than a single 'science' rate, I will split it up into biology, chemistry, physics, engineering and psychology. Different technologies will require a different combination of these sciences, and perhaps each game will have this balance randomised to some extent.

I'm a science fiction fan, so setting a game in space is an obvious choice. It also allows me that freedom to play around with science and technology. Consider suspended animation, that necessary staple of long-term space travel. Is suspended animation a matter of biology - can we tweak genes to make it easier for man to "hiberate"? Is it chemistry, some drug which will slow the body? Perhaps it's pure physics, a way to create a localised bubble of space-time which runs at a slower speed? I don't know, and that gives me the freedom to make it up - and to make it different each time.

Now, I've never written a computer game before, so there's no chance I'll be creating massive, galactic-scale 4X game like Stellaris or Master of Orion. I'd better scale my ambitions down. Why not just the solar system? One of the best sci-fi TV shows recently is The Expanse which is set, primarily, in "just" our solar system, and that allows for rich stories and grand ambitions. Why not for a game too?

So, I need to model the solar system.

Starting from Scratch

I've never written a game before. There are multiple game development platforms out there - Unity, Godot, Unreal Engine - massive frameworks which would take years to master. They would also mean learning a new programming language, and I wanted to stick with what I know best, Java and Kotlin. So I've been exploring a Java framework called libgdx, and a handy Kotlin wrapper for it called libktx. It's pretty low-level stuff, no pretty point-and-click UI, but I thought it would be a good way to learn the principles of game development if I didn't have a big framework doing a lot of the work for me.

So, step one - draw the solar system on the screen.

No, step one - draw something on the screen. Then draw something round, and planet shaped. Animate it in some way, to make it spin. Now, draw several planets - and try to scale them, and space them out, in some way that looks vaguely correct. I came up with this:

Some circles on a space-y background

Drawing to Scale

So now that I had some 'planets', could I draw the actual planets? All nine of them. Yes, I know that there are only eight planets, and a bunch of dwarves, but I did want that iconic image of the solar system, from Mercury to Pluto. I knew that drawing the solar system to scale would be a thankless task, but I wanted to try at first, just to see. So I did some research and plugged in some numbers. In game development terms, my 'world units' might has well have been AUs - Astronomical Units, the average distance from the Sun to the Earth. I didn't get the planet size scaling correct, somehow; Jupiter is huge, so I clamped it and the other giants down to something more manageable. I added zooming and scrolling so that I could navigate from planet to planet.

It looks pretty good, with animated textures for each planet rendered in Blender. Performance was poor (I think my textures were far too big), and there were some flaws in my modelling. There's no asteroid belt, Saturn is missing its rings, and there are no moons at all. Or a sun. In the image below, look at where the planets have been lit from... ca All nine planets Nine little planets, all in row An almost-accurate solar system Nine planets, some giant, accurately spaced

And then everything stalled. I have my solar system - what does the player do on turn one? Are they on Earth, on the moon, on a space ship? What's the first action the player would take? How am I going to populate this vast solar system with space stations and asteroid mining stations and orbital tethers, and how might they be represented. Project Herschel needed a rethink.

The Hexagonal Grid

Most 4X games have a fixed grid, usually squares or hexes. Perhaps that's what I need. I found a Kotlin library called Mixite which allows me to generate an arbitrary hexagonal grid, and I plugged it in to libgdx. Looked good. I even found and reported a bug in Mixite, which has since been fixed - the developers were very responsive and helpful on Discord.

hex grid

From there, I did a bit of thinking. If the Sun is in the center hex, then I'd need a radius with a minimum of 10 hexes, and if I wanted any sense of scale, and to include the asteroid and Kuiper belts, I would need many more than that. Just from my sketches I could see that this grid, and hence the game, would be mostly empty. 95% empty. I toyed with turning it into an orrery of sorts, and have the planets orbit the sun. That woud add to the realism, and the sense of scale, but it wouldn't add much to the gameplay and would introduce its own challenges.

My current thinking is to create a rectangular grid of hexes, with the planets all neatly lined up. I might introduce sub-grids around each planet, spaces to build orbital facilities like space stations or giant telescopes. But even then - if there are six hexes around Earth, does it make sense for there to be only six hexes around Jupiter?

And from all these deliberations, I can see why most space 4X games don't attempt any sort of realism or scale when drawing solar systems. In Master of Orion 2, solar systems only had two or three planets. In Endless Space 2 and Stellaris, there are maybe four or five. And none are drawn to scale. I haven't found any games set in our solar system - and a friend suggested that that's because it's mostly a boring place to be!

I'm not giving up yet, but this needs further thought.

New Blogging Layout Options for Bascule

Liam Davison

Static-site generators like bascule are essentially blogging platforms. There's a home page, maybe a couple of other pages, and then an ever-growing list of blog items. Blogs have a title, a date, and pretty much all look alike. They are all driven by the same template - in bascule's case, that template is called post and it has an associated Handlebars template called post.hb. That's hard-coded into the system.

That's working fine, but it's not very flexible. You can create as many templates as you like in bascule, but only ones called post will be considered for page listings, tag generation and so on.

I'd like to change this, for a couple of reasons. In my Dad's website, The Right Notes, the posts alternate between themes (most recently Australia ) and composers (such as Georges Bizet ). But you wouldn't know there was a distinction just by looking at them. I could add additional meta-data fields, or more tags, and then do logic on the single post.hbs template, but that could get messy and Handlebars isn't really suited to that sort of logic.

I'd like to do a similar split on this website; my new computer game project, Project Herschel, could really do with a regular blog, but I'd love to style it differently from posts like this. After all, Project Herschel is set - in SPACE! - and needs a space-age look-and-feel.

I'm going to add a new project meta-data yaml field, perhaps called postLayouts. From there you will be able to specify a list of templates which constitute blog-posts. Something like this:

postLayouts: [composer,theme]

That way any blog file with a layout of either composer or theme will be rendered with its own unique Handlebars template, but would still be considered a blog post for the purposes of listings, tags and so on. As always with bascule, if postLayouts is not specified, it will fall back to the sensible default of post for the blogging template.

Ordering Posts

There's another problem with bascule, at least for The Right Notes website. That website doesn't display any dates, but the posts are supposed to be ordered: theme, then composer, then back to theme again. The trouble for The Right Notes is that there is no logical date order for this, and the various pages have been uploaded in no particular order. My Dad would like to have some control of how posts are ordered, without relying on dates.

Bascule posts are just plain text files. There is no external meta-data (other than the project definition yaml file). If a date is not specified in the file itself, bascule just grabs the creation date of the file from the file system.

And I'm really not sure how to do it, without adding a whole bunch of complexity to bascule which it doesn't really warrant.