pikuorguk

My code running a Lua script

Well, this is a bit fun! One of the main points of my game environment is that I should be able to easily modify entity behaviour without having to hard code anything into the environment itself. After a bit of thought, the programming language Lua seemed to be the best idea.

I was completely amazed at how easy it was to add this to my own software. After compiling it up, a surprisingly small amount of code is required to get the basics working. It was harder working out how to extract the Lua script from the zipfile I am using.

The screenshot illustrates a very simple Lua script that does nothing more than contain a function called “think” which looks like this

– Basic test
function think(xpos, ypos)

print (”xpos = ” .. xpos .. ” ypos = ” .. ypos)
x = xpos
y = ypos
return x, y
end

So it takes in two parameters, prints them out, then returns them back to the host C++ application. So my C++ application calls the function in Lua, that prints out the values it received, and then returns them. If you look in the debugger you can see it all works

Now to work out how to expose data and functions in the C++ application so that Lua can use them. I need things like “getPlayerPosition” and so on.

Originally published at Error_Success. Please leave any comments there.

For the curious I have spent the past week (off and on) making a pause button work. Yes, after a week of coding I have managed to allow the player to press the ‘P’ key and see a little “The game is paused, press P to unpause, Q to Quit” box appear on the screen. Not only that, but the player can then actually press ‘P’ again and go back to watching a black screen with a red triangle on it (the “game”), or press ‘Q’ and go back to the main menu.

Which makes it sound like I’ve done bugger all really. And that’s the problem with measuring progress by things you create and can actually demonstrate to other people. You see, what I really achieved this week is

Read the rest of this entry »

Originally published at Error_Success. Please leave any comments there.

I’m working away on my un-named project, which is starting to take shape nicely. When it’s eventually finished it’ll be some sort of game engine-thing for making 2D style sprite based games – shooters, platformers, and so on. I have no idea what to call it though – a framework seems to be something like XNA where you have a collection of classes and libraries that can be bolted together and compiled up to make a program. An engine seems to be something similar, or the part of a game you get when all the assets and levels are stripped out – imagine Doom without its WAD files.

Read the rest of this entry »

Originally published at Error_Success. Please leave any comments there.

sitting in a traffic jam. They’re not very mentally stimulating, the most interest being the insides of your nostrils and the car in front. So while slowly shuffling my way home today I had a think about the design of my game environment.

I’ve just finished making the engine parse the config part of the XML file. I can now describe using XML what resolution screen to have, whether the mouse or keyboard are required, and whether sound should be enabled. So what should take about five lines of code, now takes an XML parser, some classes and an external file. That’s progress for you

The next step is to get the basic environment loop working. I need to be able to open the screen and have standard things like “quit” work properly. If you just close an Allegro program it freezes and Windows pops up to kill it off, which isn’t any good. Especially when debugging, applications that fail to exit correctly make GDB do odd things.

So, back to the traffic jam, it was very interesting as I managed to get stuck in the middle of a busy junction with cars coming at me from all angles. There’s lots of roadworks and traffic lights in town, they’re all out of sequence with each other and much confusion. A bit like my code, and like my code, the new shopping centre will be built, roads widened and traffic lights resynced with each other. Or something, I don’t think my game environment will have a shopping centre in it. Order will come from the chaos though.

Computers were invented to remove the mindless repetitive work people used to do. There are certain parts of software development that are somewhat repetitive and ripe for automation. All that boilerplate code every project has, collision detection routines, menu systems, sprite manipulation. The whole lot can be automated away and scripted from outside the code. Less bugs. More effort to begin with, but less effort later on.

I think, I’m making this all up as I go along, going off what seems to make sense to me.

Originally published at Error_Success. Please leave any comments there.

It’s my opinion, probably because I’ve written lots of database-driven apps, that all software can be reduced to a simple set of data structures, relations between the data structures, and the operations on those data structures.

Take, for example, this blog. There is a database table with the posts in, and then some PHP to turn that into readable HTML. Without the database, the site is worthless. The PHP, while important exists solely to display the data.

The same probably works for games too. Game objects have attributes, it makes sense to store game objects in collections for ease of management – put all the baddies in a collection, put all the bullets in a collection, collision test the baddies collection against the player, but don’t collision test the player against their own bullets. Level data contains attributes that are modified for each level. These also need storing in some sort of collection. Enemy AI is merely a type of attribute for each enemy type, and even the actual AI code should just modify known states for each sprite – ‘find player’ ‘move to player’ ’shoot at player’ and so on.

Don’t forget the game’s menu system and title screens. They’re just more data – “Display splash.png for 3 seconds, or until mouse pressed” “Display main menu until option chosen”.

So, because it’s easier than trying to debug homebrew Nintendo DS code without a debugger, I’m in the process of making a game environment that accepts an XML control file to set the game up. It won’t be predesigned for any particular style of game, but it will be designed for 2D sprite-based games.

It’s my aim that by writing an XML control file, some enemy AI in a scripting language and drawing the artwork my environment can then render the game. The ultimate aim is to have a reusable game rendering environment that lets me create games of a certain style in a less error-prone way.

I have a sample XML file created already, and am now using the excellent TinyXML to parse this and turn it into a set of C++ classes. After that I will reuse the sprite management stuff from my DS coding and expose basic sprite functions – “move_x”, “move_y”, “explode” etc to see if I can make a simple game of some sort.

I’m re-using a lot of code that I’ve used before. I had a basic sprite and screen management system on my DS, which has been ported to Allegro/C++ and some of the code I did in Processing has been used too. I think I’ll stick with Allegro now, it not only has excellent documentation, but it also works and is complete and so simple to use.

Robustly parsing XML is possibly more tedious than writing SQL though.

Originally published at Error_Success. Please leave any comments there.

I spent some of today learning basic, but useful calculus. There are various bits of maths that never made sense to me, and which seemed really complicated. For example working out if two lines intersect each other. Previously whenever I tried to understand this the maths confused me, so this time I tried a different method.

The great thing about 2D geometry maths is that it can be drawn on a piece of graph paper. Finding out whether two lines cross on a piece of graph paper is fairly obvious, and the line lengths and so on can be measured with a ruler. It provides an excellent way of checking the accuracy of code. What I did was draw two intersecting lines on a piece of graph paper, work out the co-ordinates of the intersection, and then manually work through the equations I found on Paul Bourke’s excellent website. After ten minutes of computing I came out with an answer that was exactly the same as what I’d worked out on my graph.

I tried the same with a circle/line intersection test and that was equally accurate and successful.

Following on from this I created two test Processing applications just to make sure the code worked as I expected. They’re nothing too fancy, but they illustrate the point well. Test the code below:

• line/line intersection – click to set the points for the lines, the red dot shows where the intersection will be
• circle/line intersection – click to set the points for the line, then click to set the circle and its radius. Blue line shows the radius, green line is drawn from the centre of the circle towards the test line.

Originally published at Error_Success. Please leave any comments there.

Made some more progress on my DS coding. Po_Ng now has two bats and a ball. The ball bounces around the screen using this absurdly simple bit of code:

if (xpos < 0 || xpos >= 256) xv *= -1;
if (ypos < 0 || ypos >= 192) yv *= -1;

xpos += xv;
ypos += yv;

Yeah, making stuff bounce around the screen is that simple So simple I had to use Google to find out how…

Tomorrow I make it bounce off the bats too.

Originally published at Error_Success. Please leave any comments there.

Before I begin writing a game for my Nintendo DS, I first need to make sure I have the correct tools for the job. I’ve got devkitARM installed and working, the No$GBA emulator works well enough for my debugging needs so what more do I need?

Well I come from a Windows programming background, and one of the nice things Microsoft give you is a load of templates to base your software on. Writing code requires the programmer to do the same thing every time - there’s one way to open a screen, one way to get user input, one way to set up a main menu loop. Having to type all that out every time is a huge waste of energy.

I’ve just finished creating my own “game engine” that should save me lots of time and effort in the future. I have a system with sprites, title screens, a menu screen and space for the game. By copying a directory full of code, swapping some images and deleting a bit of placeholder code I have a ready-made framework to put my games into. All the time consuming effort of converting image data, loading it into the program and getting it on the screen is now done for me and wrapped into convenient functions. It’s the kind of background stuff that makes for very boring screenshots so instead here is a bit of technical information about it.

My “engine” is written in C++ (ever tried switching between C++ and C#? It’s fun) and contains several key objects. There is a Sprite object and a SpriteManager class which is responsible for keeping track of the sprites, testing for collisions and so on. There is also a Screen class which represents a single “screen” in the engine. A Screen can be anything from a splash/title screen, menu or the game itself. Each Screen object is a mini program with a main Run method. A corresponding ScreenManager class keeps these in a list and cycles through them, calling the Run method on each in turn.

The clever part is that Screens run in endless loops, waiting for some quit status to happen. So the program might go into the main menu screen and wait until the user hits the ‘Start’ button. Once this happens, the screen leaves the Run method and passes a value that corresponds to the next screen to display back into the ScreenManager.

So now I can chain screens together - It can go Splash Screen -> Title Screen -> Main Menu -> Game -> Game Over -> Main Menu. Each screen simply returns the Id of the next screen to go to. The code making this work is this simple:

next_screen = 0;
for (int i = 0; i < MAX_SCREENS; i++)
if (screen_list[next_screen] != NULL)
next_screen = screen_list[next_screen].Run();


And each Screen object’s Run method looks like this


next_screen_id = MAIN_MENU_SCREEN;
while (1) {
/* Do screen logic */
if (quit_condition)
break;
}
return next_screen_id;

Thanks to inheritance I can subclass the Screen class and create others based on it. The Game object represents the game itself. When I start a new game all I have to do is create a new Game object and fill in its Run method with the game logic.

All I’ve done is create a finite state machine, a very powerful way of controlling the flow of software. The other way to do this sort of system is with a giant if/then or switch/case statements, but it becomes complex and requires huge lists saying where to go next.

So, now I have this engine complete, what am I going to do? I’m going to make the gaming equivalent of “Hello World” - Pong! If in doubt, make Pong on it. And naturally, while doing this I will create various revisions and additions to the main engine code which will get rolled back into the main repository, ready for the next game.

Originally published at Error_Success. Please leave any comments there.

Currently I’m going right back to basics with my Nintendo DS coding. I’ve made a list of ‘classic’ games I want to copy, choosing ones that get progressively more complex. The idea being I have lots of short, relatively simple projects to do rather than spending the next six months trying to make some random game I’ve invented.

I need focus you see, or I just waste my time reading Wikipedia and thinking about game design, rather than actually doing the hard work. Hard work doesn’t have to mean bashing out lines of code, making a good design or learning something useful is also part of the game.

My list of games to write begin with good old Pong, and progress up through Space Invaders, Galaxians, Tetris, Original Mario Brothers and finally Super Mario. Short detours will be taken along the way since I quite like Qix, Voidrunner and Robotron too.

I’m not trying to clone these games, I’m more using them as a definite “thing” to create. The games themselves are not important, the process of making them is what I want to learn. Right now I can knock up a database-enabled Windows application very quickly with little hard thinking required. I have a workflow I can follow, and all my tools are in the right places to be efficiently used.

With my DS coding I’m starting from scratch and before writing something cool, need to first learn not just how to write DS stuff, but how to even do that effectively. To me the best way to do this would be to make lots of short, simple things, repeatedly throwing away and re-writing pieces of code.

I’ll document my progress here, but I’m really trying hard to avoid lots of posts saying “I’m going to do the sprite bit next” “after this part I’ll be doing the input handling”. I’d rather have posts with “So far I have the sprites working, download a test here” since the Internet is too full of people saying what they will be doing, rather than saying what they have done.

It’s called “software engineering”, but it’s more like a mad scientist inventing highly unstable and possibly lethal inventions in his lab.

Originally published at Error_Success. Please leave any comments there.

I’m working my way through Super Paper Mario on the Wii, and one of the things I really like is the HP system used for Mario’s health. It’s a bit RPGish, but works really well. I also like all the nerd jokes in Chapter 3, but that’s not the focus of this post

In traditional Mario games our hero has a set number of lives and dies the instant an enemy or piece of harmful scenery is touched. It’s the traditional game mechanic of having “lives”. In Super Paper Mario it’s different; the player’s character has a number of HP which decrease when enemies are touched. It’s hardly a new invention in gaming, but this version has a few subtle additions that make it a really good system.

It allows the player to manage their health and take calculated risks based on the amount of HP left. The important bit is that every time Mario gets hurt the screen shows how many HP he just lost, Mario jumps back a bit but then the game continues. It’s not a “health bar” on the screen that gets shorter, and it doesn’t kill the player off and move them back to a restart point. The game shows actual numbers which makes it possible to take a few hits and not have to worry about impending death. Below five remaining HP the game starts beeping with an ever increasing urgent warning sound. In this situation maybe you have an item that restores HP, maybe you don’t have just have to very carefully avoid touching anything remotely harmful.

The other things that makes this sytem work very well are the collectable items that either restore HP, reduce the amount of HP lost in an attack, or give you five HP if Mario dies.

With all this help death is final when it comes, the game returning right back to the title screen. The game is littered with save points that you can return to later, with them being intelligently placed either before a difficult part, or just after one.

All these items mean it’s very easy to keep playing. Original Mario rewarded players who were either very good, or who persevered, replaying the same parts until perfection. The game demanded total perfection, with the player being shot back to the start of the level if they failed.

Of all the platform games I own, this one has taken the most of my time up for the simple reason that I can keep playing and making progress. If I mis-jump on an enemy Mario takes damage, I know how much I have left and the game then carries on. If I fall onto some spikes, or down a hole I lose 1 HP and get returned to safety just before the spike pit/hole. It’s as if the game says “you did that wrong, have another go” rather than “that was wrong, go back to the start and do it all again including the ten minutes before the point that killed you”.

And since the player has 25 HP to play with, taking the odd knock from an enemy or falling down a spike pit doesn’t really cause much of a problem. Rather than giving up in frustration I’m motivated to have another go and beat the game.

And that’s what all games should be like - not punishing the player for being crap, but motivating them to improve by not making them repeat the bits they can do.

Originally published at Error_Success. Please leave any comments there.