Early hex mass-presence

Lordy. It’s a long time since I last updated this place.

I have, believe it or not, been working solidly all these months, mostly looking at ways to make a heavily text-based game look exciting to play. The reason I never blogged about it was because I couldn’t find any.

I tried many things. Animated text. Text that rewrote itself depending on what choices you made. Clever algorithms for describing procedurally generated locations and fights with robots so that no two were exactly alike.  The more things I tried, the more stubbornly my game insisted on looking like a text adventure from the mid 1980s. I began to get an uneasy feeling that maybe there was a good reason why computer games abandoned text as soon as they had enough money for the bus fare.

Was… was I making a boring game?

* * *

Finally, around the end of October, I had a little epiphany. Including some kind of graphics with the text had always been part of the plan: I’ve got a whole design doc full of options I’ve considered at one time or another. My problem was always that any conventional approach, such as tile graphics, required either a huge investment of time and artistic skills that I didn’t have, or a lot of money to hire someone else to do the work, which I also didn’t have. But suddenly, two ideas in that design doc made brilliant sense together. One was using vector graphics to present the world in a deliberately abstracted, sci-fi combat simulator kind of way. And the other was hexes.

Screenshot 2019-12-19 13.35.19

Hexes are great shorthand for saying “this is a tactical representation, it’s not supposed to look real”. Also, they just look really cool.

Simple, iconic line-art is something I can just about do. And I already have a 3D graphics engine that’s mostly spinning its wheels. What’s not to love about this idea?

It is a big step, and it’s going to have a big knock-on effect on the rest of the game, as a lot of things I was previously going to do using text I can now do with graphics. Distance in combat, for example, was something I was going to fudge: enemies would either be “close enough to hit”, “a little way off”, or “very far away”. The combat itself would have to be described blow-by-blow, which with multiple opponents risked getting both confusing and repetitive. With simple representational graphics, all these issues and many others go away. The game will still be very text-based, but now I can use text where it works, instead of trying to force it to solve problems it was never a good fit for.

The short message is that I’m reinspired. I’ve been enjoying coding this hex graphics stuff more than anything I’ve hacked out in the past half year or more.


Hexes are crazy, but in a good way. You know how ordinary 2D graphics has two axes, X and Y? Ordinary 2D hex graphics has three axes: X, Y and Z, despite having no third dimension. That’s because a sprite can move to an adjacent position not just to the left or right, but along two diagonal directions, and you have to be able to deal with that.


I’ve had to implement real-time hex-based pathfinding, so that the player sprite can navigate around obstacles and so can the robot sprites when they’re chasing it, and that was really fun too.


As Michael Bublé so topically observed, it’s beginning to feel a lot like proper game coding. Happy Christmas!


A quick update and a movie?

Why not. It’s been a while since we’ve had any moving pictures around here.

Remember when I said I was using my procedural texture generator to create random navigable paths, and you said “hey Tony, that sounds really interesting and I can’t wait to learn more”? Crazy days! So anyway, this is what my procedural paths look like now:


Sort of like The Very Hungry Caterpillar Visits Chernobyl, or The Incredible Hulk’s sperm. The yellow line is the actual path, and the green tells the terrain generator to what extent it should accommodate it at any given point. Thus the big green circle creates a flat area at the end of the path where we can place a building without it ending up inside a mountain or something.

Using an image like that as data, I can create entirely random terrain, full of ridges and crevasses, and always be sure the player has a route to their destination. Here’s a very rough proof of concept.

You hit the cleaning robot with the adjustable wrench for 7 damage!

This month was a journey into strange and uncharted territory for me. Instead of making tools to make a game I hadn’t made yet, I actually made a small quantity of game. Something playable. And it only took me two years to get this far.


The little bit of game I’ve made is the combat system, or at least, the bare bones of it. The finished thing will be big and complicated. My principle, right from the start of this whole project, was that even though the combat was going to be text-based it had to be varied, enjoyable and polished. It had to be more than just the old Roguelike thing of “The orc hits you for 7 points of damage! You hit the orc for 3 points of damage!” And I mean no disrespect: even that stuff takes a lot of work to get right, as I was soon to learn.

I found myself following the trail a thousand pen-and-pencil RPG developers had trod before me, battling the same demons they had fought. Do you want everything in a round of combat to happen at once? No! If the player and the monster are down to their last hitpoint each, you want it all to hang on who strikes first. There has to be sequence, but blended with a pulse-quickening element of chance. That is precisely why village halls and teenage bedrooms have echoed down the years to the immortal cry of “Roll for initiative!” But code rolling for initiative into a videogame, and that has ramifications: you have to be able to sort your combatants so that they act in the right order, for one thing. Suddenly my programming language, Tig, needed a bubblesort facility. You need to know if an enemy is active or not, or off-balance or not, so now I needed binary flags.

This was actually a lot of fun. I’ve discovered that now I’ve coded a working compilable language, adding new features to it is actually pretty easy. And I can add whatever I want, because it’s my language. All those little things Bjarne Stroustrup didn’t put into C++ because he didn’t know people would one day need it to code videogames, I can put into Tig. And the really cool bit is that once they’re there, they’re there for good, making other tasks easier as you get to them.

The biggest challenge has turned out to be trying to get the code to describe the action in good English. There’s a reason most text games say things like “The cleaning robot is attacking you! The servobot is attacking you!”, rather than “The cleaning robot and servobot are attacking you!” and that’s because it’s a lot easier. Sure, you can code a little loop that lists the names of all the robots in the attack, but what if there are ever three robots? Now you want to say “The x robot, the y robot and the z robot are attacking you!” The first two terms have to be separated by a comma, the last one by an ‘and’. Now your loop has a messy ‘if… else… ‘ statement nesting in it. Soon, they’re all over your code, like hideous syntactical tumours. Computers don’t do grammar, you have to teach them all these little rules.

Anyway, it’s a work very much in progress, as that screenshot shows. But I’m pleased to have set off on the adventure.


I knew no harm of Bonaparte

Ha ha, yes! Funny! When I signed off my last post with a cheery “see you in another nine months!”, that was supposed to be a joke. Of course I wasn’t going to leave it for months and months before I updated this devblog again. What kind of useless dilettante of a game developer would I be if I did a thing like that, right?

Anyway. I’ve been working on procedural textures, and like every other aspect of this project it’s proved to be not so much a time sink as a time bottomless pit into which you can tip whole wheelbarrows full of your life. I needed a tool for experimenting with procedural graphics techniques, and I needed code my game could use to turn those techniques into textures on the fly, and while there is masses of stuff concerning procedural graphics out there on the internet, there’s surprisingly little of it that goes beyond “here’s how you make marble.”

The guilty truth is, I was glad about this.

Procedural graphics is another of those computer-related byways that has fascinated me for years. I can’t tell you how many long, boring afternoons in the office were enlivened by fantasies about coding my own procedural texture explorer, and furtive peeks at Web pages on Perlin noise. So now the opportunity had come along, I jumped at it. I started coding an app to create, load, tweak and save procedural textures, and I started researching how you make the actual things themselves.

Long story short, here’s how you make marble:


That’s fractal Brownian motion noise. I won’t explain what that is because frankly there are about a million sites on the internet that do that already, although most of them incorrectly call it Perlin noise. In a sentence: Perlin noise is ‘coherent’ noise, noise that looks like this Perlin rather than this Noise, and if you overlay it at increasing frequencies with diminishing amplitudes you get fBm noise.

What happens if you map a palette of black and white stripes to those shades of grey above? You get this:


Look closely and you can see it’s the same texture.


But that’s only the start of the weird and wonderful things you can make using procedural techniques. This, for instance:


I have no idea what I’m going to use this for.

That’s an example of what happens when you start layering different procedural textures together. For example, with my texture compositor you can take this fairly boring fBm texture…


overlay it with this slightly more exciting ridged fBm…


and tell the compositor to blend the two together using this blobby pattern as a mask:


Apply an earthy colour palette and hey presto:


A close-up of a muddy river bed? The bark of an alien tree? I don’t know, but it looks good.

Here’s another example of masked blending:


Isn’t that lovely? I call it Damascus because it reminds me of Damascus Steel.

This is what the texture compositor itself looks like:

Screenshot 2019-02-22 09.00.03

That list of items under the label ‘Tex gen stack’ is the series of texture generators used to create that image. Each has its own controls, which appear in the box below. What you can see there are the controls for the Colouriser, which let me create and fiddle with colour palettes. That whole UI is handmade, by the way. Every button and scrollbar. I wrote the library for that a few years back, and it’s really paying dividends now.

That was an example of fBm mixed with Voronoi noise, which is a very different algorithm. It creates textures like this:


I call that one ‘Alien skin’.

fBm and friends are great for making organic-looking textures, but I’m also interested in making artificial-looking ones for sci-fi structures. This is an early experiment:


And finally, one of the most intriguing uses for procedurally generated textures I’m looking into is one where you’ll never see them at all:


That’s a randomly generated path between two points, created on the texture compositor. I hope to use these to ensure my computer-generated terrain always has a route through it, no matter how rugged it gets, which is the kind of thing you have to worry about if you want to create a procedurally generated game people can actually finish. The early tests have been very promising.

It was a lot of work getting there. Computers are really, really bad at meandering. Let alone going for an amble. Trust me, you do not want to take a computer with you on a drunken country stroll.