Game Design, Programming and running a one-man games business…

Category: programming

You wouldn’t start from here

Posted on April 19, 2011

So many programming, and technical things are bodged, not just in games or software, but everywhere, because the ideal best-case academic method is totally useless given that we are always working from an imperfect base.

The railway network, telephone infrastructure, road network, sewers and god-knows-what-else here in England are all rubbish. Why? Because we got these things very early in history due to being economically and technologically quite advanced, esp during victorian times. As a result, as pioneers, we have what I guess is ‘first-mover disadvantage’. Our countries infrastructure is like excite vs today’s google :D

I definitely find this problem in my own code, my own methods of working etc. I have an engine, it doesn’t really have a name, the folder is called ‘Positech Engine’. I save my imagination for the actual game… The engine isn’t like the unreal engine or other fully-featured thing, but it has all my library code which handles stuff like directinput, rendering, vertex buffer and texture management, file loading and so on. Bizzarely, 90% of the my UI code is NOT in the library, I copy it to each new game. How sucky.

Not only that, but I have a bunch of long standing balls-ups that I am now stuck with, pending a major rewrite for the next game. I should have done them for this one, really… Here are the ones that spring to mind.

STRINGS: I can’t decide if I like char* buffers or std::string. I pretty much use std::string, but because historically I know functions like sprintf and strcpy really well, I still use them in places. As a result some of my library stuff is designed to accept either std::string or char* as input. I can type ‘.c_str()’ so fast now it’s scary

UNICODE: I don’t use unicode. This means a Japanese GSB is not going to happen any time soon. I should probably use unicode, but I don’t

TOOLTIPS: I know this seems minor, but my tooltip class isn’t integrated with my window class. This means if I create a new window, and it needs a tooltip, I need to add a tooltip object, and call a destructor, and make it respond to the mouse and get drawn. This sucks. I should have defaulted to all windows having tooltip functionality

BUTTONS: Buttons should be a subset of windows, but mine aren’t. Both windows and buttons at least derive from the same class, but a window thus now derives from a buttonlist. That means a window has a list of buttons, and a list of child windows, and they are handled seperately. THIS SUCKS.

I know this all sounds crap, and if you are a coder writing a new engine, or a student, it sounds like I’m a n00b, but the thing is, you wouldn’t start from here. Unfortunately I have, and re-using my existing engine saves me hundreds if not thousands of hours for each game, so it’s tough to make a business case for changing a lot of this. Both big studios I worked on had code that was at least as messy as this, so I know it’s not just me…

Next game I’ll fix it all, sure…   maybe…

Work For Idle Hands

Posted on April 11, 2011

One thing GSB does that I’m quite proud of, is run an ‘idle manager’ to smooth out the frame rate. In concept, it’s pretty simple. There are some jobs that need doing in the near future, but not *NOW*, and some that are optional. The idle manager works out that we have some spare time, and does them accordingly. In code terms it’s a lot more involved.

GSB has a target frame rate, and checks the time since last frame in the main game loop. If there is some ‘spare’ time before the next frame, it tells the idlemanager, and checks again once the idlemanager has finished. The idle manager has a list of tasks, and it cycles through them in turn. Two of the common tasks are these:

1) Check that we aren’t running low on any pre-cached particle effects, and if we are, pre-cache some new ones ready for future use

2) Check if any laser blasts which are missing their target happen to intersect with some debris. If they do, make the debris explode.

task 1) is vital for performance, task 2) is optional graphical fluff.

The implementation of an idle manager is cool because it allows you to use the fluctuating rendering-demands per frame to your advantage. It also means you eek as much usage as possible out of a single processor core. In multi-core, multi-threaded systems, this is all done much better by having a separate thread, which can spin off and do this stuff at your leisure. There can be synchronisation issues in that case though (I don’t want to change the list of cached particles while another thread is altering them too etc).

If you can’t be bothered with the hassle of multithreading, I recommend implementing something like this idle manager at the very least, assuming performance is vaguely an issue for you. I’m writing the idle code for my new game right now, and it will be a bit cleverer, and more involevd and possibly multithread stuff too. I hate to think the game would drop a frame when it could be avoided by doing this sort of stuff.

Revisiting the tile based game

Posted on March 18, 2011

My next game has a tile-based system behind it. Gratuitous Space Battles didn’t have tiles because if it did, all of them would be “tile 1: space“, which is kinda dull.

Tile-based games are typically associated with very old school RPGs and with early top-down very basic RTS games. Generally, these games seemed to have a set number of tiles (a ’tileset’) and the tiles would be of  fixed size. The tile size was small, to enable sensible pathfinding, but this would make the terrain look very obviously gridlike, with tiles repeating and the largest terrain objects being tiny.

Tech has moved on, and we can afford to have big textures now, but the problem is that a system that uses the tiles for non-visual stuff (pathfinding, AI, terrain etc) still probably needs fairly small tiles. For a while, I was struggling with small tiles and coder art, but the first few bits of proper art have forced me to reassess how I was doing things.

It’s all coded now, and the solution was to basically have two overlapped tile systems. Effectively, the game grid works on smallish tiles, and the visual tiles that have textures applied to them are four times the size. This is completely transparent to the gamer, but it does make for a slightly strange ‘change edit mode’ button in the game editor, and some slightly messy code. Eventually, the system I plucked for just uses the smaller tiles, in the game engine and the editor cunningly lets you apply the larger ones, and transparently splits them into 4 and applies them to the smaller ones for you.

It was a bit of a pain to code, but worth doing. One day I’ll have screenshots to show!

Explosion Design

Posted on February 15, 2011

I’ve spent another whole day working on particle /explosion stuff and tools. I was very pleased with the explosions in GSB. They look like this:

But much better in motion. I think that’s not bad. However, just because I think it’s not bad doesn’t mean it can’t be a factor of ten better. I’m aiming for ILM-standards, so there is a huge way to go.

GSB had a particle editor, but it wasn’t as good as it should be, mainly because it was built as an external program, and a crap one. I am notorious for making rubbish tools. I should just ask Eskil to make them. Anyway…

Here is the very first attempt at the explosion / particle editor for LB. It’s not vaguely finished, not even by 50%, and I really need to support zooming in! Anyway, the main thing is that it’s built into the game, which means a lot less hassle to edit effects and then toggle back into the game and see how it looks. Plus it uses the exact same source files as the in-game effects, so it’s less messy.

To be honest 90% of the effort was a re-jig of the class structures for a lot of my particle code, rather than actual tools production. Obviously all the GUI code there and the graphics are from GSB, don’t worry, I’ll get a brand spanking new GUI design for the new game in time.

I’m determined to finally make a game that has decent tools from the start, to make me more productive.

In other news, I was woken at 3AM by the death screams of what sounded like an injured pterodactyl in the garden. It *might* have been some less exotic bird, but I’m not so sure. Glad I hadn’t just watched some creepy horror movie.

Going from BASIC to C++, in understanding game source code

Posted on February 1, 2011

I was chatting to someone about a year ago, who was embarking, for research purposes, on how to code a game in C++. They were familiar with the rudimentary concepts of coding, and with games, but had never looked at C++ before, or the source to any modern game. They had enormous problems going from the programming they leanred briefly as a kid which was this:

10 PRINT "I AM L33T!"
20 GOTO 10

And modern game source code. The main difference is that a C++ game is ‘object-oriented’ and the languages people start with are just simple lists of instructions, executed in order. This is a 30 second guide to helping newbie coders cope with the difference. The biggest problem you have, is the question “Yes but where does the code actually START?”. And the answer is, a function called WinMain. Basically, the structure of any game is this:

WinMain()
{
Create A Window();
InitialiseGameStuff()
while(true)
{
CheckGameNotQuit()
GameLoop()
}
}

That’s basically, Kudos, Democracy, Starship Tycoon, GSB… etc. It’s all there. that is the whole game. The real stuff happens inside GameLoop(). That is basically this:

GameLoop()
{
BeginFrame()
DoAIStuff()
DrawStuff()
EndFrame()
}

And that obviously splits out into a billion other functions. Now already, it might look scarily nothing like 10 PRINT SCREEN, but just imagine that GameLoop() is a GOTO that jumps to the start of GameLoop() and imagine a RETURN statement at the end of that section. The weird bit, for new coders, is that the code will jump back and forth all over the place, between different source files, in different orders, up and down and all over like a ping pong ball, but, ultimately, when the chips are down, it’s not really *that* different from old BASIC programs. Until you multithread it, anyway :D.