Fleet world hack

Cubes, not falling

Being a games programmer involves spending a surprising amount of time in the company of  coloured boxes.

So it turns out game physics is quite hard to code. Who knew, right? Well… you, probably. And me. And also just about everyone we know. And yet for some reason I just had to go and code it anyway.

This has been a tough month of development. The fact that it ended up five weeks long, which is unusual for June, should tell you all you need to know. And to think I thought this would only take me a couple of weeks.

In my defence, as I noted in my last post, I only wanted to do very simple physics where you move around my landscape and don’t fall through it, but apparently even that is really hard to code if your main qualification is in English Literature.

The problem with game physics in a nutshell: physics is a continuous process, videogames can only simulate it in discrete chunks. If your game runs at 60 frames per second, then 60 times a second your physics code gets a chance to update the simulation, but there’s a tiny microsecond gap between each update, while your PC is off doing something else. If your objects are just flying through space this isn’t a problem, but if they collide it suddenly is, and a huge one. In fact technically, the physics isn’t even the problem: it’s the collisions.

Your objects will collide between the nothingths of a second in which your physics code runs, which means by the time your code tells you about it it’s already happened. How bad can that be? Let me put it this way: because of physics, when a crate is resting on the ground in your simulation, it is actually colliding with the ground 60 times a second. Ah.

Physics: Hi Tony! While we were away some downward acceleration called “gravity” was happening to that crate, so I moved it down a bit. Into that stuff called “ground”. Hope that’s OK?
Me: You idiot.

You have to move the crate back, and you also have to remove the velocity it gained during its little sojourn into the ground, which now never happened. And you have to get the numbers right, or it will start to vibrate as your code gets caught up in a mad spiral of overcompensating and undercompensating at 60 frames a second.

And vibrations will always happen, because you’re working with clumsy approximations rather than the infinite continuity of the real world. Fix one bit and you mess up something else. It’s like trying to mend a watch while wearing boxing gloves. As the month I’d allotted for coding the physics drew to a close, I seriously considered jacking the whole thing in and using an off-the-shelf physics engine such as Bullet Physics instead. But that would have meant maybe another month getting that to work, and maybe finding at the end that it wasn’t a better solution anyway.

Finally, I found what was causing the vibrations and how to fix it. Then I found another problem. Sometimes, running downhill made you bounce up and down. Note the “sometimes”. That took most of this week to solve. Then I had a problem with jumping.

Ah, it’s good to write about these problems in the past tense, from the comfy perspective of having solved them. Which is kind of why I didn’t post anything earlier. Maybe I should try to do that in future, to keep this blog more real.

Anyway. Ever since I started coding this terrain engine, well over a year ago [edit: two years ago], it’s been my ambition to one day run around on its world, just like in a real game, rather than simply flying around (and through) it. The difference in realism is immeasurable, and hard to put into words. How does it feel, after all this time and a final, brutal slog through seemingly unsolvable physics problems? It feels like this:



Flight of the bumbled boxes

This month is timetabled for getting the physics working, which isn’t as ambitious as it sounds as my game isn’t going to need much. All that’s required is enough for the player to fall back to earth when they jump, but not to fall through it.

I originally had physics scheduled for later in the year, and the vaguely worded and scarily aesthetic and subjective ‘Make Terrain Fun’ down as my next task. But then I realised the only way I was only going to be able to tell if my terrain was fun to walk around on was if I was actually walking around on it, rather than flying above like some kind of sentient helicopter. So, physics was required.

After a few days of the preparatory work which sadly seems necessary before I can code anything fun these days, this morning I tried dropping physics-enabled cubes onto my extremely primitive collision detection system, and this happened:

Falling down a fractal rabbit hole

Oof. Let’s try not to do that again.

I wanted to make a cloud plane, you see. Nothing complicated, just a plane in the sky with cloud textures on it, to make looking up more interesting. The only issue was that I would have to learn how to draw textures using shaders.

Oh, sure, my engine could already draw textures the old way, like this:


But back then it was a 2D engine I was writing to teach myself the rudiments of graphics programming. So I was using what’s called OpenGL’s Fixed Function Pipeline – the old-school way of drawing where OpenGL gives you a bunch of functions so you can tell it “here are some vertices, please draw them as triangles here using this texture”. Simple, but as dead as a diplodocus. Nowadays, everything is drawn using shaders, where you actually write little programs for your graphics card to run directly. Shaders are more powerful, but the FFP was what I was used to and I didn’t want to learn too many new things at once.

When I made the jump to 3D programming, I made the jump to shaders, but up until now I hadn’t had to draw textures. Turns out it’s pretty easy. And that’s where the trouble started.

Now that I was using shaders for everything, I thought, it was time to rationalise and streamline how I used them, which had been a bit ad hoc up until now. You know, like a real, grown-up programmer, like Randall Munroe.

You’ve basically got your choice of analogies here. We can either go with “falling down a fractal rabbit hole”, where every bit of code you rewrite turns out to require another bit of code to be rewritten which requires another bit of code to be rewritten until you start to forget your own name, or we can go with “replacing all the moving parts of a car engine with new ones while the car is still running”. Take your pick.

For a long while, nothing worked. Including all the bits that had previously worked, like my lovely scrolling terrain and the sky dome. Eventually, I crawled out of the next-to-last rabbit hole (yeah, went with that one in the end) back into the first rabbit hole, because that’s how fractals work, and then out into daylight. Beautiful, cloudy daylight.

Ah, it was worth it. I’m going to be doing a lot more work with shaders and textures from here on in, and I now have a solid foundation of flexible yet well-structured code on which to build.

Now if you’ll excuse me, I have some tidying to do.

Rolling countryside

A few days ago I threatened to show you my terrain speedily scrolling, so here it is, under its nice new sky dome. Those new hills and mountains you see appearing are’t being loaded from a file, they’re being procedurally generated on the fly, at about 840 frames per second. They didn’t exist, anywhere, until about a millisecond before they appeared. The miracle loses something in the translation to blurry downscaled video, but trust me, it’s brilliant. There’s a first-person bit at the end so that you can appreciate the sky dome.

Otherwise, after the heady excitement of rediscovering trigonometry, it’s been a bit of a slow week. I’m beginning to realise that I can’t always be coding and moving the project forward every day. I have to plan my next steps out on pen and paper like a good programmer, I have to read articles, I have to learn how to do all sorts of things that are completely new to me. Unfortunately, when you’ve committed yourself to something as massively daunting as making a game, and maybe even rashly started blogging about it, you can start to feel vaguely panicky when you stop making obvious progress.

Oh well, early days and all that. Onwards!

Dome man’s sky

Screenshot 2017-05-02 17.22.52

Well, that’s my sky dome. The perceptive among you may be saying to yourselves “that’s not a dome, and it’s inside the sky.” You may even have added “also, it’s inside a mountain.” All true, for various exciting reasons.

Like most things in 3d graphics, that dome is made out of triangles, and the interesting thing about triangles in 3d graphics is that they have a right side and a wrong side. When the right side is towards the viewer, the graphics software draws the triangle, when it’s not, it doesn’t. This is called backface culling and it’s a little piece of genius. If a triangle in your scene is on the back of a crate or the back of a mountain, the viewer can’t possibly see it, so you don’t want to draw it. How does the software know not to draw it? Because the wrong side is facing the viewer. In a typical scene this simple idea saves hundreds of thousands of wasted drawing operations every second.

I built this dome to wrap around my scene – it’s a sky dome – so the viewable sides of all its triangles face inwards. The nearside of the dome has all its unviewable triangles facing towards you, so they’re invisible. Instead you’re seeing the inside triangles of the far side of the dome.

Why is it smaller than a small mountain? This is the best bit. A sky dome can be any size you like. It can be as small as a nutshell, and still seem as large as infinite space. You draw it first, from a viewpoint somewhere inside it, because the sky is going to be the most distant thing in your scene. Then everything else you draw after that, such as mountains or Prince Hamlet, will overwrite the dome, so it will appear to be inside it. In the picture above I just haven’t done that bit yet.

That was this morning. This afternoon I switched streams and started work on my Branching Narrative Compiler, but that’s a whole other story.

OK, that’s quite enough meta

Day 1 of actually Making My Game For Real. Started badly, but I rallied. I had three things I wanted to make a start on: flatter terrain; a sky dome; and my Branching Narrative Compiler. Unfortunately, last night in bed I also had what seemed like a cool idea for tweaking the terrain engine, so the first thing I tried was that. Didn’t work. Thought I could see why, tried some other stuff because now I’d committed too much time and wanted something to show for it, and before I knew it the morning was gone.

OK, lesson learned. From now on, stick to the plan. If I want to try other stuff, I do it in my spare time: evenings and weekends.

Played a bit of Sir, You Are Being Hunted, because hey, it’s a bank holiday, I’m not supposed to be working at all, then in the afternoon I tackled the sky dome. This is, as the name implies, a dome you put around your world to give an impression of sky. You can tint it different colours for the time of day, make it lighter near the horizon, etc. As the name also implies, it requires a dome. I didn’t think this would be too hard to make. I was bad at maths at school, but I got the hang of trigonometry once my distractingly attractive teacher (where are you now, Miss Perks?) taught us the brilliant acronym Stupid Old Hag Cracked All Her Teeth On Apples. Sin = Opposite / Hypotenuse, Cos = Adjacent / Hypotenuse, Tangent = Opposite / Adjacent, you see. You can go surprisingly far in O Level Maths with that one. But not as far as finding the vertices of domes. Not if you’re me. I know how to find the vertices of cylinders, but this was a step into the unknown.

I could have simply cut and pasted someone else’s code from online. I could have made a dome in Blender and exported it. But I knew if I worked out how to do this I would have learned something useful, so I persevered. I looked up meridians and parallels, I tried different formulae on paper, and I worked it out more or less from first principles. (sin lambda * cos theta, sin theta, cos theta * cos lambda) * radius, in case you were wondering. Obvious really. Those of you with any maths skills are no doubt wiping the tears of merriment from your eyes right now. Hey, I studied English Literature. Can you write an essay on the symbolism of Partition in contemporary Indian novels? No? Well shut up, then.

My code made this lovely, dome-shaped spread of vertices, which over the next few days I shall turn into a solid, shadeable dome. Onwards!

Screenshot 2017-05-01 18.20.24

Difficult second post

Screenshot 2017-04-27 15.28.14

It’s been an interesting week. A little while ago it was going to be my first week of Making My Game For Real, but as the date got closer I realised there were a few bits of my terrain engine I wanted to sort out first, so I moved the official starting date to tomorrow, May 1st, and this became the week of Sorting Things Out instead.

I got most of the Things mostly Sorted, but I also kept running into the bugs and glitches they threw up, and each one of these just devoured my time trying to track it down. It’s a salutary lesson about how time you scheduled for moving the project forward can end up being spent – constructively spent – without actually getting any further at all. Part of the problem is that my terrain engine is the product of two years of non-seriously messing around. If I wanted to do something I would find out how to do it by just diving in and coding up an idea to see if worked and how well. That’s not only a meandering way to get things done, it also leaves you with very messy code that you stopped working on the moment it did what you wanted, full of copy-and-pasted repetitions and functions you haven’t labelled because at the time you didn’t know if you were going to keep them.

Never mind. At least I have a much better idea of how not to approach coding from now onward. And to be fair to myself, I’m already doing better: planning things out in a document before I start coding, for instance. And I have made progress. Terrain which for the best part of two years looked like this:

Screenshot 2017-04-30 19.05.44

now looks like this:

Screenshot 2017-04-28 11.36.53

And it scrolls stupidly fast, too. I’ll have to work out how you post moving pictures on this WordPress thing so that I can show that off.

The other good news is that if the game doesn’t work out, it looks like I could still have a thriving career in 1930s abstract art.

Screenshot 2017-04-28 10.22.48