Height Maps

Greetings and salutations my friends, I hope you're well! I am in a specially good mood today as I have recently implemented a new feature in my game, and it actually looks cool!

Over the last few days I have been working on a cool way of creating a background for my tower defence game. When speaking with my project supervisor Simon, he mentioned it might be a good idea to create a height map which can be used to render a terrain.

First off, a height map is a way of procedurally generating a graphical scene. The height map itself is basically a grey-scale image (think of clouds) which acts as data that you want your program to get hold of. In order to get hold of the data, you go through the image, taking each pixel in turn, finding the intensity (level of white/black) in each one. The values of each pixel correspond to the heights of your vertices when you go to draw your scene. So white would be the highest point, and black would be the lowest, with all the greys somewhere in between. As you draw your vertices, you go through the list of pixel data and set the height to the corresponding value (you can of course scale this afterwards if you want).

This all sounds perfectly simple and straightforward, and I guess it is compared to some problems you'll face, but as I have come to learn, things are never as simple as they first seem. The first problem I had was getting hold of the actual pixel information itself. I am using SDL to load my images, and while the SDL_Surface object is great, it is not at first blindingly obvious how to get hold of each pixel. Realising I wasn't going to get that working first, I decided to get the drawing code working, and then work out what the height values would be after. Here is what I got first try...

Looks bad I know, instead of finding the height values from the height map image, I randomly set the values between 0 and 100 for each vertex; this was the result. Green probably wasn't the best choice either. At least I knew something was drawing which was a start. I then went about getting the pixel information to work, and I solved it with this little method:

get_pixel(SDL_Surface *surface, int x, int y)
{
Uint8* p = (Uint8*)surface->pixels + 3 * (y * surface->w + x);
return *( Uint16* )p;
}

Here you pass in your SDL_surface that corresponds to the image you have loaded, and the x and y values of the pixel you want to find (the coordinates of the pixel), you next store the pixel information in a pointer to an integer, (the pixel value is stored as an int) and then return it.

Once you have all those values (stored helpfully in a two dimensional array) you simply have to put them into the appropriate place in your drawing code, (which I had finally figured out after several hours of research and bouts of trial and error). I finally got something that looked like this, based on the height map below.

I was skipping and dancing around after I first got this to work. There was no lighting, I was just incrementally increasing the colour from dark to light in each triangle I drew. I then went about getting the lighting code to work, and finally ended up with this:

Success at last! I understand it does kind of obscure the playing area but you get the idea! I have to thank www.videotutorialsrock.com for a lot of information on height maps and techniques on how to create such an effect, I will hopefully be able to move it out of the way of the grid soon too!

Tower Defence ideas and a bit of code

Recently in my tower defence game I decided it would be cool to allow opposing players to place bombs over one another's towers in order to destroy them for a certain amount of resources. My thinking was that this would introduce an extra element to the gameplay where by a player has to balance their resources to afford new towers to fend off the enemies, as well as also trying to destroy their friends towers to make life harder for them.

I wanted to implement the bombs so you could have as many as you wanted at a time, so as I have done with my enemies and my towers I created a good old c++ vector (a smart array, or simply a form of container for my data) that could then be iterated through to update them.

I ran into a bit of a problem when I wanted to remove a tower and a bomb after the bomb had blown up the tower. I needed to know if the bomb I was on as I cycled through the list matched the tower, and therefore knew which tower and bomb to remove.

Here is the code I am using, you probably won't understand it, and it probably isn't the most elegant way of doing it, but by joe it works!


void CGameController::Update_Bombs( CTimer* timer )
{
for( unsigned int i = 0; i < _bombs.size(); ++i )
{
_bombs.at(i)->Update( timer );

if(_bombs.at(i)->get_exploded())
{
         for( int j = 0; j < _towers.size(); ++j )
{
if( _bombs.at(i)->get_i() ==
                            _towers.at(j)->get_index_i() &&
    _bombs.at(i)->get_j() ==
                            _towers.at(j)->get_index_j() )
{
_grid->set_occupied( _towers.at(j)->get_index_i(),
                                 _towers.at(j)->get_index_j(), false);

         _towers.at(j) = _towers.back();
_towers.pop_back();

_bombs.at(i) = _bombs.back();
_bombs.pop_back();

break;

}
}
}
}
}

Basically what I am doing is iterating through all my bombs, I update each one in turn, and check if it has exploded. If it has indeed exploded, I then cycle through all my towers, and then do a comparison with the grid square of the tower and the bomb, to make sure they match, and then I remove both of them. It works perfectly, but only with the help of my friend 'break;'.

Without that helpful command, if the first bomb in the bomb list was matched with a tower halfway through the tower list, and the bomb was then removed, the tower list would keep iterating through, and would try and compare itself with a bomb that no longer existed! Not good! I got a horrible run time error, and panicked quite a lot, but then remembered I was missing a 'break;' and then suddenly all was lovely again.

If you can think or a far cleverer way of accomplishing what I am trying to do I would love to hear it, no doubt I am sure there is, but I am just glad it works, well mostly.

Tower Defence Update

Firstly let me apologise for my lack of updates, I have been pretty swamped thinking about my project and working on my code lately. I kept coming to write an update but didn't feel like I had anything particularly great to talk about so I decided against it.

I thought now was as good a time as any as I feel as though I am finally making some head way on my project. I now have a game that two people can actually play in competition with one another. That might not sound like much, but now the game can actually be played I can start thinking about balancing all the variables I have carefully crafted into the game. Things such as wave speed and number, tower fire rate and damage, and resource costs can start being honed so as to create a well balanced and enjoyable experience. There is also the matter of polish with regard to the user interface and graphics that will go some way to increasing the visual appeal of the game itself.

I will try and post some screen shots of what I have soon so you can have a look at it, hopefully it will change more and more in the coming weeks and months.

Problem Solving

Problem solving is something we humans do all the time. Each day we are confronted with problems ranging from getting your car to start in the morning, to making your way to two parties each taking place on the same night (good luck with that one).

Programming relies on ones ability to solve problems so heavily that the P in programming really should stand for problem, and perhaps the R for resolve (No S's in programming for solve, maybe 'programmers'... I'll keep thinking). If you look at literally any job listing for a programmer, one of the bullet points in which they list the skills required for the job, will most likely be 'Problem Solving'. I remember first seeing such a listing, and thinking what on earth they really meant. I knew I could solve problems (much like the ones listed before, well maybe not the two parties one) but what did it mean with regard to programming. Surely you could just write a program and it would work, you'd have a problem, which would be solved by creating the software itself; for example making a checking system for a hotel would solve their booking system problem. Actually making the program itself is the easy part, right?

Looking back I feel foolish for ever thinking such a thing. You see the problem with programming is that even if you have the perfect design, the greatest architecture in the world, and sharper programming skills than my comedic wit (ahaa...) you will always find yourself hitting road blocks and quandaries that cannot be solved by your initial design. Enter Problem Solving.

To be a good programmer you have to be able to think on your feet. If something suddenly doesn't work as you'd expect, or you realise the thing you are working on just won't work at all. Do not throw your hands up crying 'It's impossible, it can't be done, I am going to drink more coffee'. Instead what you must do is analyse the problem itself, and then think of every possible solution you can. The easy part of problem solving is thinking of great solutions, the hard part is then deciding which is the best or the most appropriate given the time and complexity involved, and then thinking how exactly you implement such a solution. As you program more you will begin to build a tool box of tricks to help you when you reach such problems (which will be often and always) but the most important skills I've found have won out, are patience, persistence, and a willingness to admit you may have been wrong.

The thing you realise the more you program is there is never one solution, you have to pick the best one you can, and when you realise it doesn't work, you have to make it work, by adapting or evolving the original solution. This ranges from lofty design ideas, to small implementation details; they both require the same set of skills to handle correctly.

I would like to tell you it gets easier, but that would probably be a lie. The more complex software you work on, the more intricate the problems, and the harder the solutions. Let me tell you though, when you solve the problem that has been taunting you for the last two hours/days/weeks, and you experience that moment when you hit run, and everything works.... my friend, nothing comes close to that in the world.

A Poem

On occasions/often (delete as appropriate) while you code you will come face to face with problems that seem insurmountable. There seems as though there is nothing you can do, everything is going wrong, and you can't face your monitor.

For when this happens, read this poem, and it might bring a smile to your face and give you the motivation to tackle the problem head on, and just maybe, prove yourself wrong, and do it.

Somebody said that it couldn’t be done,
    But, he with a chuckle replied
That "maybe it couldn’t," but he would be one
    Who wouldn’t say so till he’d tried.
So he buckled right in with the trace of a grin
    On his face. If he worried he hid it.
He started to sing as he tackled the thing
    That couldn’t be done, and he did it.

Somebody scoffed: "Oh, you’ll never do that;
    At least no one has done it";
But he took off his coat and he took off his hat,
    And the first thing we knew he’d begun it.
With a lift of his chin and a bit of a grin,
    Without any doubting or quiddit,
He started to sing as he tackled the thing
    That couldn’t be done, and he did it.

There are thousands to tell you it cannot be done,
    There are thousands to prophesy failure;
There are thousands to point out to you one by one,
    The dangers that wait to assail you.
But just buckle it in with a bit of a grin,
    Just take off your coat and go to it;
Just start to sing as you tackle the thing
    That "couldn’t be done," and you’ll do it.

                                                by Edgar Albert Guest

I am going to frame this and have it next to me for all those moments when it seems like it can't be done, when in fact it can.

Over-Engineering

Recently I have been thinking a lot about software design and software engineering. The importance of software design, as I have stressed before, is paramount in ensuring your code doesn't fall apart the moment you start trying to piece it together. The problem with programming however is there are nearly always 20 (or more) ways of solving a particular problem. Often some will be preferable to others, but nearly always you have to make some kind of compromise, and pick the lesser of two evils. There never really is a perfect solution, only the best one you can think of at the time, and there will no doubt be a helpful colleague to come and poke their nose in and tell you exactly how they would have done it instead.

Now when you come to design and implement a certain set of functionality, you are presented with a choice of possible ways with which to handle creating it. I have found there are two main approaches to this. The first is to think of a very rough idea of what you want, attempt to scribble some notes (doodles) in the form of some (very) basic design, and start coding. You are basically trying to achieve the functionality you want as quickly as possible, with little to no concern for who else will need to look at, or reuse your code. The other way, is to create an impeccable design, with a multitude of classes and interfaces that allow an array of functionality you might not even need yet, but you are planning for every eventuality, and for the system to be used over and over again.

Now I am pretty sure which one you think is better, and you'd probably be right. The latter sounds like what a proper software engineer would do, and this is probably true, but that approach might not always be the best or most appropriate solution. This approach is probably a good way to go if you are a professional, seasoned programmer, but for guys starting out, this approach can be completely overwhelming. There are so many levels of abstraction, and so many possible things to worry about, that it all ends up looking and sounding too much to take in and maintain.

What you want is the base functionality to work, and to be able to see it working. This is the best way to learn in my opinion and once you have these fundamentals in place you can start building a better design around them. There may be times when even professional developers take the quick fire approach, if it is a system that is small, and won't be used much, why make an over-engineered solution when you could code something up quickly, and then get on with more pressing tasks.

I am sure not everyone will agree with me, but it often feels like you need to walk before you can run, and there is no way you will create a flawless design without understanding the quick way of doing it first.

I love Visual Studio

I got this error today, I had never noticed it before but it made me smile. Studio can be so helpful at times... at others it can make you want to cave your own head in, this is one of the former.