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:

Advertisements

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:

platformer

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

Non-specific first post

When it first occurred to me that if I resigned from my job I might have enough time to write a videogame – March 8, 2.22pm, apparently – I experienced an immediate rush of ideas that I knew I had to get down before I lost them, so I opened a Google doc. Because these ideas were just generalised amorphous feelings about the kind of game I wanted to make rather than anything specific, I called the doc ‘VagueGameIdea’.

This is the dev blog for that game.

The ideas are a little more focused now. The elevator pitch is “explore the mysteries of an alien world as the lone protagonist of a 1970s science fiction novel”. It’s going to be a work of interactive fiction, because I know how to do words and because it’s about 100,000 times easier for a one-man development team to write “you see a scintillating alien city on a hill” than it is to model one in 3D. But it’s also going to have an infinitely explorable 3D procedural landscape, because I’ve spent the last two years coding an infinitely explorable 3D procedural landscape graphics engine, and there was no way I was going to throw all that work away. It’s an odd mix, I know, but as soon as I thought of it the perverse juxtaposition appealed to me. At least this way I’m going to make something a little different, and perhaps the novelty value will appeal to other people too.

I decided to keep a development blog because Graham Smith suggested it, and because I think it will help me to take this project seriously – it’s harder to quietly abandon something once you’ve put all your dreams and strivings up there on WordPress for everyone to see. Hopefully there’ll be a few useful insights along the way, too.

I anticipate posting to this blog a great deal in the early days of development, and then much, much less as the novelty wears off.