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.

Textual objectification

When a developer doesn’t update his devblog for a whole nine months but keeps working on his game all that time, you just know the end result is going to be something amazing, right? Well hold onto your hats – why you have multiple hats I don’t know – because here is the result of all my secret labour. Right here, right now:



You can probably see why I didn’t bother updating this blog now. I’ve been working on Tig, my compiled programming language, all this time, and programming languages just aren’t that exciting to blog about. Nor do they make for exciting videos. I didn’t even realise how amazing I was being until one day, out of curiosity, I turned on my text editor’s code-styling option – the setting that colourises for clarity. And wham! My bland, middle-class-white-boy code turned into this:


I know! It’s like something you see scrolling up someone’s monitor in Mr Robot, right?

That was when it hit me: oh my God I’ve actually created a programming language.

That’s not C++ you’re looking at there, or whatever bobbins GameMaker uses. That’s Tig. That stuff is read by my compiler, turned into machine-independent bytecode, then run in-game to produce the video you saw above. Codewise, I’ve done something pretty incredible. For an English Lit student.

Yet when people ask me how the game’s going and I try to explain Tig to them, a sort of glazed, polite-but-where’s-nearest-exit look appears in their eyes. I can’t really blame them. Programming is hard and boring to explain, programming compiled programming languages doubly so. Indulge me in this quick BBC Bitesize summary and we’ll never speak of it again.

It’s an Object-Oriented Programming language
OOPs tie together related code and data in virtual objects that message each other. This is very handy for game design, where you’re basically making a world full of virtual objects that interact. Such as crates. In Tig, you make a crate by writing:

CGameObj crate has name “crate”, description “A standard wooden crate for use in games.”,
weight = 10;

This says “make an object derived from CGameObj and give it a property called ‘name’ set to the text ‘crate’, a property called ‘description’ set to the text ‘A standard wooden crate…’ and a property called ‘weight’ set to the integer 10. CGameObj is another, much more complicated Tig object that handles all the default game code for in-game items, such as printing the description text when you examine them. And this is the clever bit: because our crate is derived from CGameObj it will inherit all that functionality automatically. You don’t have to write another word.

Suppose you want the crate to shatter when it’s hit. The game calls an item’s ‘onHit’ property if it receives damage, but the CGameObj default onHit response is to do nothing. So we write this:

CShatterable has onHit() { print “The ” + name + ” shatters into pieces!”;
destroy self; };

Now if you derive our crate from CShatterable as well as from CGameObj, CShatterable will hijack onHit. The result: a fragile box that destroys itself on receiving damage, and tells the player this has happened. But the really clever bit is that now you can attach CShatterable to any item to get the same effect, whether it’s a Ming vase or a mastodon.

Want an exploding crate or mastodon? Write this:

CExplosive has onHit() { print “The ” + name + ” explodes in a fireball!”;
destroy self;
player.onHit(100); };

Notice how the exploding object will now use the player’s bespoke onHit property to give them splash damage.

Once you’ve coded a few useful template objects, you can create in-game items with quite complicated behaviour simply by combining them. This should pay big dividends later in the development cycle.

It creates its own hypertext
Interactive fiction is not cool. One of the reasons for this is that in an age of virtual-reality spaceships, you still have to laboriously type what you want to do in an IF game. I’ve tried to offset this a little by using hypertext, so you don’t type, you just click.

The clever bit isn’t the hypertext. The clever bit is that Tig will mostly hyper that text for you. If you write a room description that includes the text “…there is a narrow passage to the east”, Tig will understand that ‘east’ is a direction, and if you can go east from this room it will turn the word ‘east’ in that sentence into hypertext that will take you east when you click on it. If you write a room description that says “an old piano moulders in the corner” and you’ve coded a complicated piano for the player to interact with, Tig knows to make the word ‘piano’ hypertext and connect it to your piano code. Most of the hypertext you can see in that video – just about – is being created and removed on the fly by Tig.

So there you go. All this took a long time and an awful lot of work. One day it may yet end up in an actual game. Until then, I’ll try to code something less geeky for the next blog entry. See you in another nine months!



Of cats and cake

This has been a successful month, but not very graphically so, so you’ll just have to take my word for it. I created my own programming language, Tig, which is what Ghostworld will mostly be written in. It consists of a compiler, a virtual machine to run the compiled program on, and the language grammar itself. A very simple program written in Tig might look like this:

event robotTea { 
 "The robot abruptly turned around and glided away into the back room. I noticed that it had left its cream cake on the table.";
 option "I hurried after it." backRoom;
 option "I stealthily helped myself to another slice." stealCake;
 option "I remained seated." remain;

event backRoom {
 "The robot was just settling into an armchair as I arrived. ""Where is my cake?"" it demanded.";
 option "I apologised profusely." killed;
 option """Fetch your own damn cake."" I told it." killed;

event stealCake {
 "Just as I was tucking in, the robot returned. ""CAKETHIEF!"" it grated, and tore me limb from limb.";
 option "I allowed my ghost to float somewhat implausibly back in time to our first meeting..." robotTea;
 option "I decided to call it a day." quit;

event remain {
 "After a long time the robot returned, and cut itself another slice of cake.";
 option "I smiled nervously." robotTea;

event killed {
 "Alas, I had underestimated my host. ""BAD GUEST!"" it grated, and tore me limb from limb.";
 option "I allowed my ghost to float somewhat implausibly back in time to our first meeting..." robotTea;
 option "I decided to call it a day." quit;

event quit {
 "The end.";

If you compiled that source code and ran it on the virtual machine, you could interact with it like so:

The robot abruptly turned around and glided away into the back room. I noticed that it had left its cream cake on the table.
1: I hurried after it.
2: I stealthily helped myself to another slice.
3: I remained seated.

The robot was just settling into an armchair as I arrived. “Where is my cake?” it demanded.
1: I apologised profusely.
2: “Fetch your own damn cake.” I told it. 

Alas, I had underestimated my host. “BAD GUEST!” it grated, and tore me limb from limb.
1: I allowed my ghost to float somewhat implausibly back in time to our first meeting…
2: I decided to call it a day.

As you can see, Tig makes it easy to write branching narrative games. But it can already do a lot more. You can make player options execute code statements, such as “robot.temper = ‘piqued’;”. You can create objects simply by writing “object cake has description ‘A daunting confection of mascarpone and sponge’, weight = 20;”. Many more powerful features will follow.

Writing your own programming language is no easy task – why go to such trouble? One reason is that it’s a basic rule of good programming that you separate your code and your data. In the case of a platform game, for example, your code is the bit that handles input, graphics, and so forth, and the data is the level. You could mix all the level data in with your code, but it would result in a gigantic, unwieldy morass of numbers and C++ statements, and every time you wanted to change a single brick in one of your levels you would have to hack around in that monstrosity and then recompile the whole thing. Keep code and data separate, and all you have to do is write one clean function that does a thing when it encounters a brick, and you’re free to create and tinker with as many brick-based levels as you want in your level editor.

OK, so this argument gets stretched a teensy bit in the case of Ghostworld, because my game is a work of interactive fiction and so its data has to include code of its own – but, shut up, because the same principles still apply. A text-based, interactive game’s script is its data, and designing any game in its own dedicated, user-friendly language is far easier than trying to hard-code it in C++, or Unity or GameMaker for that matter.

The other reason I’m writing my own programming language is this guy:


Tig and Cas were our first cats, and Tig was the first to die, in 2008. It came out of nowhere, it wasn’t fair, and when he was gone I really missed that little guy. To amuse myself, and to keep his memory alive in some way, I decided to call the programming language I had just started to create back then ‘Tig’. I found the intricacies of language creation fascinating, and it became a wildly ambitious project, boasting dynamic typing, multiple inheritance, and much more. Alas, I was not a great coder in those days, and it was all built on messy, amateur, poorly thought-out C++. Improving it became harder and harder, until in the end I just quietly stopped, but I always felt a little pang of guilt for not doing right by my mog.

When I decided to make this game, I quickly decided that it needed its own scripting language, and I knew immediately what that language would be based on and what it would be called. I made myself start from scratch, but that first attempt helped hugely: I knew what worked and what didn’t, but most importantly this time around I knew how to code it properly, which is why this month has been a month of rock-solid progress. Thanks, little dude.

Strange fruit

October marks an exciting change in direction for the development of my game. Exciting if you’re the one who’s been writing the thing for the past five months, anyway. Less so for everyone else.

For a start, the game formerly known as ‘my game’ now has a tentative name. How does Ghostworld grab you? Yeah, I’m not too sure either, but it will do for now.

The bigger change is that I’m putting graphics development on the back burner for a while.

I had a six-month plan to produce a rough, playable game, where each month was dedicated to another part of the graphics engine. October was meant to be Make Buildings, and November Shadows and Water. But my game – sorry, Ghostworld – was always supposed to be a work of interactive fiction too, and I’ve been guilty of sidelining that. I started to feel a little uneasy a couple of weeks back, as I wrestled with recalcitrant fractal plants and realised I had a lot more work to do here, and also in a whole bunch of other graphics areas, before I would have anything that looked remotely like a game. Should I just plod on like this? And on, and on, and on?

The received wisdom is “no”. Derek Yu and some guy called Tom Francis both made playable prototypes of their games as quickly as possible, and then evolved them. A lot of other devs advocate the same approach. And it’s a lesson I’ve already learned over and over in fiction-writing: get a rough draft finished before you do anything else, as fast as you can, no matter how bad it is. If you stop to fix and polish bits, you lose momentum.

You don’t play with the graphics in my game. You play with the interactive fiction. If I want to make something playable, it’s the text side of things I have to get working first, as fast as I can. So that’s what I’m doing.

This will result in less graphically exciting blog posts, which is probably one of the subconscious reasons why I’ve been ignoring the IF stuff all this time. Another, I suspect, is that as long as I’m not working on the actual game, I don’t have to worry about how good that game is, or indeed how good I am at making games. I’ve been living with myself for some time now, you see, and I know how my mind works.

So here are some current screenshots of Bedquilt Land, just in case it’s a long time before I post any more:3DTest 2017-10-01 19-42-05-38.bmpScreenshot 2017-10-05 15.40.12Although the fractal tree improvement didn’t get very far, what I did achieve was to get trees and grass growing in more natural clusters, rather than uniform, unbroken swathes. So there’s that. And yes, my trees have square fruit now, shut up.