OMG I CAN'T SEE WHAT'S GOING ON! THIS GAME IS RUBBISH!

Yeah, so… you’ve seen bullet-hell style shoot-em-up games. Well how about baddie-hell ones then?

No, this is quite obviously not sane and nothing at all like the intended gameplay. Let’s just say I might have a few bugs in my enemy generation code. Mind you, it is a rather good test of the whole update and draw loop – every one of those enemies is being mindlessly collision tested against every one of the orange bullets and the player. Using a simple circle-circle test. No fancy space partitioning or trees of objects, just a lot of

For all the enemies
    For all the bullets
        If the bullet and the enemy are touching
            bullet-you-just-hit-enemy(enemy)
            enemy-you-just-hit-bullet(bullet)

And then some moderately complex code to rip the objects apart into their component triangles so they explode in a pleasing way – it’s kind of the modern 3D equivalent of Robotron’s sprite shatter effect.

Exploding the 3D objects is easy, just draw each triangle a set distance from the centre of the object along its surface normal. It’s a single line in the shader.

I figure that if it goes really slow when I make the enemies do more taxing things than slide down the screen then I’ll look at improving the code.

Here’s a video. Next on the list … making enemies appear slightly slower with more interesting behaviours.

Click here to view the embedded video.

Here’s how to make a new custom code template in XCode 4. It’s surprisingly simple to customise your empty C++ files to remove the useless iostream include and the boilerplate junk at the top.

That’s what we’re aiming for, a separate entry in the list on the left and then a template to choose from.

Step 1 – Copy some files

We have XCode from the Appstore, it doesn’t live in /Developer any more so ignore anything that tells you to copy stuff out of /Developer/Xcode because they’re now wrong.

Instead…

Go into /Applications and right click XCode and choose Show Package Contents. Then navigate to Contents/Developer/Library/Xcode/Templates/File Templates.

This is where all your templates live.

Do not edit these files, ignore anyone who tells you to, they are going to cause you pain and suffering in six months when you absent-mindedly update Xcode.

Instead we will make our own copy in our home directory; this is Unix and we can do clever things that save us time and effort later when how to do this has leaked from our brains.

So open a second Finder window and navigate to ~/Library/Developer/Xcode. If these folders don’t exist you will need to create them, but bear in mind that certain folders are hidden in Lion. Try using the ‘Go’ menu in Finder and typing in the path manually.

You’ll need a folder called Templates and inside that one called File Templates

In there copy the relevant folder from the equivalent in Xcode’s package. I copied the C and C++ folder. Once copied, rename this folder to something more meaningful, the name of this folder appears on the left of the ‘Choose a new template’ window. I called mine ‘NCOT C and C++’.

Start XCode and check you see the new template choice. If you don’t, you put the files in the wrong place.

 Step 2 – Edit the template

This is the easy bit, just open the files you copied and make changes. If you do this on Lion you’ll need to ‘unlock’ the files first.

If you copy the C++ header template and the C++ code template into the same folder Xcode will generate both at the same time for you… just like it used to do in Xcode 3.

Oh, and I know this is more effort than simply hacking the contents of the master templates but at least this way if you delete Xcode and reinstall it your changes are preserved.

It's a canyon, there's stuff to shoot at... it appears to be shooting back at you.

Here’s some more progress on my iOS shooty game. There’s now things to shoot at and a more usable control system. Click the video below to watch…

Click here to view the embedded video.

Righto now you’ve seen the pretty video, here’s a short explanation of what’s going on…

The main attract screen contains the name of the game, spinning neatly in space. I constructed it using the pretty cool Milkshape 3D since it contains a feature to produce 3D renditions of text. Under that is a spinning collection of all the 3D models the game knows about, some of them might look vaguely familiar. Please ignore the washed-out look of them, that’s my phone’s camera’s fault. And under the spinning ships is a good old textured quad.

All games need attract screens, there’s no point in having a menu or anything with a game this simple. At some point there’ll be a thing to click on to view high scores and commune with the sacred OpenFeint but that’ll be one of the last things to go in.

The main ‘game’ now has the ability to place enemies which have the freedom to move around the screen and shoot at the player in whatever manner they decide. Currently you can see some pretty spinning enemies that fart out neat sprays of bullets at timed intervals, when I enable collision detection they’re going to be proper pains to deal with! They are also a good test of the basic entity handling and bullet management code I wrote and now I also know how many bullets is ‘enough’ for the screen.

The ship is controlled by sliding your finger on the screen. It’s a bit twitchy but when trying to avoid being blown up there’s nothing more annoying than laggy controls or half-baked inertia that sends you skidding across the screen. I may fiddle with it later when there’s actual threat to the player, but for now it’s OK. You’ll also notice the player’s ship shoots constantly; the whole game is controlled using a single finger with not a hint of onscreen joystick nastyness. Back in the 80s we used to pay money for joysticks with autofire so that our shooting games didn’t require constant mashing of the fire button… consider how fun it isn’t to repeatedly mash a finger against a glass iOS screen to simulate the same thing. No, it’s not fun so let’s have the ship fire all the time shall we? Yes.

Although there might be a power-down that switches your guns off briefly and a whole load of powerups that alter how your bullets move so it won’t be quite so ‘wave your finger randomly to kill everything’.

So what’s next?

Well, apart from the collision detection code the main “engine” of the game is complete enough to produce a playable game. Now it’s time for the other 80% of making a game – the actual bit where I make a game! I need to sit down and decide on fun enemy designs and movement patterns. I’ve decided the focus on this game will be a wide variety of enemies and behaviours. I tend to get bored of shooters pretty quickly once I’ve seen all the enemies and died in the bullet hell they produce, so having plenty of different things to blow up should add some interest.

So lots of careful ‘research’ and staring closely at paused emulators and YouTube to look at chunky 90s 3D models is in order… plus playing the odd shooty game

No 3D engines were harmed in the creation of this software, it’s all written using nothing more complex than OpenGL ES 2.0, C++ and as little Objective-C as I can get away with. While writing code this week my Mac’s SSD died so I lost a fair chunk of time restoring my backups onto a regular HDD. I didn’t lose any data though The videos are recorded by hand using my iPhone’s camera, it’s a tricky business balancing the brightness of the screen and avoiding any glare on the shiny iPad display. Since these are just test videos I shovel them straight into YouTube rather than spending time editing them.

The Problem

I need to make lists of students using Excel so I can track their grades and so on. I have real-world amounts of data to process – 15 groups of students, each group containing on average 20 students. The aim is to do this chore without wasting too much time as I actually need to use the spreadsheet for a purpose, rather than just for learning how to make a spreadsheet.

Getting Data

Fortunately to save a lot of effort the school registration system lets its users export data in a tab-delimited CSV file. The output looks like this

From this you can see the ‘Student Name’ column contains the student names as a single field with a comma between them. This is a bit of a pain when it comes to mail-merging student reports and generally organising the information.

The names need splitting up and that horrid UPPER CASE text correcting – it looks a bit unprofessional if a student’s ICT report contains ‘BROWN, Paul’ at the top instead of ‘Paul Brown’.

Splitting the text

Splitting this up is as easy as pressing the ‘Text to columns’ button in Excel but it has a few drawbacks such as overwriting the columns around the data it is expanding. You’ll also discover it leaves the space between the comma and the first name.

And if the list changes, you need to remember to do it again. I’ll be doing this every year with all my classes, so having a master spreadsheet I can simply copy and then fill in will save hours. And the easier I make this process the more likely I am to remember how to do it.

Working smarter, not harder

Let’s use Excel for its intended function shall we? I.e processing data using formulae.

Now all I have to do is paste the raw names from the tab-delimited file and the rest of the sheet updates itself automatically. Now, at the start of the school year all I have to do is

1. Copy any of last year’s class spreadsheets to a new file
2. Export the class list from the registration system
3. Copy the raw list of student names and paste into the spreadsheet

No complicated button clicking procedures just simple and mindless copy-and-paste.

The formula looks like this, assuming a column of data in ‘LASTNAME, Firstname’ format

=PROPER(LEFT(A2, FIND(",", A2)-1))

=PROPER(RIGHT(A2, LEN(A2)-FIND(" ", A2)))

How they work

Find() takes two parameters – the character string to find and the cell to look in.

Left() takes two parameters – the cell to look in and the number of characters to extract. If you notice I’ve taken 1 from the value find() returns so that the comma isn’t included.

Proper() just converts whatever text you give it into Proper Case.

The second formula does a very similar thing, except a bit of extra faff is required because Right() returns the rightmost number of characters from a string, but Find()  only tells us where in the string a given character is. However a bit of common sense should tell you that if you know the length of a string (using Len()) and take off the position Find() gives you, it’ll return the number of characters to the end of the string.

Later I might document how to mail-merge data using an Excel spreadsheet as the source.

This week’s learning point – your game only needs to be convincing enough, it doesn’t need to model reality…

Mmm Euler integration

This week started with me having the simple challenge of “stop the ship going off the screen” and this lead me on a merry trip trying to calculate reflection angles for spheres intersecting planes and after some rather hideous problems deciding to look at a proper physics engine. Calculating physics is kind of hard so surely a pre-made physics engine is a great idea – more writing game, less making ‘engines’.

Yeah. And I’m sure it is if you want to make a game where physics is the main ‘thing’ and where you already have a fairly good grasp of physics. I spent a productive hour creating a new XCode project, importing my old code, deleting a load of unused code and generally tidying things up and then I dropped the Bullet Physics source in there. Bullet looks quite impressive but be prepared for a lot of digging around in source code – its documentation is rather thin. There’s a comprehensive list of API functions to read in that fantastic machine generated way Doxygen “documentation” is, and there’s a PDF that gives a brief overview.

After a few days of trying to figure out how to get beyond the ‘bouncing cube on a surface’ demo to something more game-like I decided I don’t really need a physics engine. I’ll stick with trying to learn 3D coding for now, physics engines can wait until I’ve got everything else sorted. Their black-box nature confuses me somewhat.

So, using nothing more than some simple pretend physics and bounds checking I have this working… The ship won’t go outside the game area and its little bullets will destroy the oncoming enemy ships. All done using 1980s style computation. Retro gameplay, retro coding style

Click here to view the embedded video.

From watching the video you will no doubt have realised a few things that inhibit gameplay – everything feels a bit ‘stiff’, there’s no sense of motion from the enemy ships and they’re impossible to hit. Oh, and you can’t see them. And this is all stuff I can work on now that I’m not spending hours trying to learn advanced maths.

The next thing to work on is how to represent waves of enemies and control when they appear.

In my universe the apple would have fallen through the earth, then shot off into space...

Where the laws of physics are optional and not quite as they should be. If you’ve ever heard people talking about physics simulations “exploding” and wondered what it looks like when that happens, watch the first video If you want to see what a physics simulation written by someone who has a clue looks like, go watch the second.

I had a simple looking item on my TODO list – “Collisions between terrain and ship”. It seemed fairly straight forward if I pretend the terrain is a box, rather than a lumpy collection of triangles. Just make sure the player can’t go outside a suitable sized bounding box. And if this was 2D it would be quite simple, but it’s 3D so it’s a bit less simple… and god help you if you put “3D collision detection” into Google – you’ll be off researching  RK4 integrators before breakfast.

It’s possible to fake a fair amount of this using the good old ‘position += velocity’ type stuff, but once you try to make things collide (or rather, make things be solid) – and more importantly work out what to do when things have collided it gets kind of complex very quickly.

So, after a few hours buggering about with dot products, vectors and graph paper I did what any mathematically challenged coder does – starts looking for code to ‘borrow’. There’s tons, and once you ignore everyone who says “use Unity” and the few misguided people who say “Use Cocos2d” (yeah, people can’t read and interpret things…) you find Bullet Physics which if you do some digging isn’t so hard to bolt onto an XCode 4 project.

Click here to view the embedded video.

I think, by adding an entire physics and collision resolution system into my code, that I’ve gained a load of stuff for free. Tomorrow I’m going to strip out all my hand made physics code and thoughtfully mesh Bullet in there instead. Maybe by the end of tomorrow I’ll get things moving and bouncing off each other, or maybe I’ll unpick another thread that leads me on a merry path of learning (these things start off as simple enough sounding questions. I’m sure this learning curve is fractal…).

Click here to view the embedded video.

I managed this by following a quick copy-and-paste ‘Hello World’ tutorial and a bit of guess-the-method-using-intellisense coding (type a class, press ‘.’, choose a likely looking method, Google its documentation, have a go). It’s a bit rough but it works and the ship doesn’t escape.

I did this last year, and it might be fun to review what I wrote… So let’s see, I ended last year’s post with this

So, by this time next year I’ll be happy if I’ve created at least one complete game of some description. I don’t even care if it’s just Pong with a computer opponent you can’t beat. Let’s set the bar nice and low to start with.

And if you go over to iTunes you’ll see I did indeed manage to create a game called Ship Goes Up It took me a number of months and was somewhat fiddly. Some people that bought it even commented that it was quite fun to play. I think that constitutes success. I also managed to help out a friend with an Android game called Retro Blitz that he’d wanted to put on the App Store (it was created using some cross-platform tool so converting it to an iOS app was as difficult as compiling the supplied XCode project, tarring it with the App Store glue and waiting for Apple to do their thing).

In other news I received a BBC Micro for Christmas along with a Fignition AVR-based computer. The BBC Micro needs me to buy an SD card reader for it, and the Fignition needs me to learn Forth. I have ideas to type out some of the simple “games” from several 80s computer books that I own. It might make a nice diversion from the other thing I spent this year doing…

If you’ve read this blog recently you’ll have seen several videos of me slowly getting to grips with ‘Real’ OpenGL ES 2.0. Real, full-fat OpenGL ES, complete with me having to learn basic linear algebra and other highly confusing concepts. All I can say is that learning something confusing like what a ‘ModelViewMatrix’ is takes more than an afternoon of playing in OpenGL. Learning all this stuff seemed to follow the pattern of me reading a book or blog entry about it, getting confused, reading several others, asking some questions, fiddling around for a week or so, then re-reading the books and blogs while thinking “oh right, that now makes sense!”. I can’t learn the stuff without reading the books first, and I can’t make sense of the books without fiddling with the examples.

Go and learn proper 3D maths now, it’s really hard

So, in the name of progress I want to achieve two things next year

1. Make a fun 3D game that people play for more than 30 seconds
2. Have it sell more than 10 copies

so that it’s worth me renewing my iOS dev license in August. I mean, £59 isn’t so bad – it’s more fun than spending the equivalent on an XBox Live Gold account or shovelling money into WoW or Rift (and I can’t play those games anyway, I don’t see a level 50 warrior elf running through the forest, I see a scenegraph apply matrix transformations to a 3D mesh while the entire world is translated down the Z axis).

Many things are cool, like this screenshot of XCode for example…

The 'Capture OpenGL ES Frame' view in XCode 4

this is what happens when debugging iOS apps that use OpenGL, there’s a handy button to click that lets you poke around in the OpenGL ES state. It shows running GLSL programs and the state of the buffers. Quite useful when you’re confronted with a black screen.

Anyway, that’s not what a scene graph is, I’m not even sure if what I constructed is really a scene graph either. I do know it’s a really handy concept that has made structuring my 3D code so much simpler. I always had the problem of how to put a 3D object in the game world at one position, and then have something like a ‘drone’ ship orbit that object, or make ‘bullets’ shoot out of the ship. Or something simple sounding like have a camera that follows an object (this is not simple BTW, it effectively involves undoing all the transforms made to your scene so that the bit the ‘camera’ looks at is positioned at 0,0,0. The maths is horrid but this thread explains matrix inversions well enough).

Click here to view the embedded video.

What I created was a simple tree structure that holds the relationships between game entities. Each Entity object has a list of pointers to child Entity objects and so on. This is just an STL vector of pointers to ‘Entity’ objects. There’s an update function that recursively goes down the tree calculating the ModelView matrix of each entity based on the ModelView matrix of its parent. Recursion is cool like that, if you’ve got a tree you need recursion it makes calculating things very easy.

However, traversing a deeply nested tree isn’t so useful if I want to find a specific entity (like the player ship because the user just poked the screen), so rather than the tree being a container for all the entities it merely defines relationships between entities. The entities themselves live in a bog standard array that I can quickly loop through pulling out things to draw on the screen, etc. Making an Entity first involves finding a free slot in the master Entity array, then adding its pointer to a suitable parent Entity.

Oh in the demo video ignore the missing right-hand edge of the canyon, I was testing out different camera angles. One day I’ll work out how to smoothly move the camera from one angle to another to do fly-bys and different game modes. I’ll probably work that out on the same day I make the enemy ships fly by themselves since it’s the same thing

Next thing – multi touch so there can be steering of the ship and shooting. I got rid of the tilt controls, they were annoying me (mostly because the light in my room was reflecting off the screen!).

It's getting a bit nippy out

There has been progress on my “fly endlessly down some sort of canyon” iPad thing. Quite a lot of this progress has been non-visual infrastructure code where I’ve taken hastily hacked test code and rewritten it in a more reusable and thoughtful manner. The main visual changes are that we’re now flying over ice and snow after I watched the BBC’s Frozen Planet series and decided the bit where we fly down a canyon carved out of the Arctic ice sheets looked kind of cool. It’s also winter and getting a bit cold outside.

I’ve also got some basic tilt controls working so that the ship moves left and right depending on how you tip the device. Tapping the screen makes the ship rise and fall. I need to adjust this as everything is a bit slow and smooth but for now it’ll be enough to let me try the next thing on my todo list. There’s a video to watch below.

Click here to view the embedded video.

So what’s next? Maybe a few nights spent playing with Milkshape3D drawing low polygon ships to shoot at. I can do quite a lot of gamey stuff if there’s some opponents, rather than plugging away at invisible infrastructure code – I wrote some linar algebra to generate an orthographic view for the HUD (that’s the thing saying ‘Yo’ on the screen) and worked out how to have two different shader programs running. All that effort to make a small square appear on the screen. And lots of effort working out how to make this automatically scale to different screen sizes, which works rather well and means an iPhone version just “plops” out the compiler with no effort.

It takes hours to make that stuff work, but since it doesn’t produce anything worth looking at I’ve not bothered writing about it! I really need to work out some sort of tripod arrangement for my iPhone so I can record videos better, one-handed iPad waving while holding a phone doesn’t work very well.

Uh oh... someone's deleted one of my standard C++ headers?!

If you use XCode and have to deal with C++, Objective-C and Objective-C++ you might one day come across utterly mind-bending compiler errors that seem to defy logic. Weird things like header files not being found, or GCC somehow forgetting what the keyword ‘class’ or ‘template’ means.

And it can take hours of head-banging to work out the cause. So here’s a hint…

Make sure XCode thinks your source is the correct type. Is it compiling your crazy mix of C++ and Objective-C as Objective-C++, or has it got in a mess and is trying to compile it as Objective-C?

This can happen quite innocently if you hand create an Objective-C++ source file and name it foo.m instead of foo.mm. Especially since nothing bad will happen until you try to #include something that somewhere eventually #includes some C++. So you might have a load of Obj-C that through a chain of #includes/#imports eventually tries to use some C++. And then it’ll all go wrong.

The compiler doesn't seem know what the 'template' keyword means?!

You’ll know it’s gone wrong when illogical things happen. Things like a file that used to work fine suddenly no longer compiles, even though you’ve not altered anything inside it (all you did was #include it).

Time to find bug – ten minutes. Time to fix bug – less than a second.

Coming next… how to find the location of those bizarre backward_warning.h #warnings.