Cities in the Sky

Yep, that’s right, I’m writing blog posts on consecutive days now. Whatever next; Twitter?

Anyway, I’ve tapped on my keyboard a bit more and have now gotten rid of those pesky Piece and Debris classes once and for all, and fixed up some bugs that have crept in during my purging. Pieces are now defined by their behaviour components, which take their parameters from good old objects.xml. To show off how fantabulous this is, I went and added raise pieces in the shapes of crosses, lines and blocks, and had them hooked into the game in probably under a minute.

Eye candy is always nice, so here’s a screenshot of the CITS after a couple of minutes of play:

I’ve done a wee bit more work; the Person class is now completely gone and replaced by GameObjects with PersonBehaviourComponents. Also Building, and its subclasses SmallHouse, LargeHouse and RaisableHouse are gone, replaced by GameObjects with NormalBuildingBehaviourComponents and RaisableBuildingBehaviourComponents. What this means to me is squeaky clean code and the right to lord it up over other programmers, and what it means for you is that I can now edit my objects.xml file to have a “Lighthouse”, “Observatory”, “Sheep Factory” and so on without having to go through lots of copying and pasting (and subsequent maintaining) of lots of C++ code. Hurrah!

I actually removed Person a little while ago, but I didn’t think you’d be particularly interested. Not that removing Building and friends is any more interesting to you but it was quite significant to me! That, and Rich told me to write another post. Is this satisfactory, o great blog critic?

One of the things I’ve been doing recently is transitioning from an inheritance-based to a component-based game object system. I started the project with full knowledge that component-based game object systems are better, but intentionally didn’t implement one since I thought it would be unnecessary for such a small game. It turns out that I was wrong, and since it’s something I’m very interested in and have thought about a lot, and since something similar was going on at work, I thought I’d give it a go.

Originally I had specific classes (Building, SmallHouse, Person) that handle everything about themselves (like graphics, physics, game logic) and do all their processing in a big ‘update’ method. I’ve factored out and moved around this code through several stages, keeping it building and running along the way, as it’s dangerous to just rip it out and start again. Now I’m at a stage where these classes have been replaced by a GameObject class, which owns a collection of Components, whose subclasses like PhysicsComponent and GraphicsComponent are registered with and updated by PhysicsSystem and GraphicsSystem respectively. GameObjects can be created by name from a GameObjectFactory, and object types can be created and registered at runtime, or from an XML file. So I now have an ‘objects.xml’ file that looks a bit like this:

What a difference! If you aren’t impressed by that, you’re either not a programmer, or you’re a programmer in a field a bit less backwards than video games.

Now, I told a bit of a fib; actually the only class I’ve completely removed is ‘Debris’, since changing everything at once would have involved a lot of copying and pasting, as a lot of the intermediate steps were actually quite ugly and verbose. But now that I’ve proven the system works for Debris, I can get rid of all the other ‘game object’ classes. Then the only C++ code I write for game objects will be for their game logic, if that can’t be reused from existing components.

As such, the visible results you can expect from this are a variety of interesting new buildings some time soonish!

Just a small update this time; I noticed the lighting was a bit odd in that the surface of the island seemed to be shaded uniformly and the underside was a bit too light, so I tweaked that.

Also I noticed looking at the past few screenshots that the island is the same each time, when it’s meant to be random! That’s a shame since I spent quite a while making a nice island generator. So I reinstated that code and now it’s generating random islands again every time.

You may also have noticed that I’m now using Flickr to host screenshots (well done you). I chose Flickr because Picasa seems to reduce the quality of its thumbnails massively, which is really annoying and makes CITS look even worse than it should do. Also Flickr’s image previews happen to be exactly the same width as the text on this page which pleases me

Still, one tiny update in over a month? I’d be a bit miffed if I were you. Trust me though, I’ve been doing all sorts of other interesting things (that don’t deserve screenshots) which I’ll post about very soon!

As I said in my last post, the next thing I wanted to get done was to fix up the physics on the raisable buildings by rejiggling the code for the Building class. I’ve now added ‘Debris’ which is spawned by each ‘Building’ when it decides it’s time to fall off the island. Currently all the buildings just spawn a piece of debris that looks exactly like the building itself, though in the raisable building’s case this means one piece per floor. Since the physics can be a tad unstable at times, this can result in interesting-looking explosions such as that pictured in this screenshot!

You may also notice there are some bright orange buildings there. If you don’t notice them you’re not looking very hard. They’re just replacements I made for the ‘tudor house’ mesh that I borrowed from Ogre right at the start of this project – it was unnecessarily highly detailed, a bit ugly, and not mine. These new buildings have only one of those problems.

I also replaced the graphics of the people – they’re now little chaps made out of several cuboids (what an evolutionary leap!). They’re even textured! You can’t see it from the screenshot, but they each have a smiley happy face. They’re blissfully unaware that if ‘trippedOver’ ever returns true, they’ll be launched upwards with ‘10′ force, which although unitless is definitely quite deadly, and comical.

Next I’m going to do a bit more rejiggling (‘refactoring’ is a term many programmers use inappropriately, so it’s sort of lost its meaning. ‘Rejiggling’ is a good replacement I think), since there are a few bits of code that are being duplicated every time I add a new type of object. After that I’ll be adding some ’special’ buildings and updating the game logic a bit, which will be fun That will probably have to wait until after Easter though, since I’m off to France with my girlfriend for a bit first!

Tonight I added those raisable buildings I was talking about. This involved a lot more work than you’d think! Mostly this was because it’s quite a radical change from the way things are done currently. Each building is made up of several meshes now – a ground floor, a roof, and several middle floors, whereas before there was the assumption that there was a 1:1:1 mapping between building, physics object and mesh.

You may also notice that I’ve thrown some random rotations of buildings into the mix. This pretty much came for free when I was adding in all the other stuff, so I’m happy since it makes things look a whole load more interesting! Similarly, it’ll now be easy for me to add things like stilts/foundations to make sure buildings don’t hover like they can now, or to add scaffolding temporarily just after construction, or to change the appearance of buildings entirely (make them more futuristic as the game progresses or the buildings are developed enough). All graphical niceties that I’ll get to in time!

Unfortunately I’ve broken the physics on those buildings since they can no longer just take their position and orientation from their physics component (otherwise the whole building would be at ground floor level), but I haven’t bothered to fix this since that’s next on my list of things to revamp. I’ll make buildings spawn ‘building chunk’ objects when they collapse, which will improve things in many ways – the Building class will then have one responsibility rather than two (it currently has states for ‘free’ and ‘attached’, the ‘controlled’ state being lost when I factored that out into the ‘Piece’ class), there will be the possibility for multiple building chunks with different graphics to that of the building they came from (proper bits of rubble!), and the Building object will need physics only for collision detection and not to physically attach it to the island.

Hah, I bet you didn’t think I’d wait this long before posting those interesting things, did you? Did you?

What I’ve done is had a good ol’ rethink of the way the gameplay is going to work. Up until now, the idea has been that individual buildings fall from the sky and get attached to the island when they hit it. If you build on top of an old building, you destroy both the old and the new. Your score was going to be decided on a measure of each building’s quality (depending on where on the island it was placed, and which other buildings were around and so on), multiplied by the number of people, to get a rough measure of the total ‘happiness’ of your population.

The problem with this is that you’d quickly run out of space and end up being forced to destroy all your old buildings. There would come a time when your island is full, and your task would change from building a nice city to coaxing the physics system into not wrecking everything each time you place a building. Development would be linear, and capped, and I don’t think that would be very fun.

I went through a few more ideas after this, and after some discussions with the guys at work (that means you Rich!) and an old university chum (that means you Mike!), I’ve come up with something that plays well in my head, which I intend to try out. It’s just a few changes to the old idea, but I think they add up to something quite fun.

Instead of dropping actual buildings, you now drop pieces which can create buildings, or perform some other function. The main pieces will be ‘raise’ pieces, which will raise whichever buildings they hit (or create them if not present. These buildings will be your ordinary houses, and the idea will be to just have as many of these as high as you can make them. Of course the higher they are the less stable they are. The other main types of pieces will be the special pieces, which build buildings like docks, windmills, farms, mines and so on. These will generally have some criteria for where they can be built – docks at the edge, windmills up high, farms on flat ground – and will sometimes have gameplay effects other than their physical presence – mines will mine out a cavity inside the island gradually which will act as a negative weight, docks will attract merchants which will serve as other physics objects to get in the way.

Scoring remains cumulative over time, but instead of the previous sum of building scores times population, it will be a general ‘development’ score (which I see being a sum of ordinary buildings and their heights), affected by several multipliers relating to the special pieces. These multipliers will be things like ‘have 3 docks’, ‘have 3 windmills’, ‘have a really tall ordinary building’, and will be shown as greyed out icons next to the score when inactive, and lit up when active, probably with some crazy effects when several of them are acting together.

I’ve made a start, in that I’ve re-jiggled things to no longer drop buildings but to drop pieces, and I’ve added multi-part pieces (just an ‘L’ shaped raise piece at the moment), and added the base functionality for the raising mechanic (Note that you can also see the temporary Flash-based replacement for the in-game GUI in this screenshot!). In doing all this I’ve learnt some 3D modelling with Blender, which was different. Just today I figured out how to do UV editing and texturing, and exporting that information from Blender into a format that OGRE can use. All that must have appealed to my previously undiscovered inner artiste, since I then spent a few days learning to use my graphics tablet to do a spot of ‘digital painting’, but that’s a story for another day!

I started work on CITS again a couple of weeks ago, yet somehow it’s taken all that time just to get a couple of really very simple things done. All I wanted to do was to replace Simul Weather with a skybox of a Simul Weather sky, for debug builds, because it takes half a minute to load. So I went to the Ogre forums to ask how to go about saving a cubemap of the current scene out to file. I got no responses (thanks Ogre community!), so I made up my own way. Prepare for a rant.

I figured I’d just have the camera render to texture, then on a button press have it spin round to face each direction, update the texture and save it out. My first bit of fun was in tracking down a bug caused by Simul using the same string name for a texture as I did (moral of that story: don’t use string identifiers for bloody textures! What’s wrong with pointers or other unique handles?). Even so, once I’d sorted that, I found that it just didn’t work like that, and kept saving the currently rendered view.

So I thought I’d have six cameras each with their own render target, which I’d set off all at the same time. Except that did exactly the same thing.

So then I added in loads of calls to various Ogre update functions, to render extra frames in-between updating the camera and saving images. This worked to a certain extent, but gave very strange warped images for some directions, presumably because the Simul state depends on the previous frame and isn’t correct for sudden changes in viewing angle.

So then I thought I’d have twelve buttons mapped; six to get the current camera facing each direction, and six to save out the current view to each file, so I could allow the state to settle manually. Except that generated all sorts of weird twisting artifacts half the time, and the other half it’d make the clouds progressively blurrier each time I pressed a button to change the view.

So then I sat and tweaked values and mucked about with different ways of setting the camera’s direction, and eventually discovered that you could press the buttons in a certain order to get acceptable results, which finally worked. Sadly the sides of the cube don’t quite match up despite setting a FOV of 90 degrees and aspect ratio of 1, and the images are even more over-exposed than they appeared in-game (quite how I don’t know), but I was really quite bored of Ogre and Simul now and wanted to get on with something more fun.

Unfortunately in the process of all this I’d had to downgrade Ogre from SVN HEAD to the last stable release, 1.6, since I suspected it of being buggy, and it just wasn’t playing ball with CITS. It turned out that at some point there had been a switch from one memory manager to another, which required me to edit the Ogre source to change it back to the normal one. That was great fun, since changing something so fundamental requires a recompile, which takes a good hour or so.

Then OPAL went bad. Well, the code that converts an Ogre mesh to a format OPAL can understand went bad. I’d made some assumptions about the index buffer format Ogre uses, which were valid before 1.6, were valid after 1.6, but apparently weren’t valid at the instant 1.6 was released. That’s the fun I’ve been having this evening.

It’s finally done now though, and I can get on with some more important tasks!

There are a couple of other more interesting bits of news about the game, but they can wait for another update!

Well, I sorted out a new Simul license so the sky is back to normal (and so I can post screenshots again!). I’ve also done a load more work on the UI. It’s still not totally functional, but the high scores screen displays high scores and the in-game UI shows points and tilt like it did before, so I’m back to normal functionality at least. I also did some clever-but-not-really things like learning a bit of Actionscript, and scaling the Flash output based on viewport resolution.

The high scores screen you see is the result of several hours of tweaking and fiddling. I’m fed up with temporary graphics so I thought I’d try to create something a bit more permanent. It turns out I’m not so good at this though – it looks a little boring to me. It’s not abysmal, but it’s not good either. There’s a chap at work who’s marvellous when it comes to interface graphics, maybe I’ll ask him to sketch something up for me, so I can at least get a nice theme and colour scheme going.

I’ll probably improve the UI functionality next, though there’s another little side-project I’ve been dying to get my teeth into for the past few weeks, so we shall see… yes, we shall see…

I had a little time to play with Hikari, a UI library for Ogre that effectively wraps a Flash control and adds some C++ interoperability. This means that I can make a little Flash application and have it run in-game as the user interface, which is much more flexible, easy to modify and generally nice than the Ogre overlay system I’m using at the moment.

I’ve made a Flash file for the menu, in-game UI and high-scores table and they’re being displayed in-game instead of the ugly temporary overlay graphics I had before (that you never did and never will see!). They’re not functional yet since I haven’t really had the time to learn Flash, and the input code I wrote doesn’t keep track of cursor position yet which would make buttons useless. That’s next on the agenda though.

I shan’t give you a screenshot since I still haven’t sorted out a Simul Weather license, so everything looks very ugly!