Already suggested.
I just need the time to (slightly) trim my chess programme and make it work with the display framework - which should be easy enough, since the entire programme apart from the one sourcefile that displays the board is independent of Allegro.

Yes, all entries are welcome. Eventually changes will be made to the IGame interface to allow network games to be developed, but that shouldn't stop you from making a game that will work without network support which can be added with little effort later.

Yes, right now the focus is on turn based games like chess and turn based strategies. I wouldn't mind having a system capable of handling simple action games as well but that's not a priority.

Btw, I'm not working on the hardcore network code myself. There's a secret contributor in this project who wants to remain anonymous for the time being, at least I assume so, otherwise he would have already posted in this thread.

Oh and with the whole weekend in front of us I hope to get some serious work done in the next 48 hours or so.

About the load/save functions... that would be very easy to implement for me. But on the other hand, if a game requires those functions, it's probably not a "minigame", although for games like your Blocks it would be useful. Btw, I played your game quite a bit. Couldn't get past level 40 for some reason. There's more than half hour of gameplay in there, although the first levels really are very easy...

Did you forget to put the source in the zip? I don't mean to say that you have to release the source, but those of us who are in Linux really can't play the game

I appreciate the effort but there are a few things I found wrong with your game:

- It doesn't work. The ball constantly travels only along the top edge of the screen and when you try to hit it, it gets stuck until you move the paddle away. (see attached screenshot)

- At 1MB it hardly qualifies as a minigame (just like my dart game ). But that's no problem really. What bothers me is that the background bitmap adds nothing to the gameplay while weighing almost 1MB. You could save the background as jpg and use the jpeg Allegro add-on to load it. You'd have to install/release it in your game of course.

- There's no source. Luckily I'm in Windows right now so I could play it, but most times I'm in Linux (as are quite a few other people) so I really would need the source.

Ok, I've hacked my (old) chess-programme into working with the interface. I didn't have to touch the actual chess-code at all, which was good (I wrote it with that in mind). The only thing I've disabled is the `ponder' feature: allowing the computer to think while you are thinking. To get it working, uncomment a few lines and compile the source again with pthreads enabled.

The interface itself is a pretty ugly hack though: I copied most of the code from my original quickly hacked-together interface and beat it until it compiled and worked. This means that right now you cannot change any settings (such as the maximum searchdepth and how long the computer thinks; these are hardcoded at 12 ply and 10 seconds). Worse, it bypasses the interface's input method, which means that you don't get keyboard shortcuts, which means that you also cannot take back any moves.
The biggest problem, however, is that nothing updates while the computer is thinking - the logic callback just freezes for ten seconds while the computer is thinking. That means that the game will appear to hang, while it actually doesn't. I'm not sure what to do about that right now; personally I'm not sure if the framework as it is (ie, a logic loop and a drawing loop that each update N times per second) is well suited for a game like chess. I could add a callback function that is called by the programme to get it to print some output, but that also doesn't play nice with the framework's separation of logic and drawing. Spawning a separate thread in which the computer thinks would be an option, but it again requires pthreads.
Anyway, the game is playable and I'll see if and when I can be bothered to improve the interface.

I remember that there were a few things that I wanted to clean up and implement in the chess programme itself (mainly having to do with move generation and move ordering in the generator), but the current programme at works.

EDIT: as for compiling, just unpack the code and run `make'. That should build it correctly for either Windows or *nix, but I haven't actually tried it in Windows.

You mean, OpenLayer 2.0 doesn't compile because the compiler doesn't understand a function definition? The CVS version compiles for Linux as well. OpenLayer is not platform specific in any single way... That's why it uses supporting libraries which are cross platform.

I mean it requires GlyphKeeper which requires FreeType 2.1.10 while I have 2.1.9 and upgrading apparently involves having to use some form of black magic.

Yeah, that would be best, I think...

Excellent. Doesn't hang anymore...

1) I'm a bit worried by the way settings are handled.
load_settings() WRITES in the structure, so using a static structure for this
is a bit messy IMO. (it's shared by all the users of the DLL)

In my game, I malloc a fresh GameSettings structure in the creator of my
IGame class and feed it default values, then free it in the destructor.
I was counting on GameDriver::Run() to run load_settings() on it and feed the
current values from .cfg, but it reveals a bug in this function : it calls
load_settings(settings, encode_game_name(theGame->GetName()));
This reads from a file called "<gamename>" with no extension, in the current
directory, instead of "<whatever_directory>/<gamename>.cfg"
(I've tested, it really behaves this way)

Actually, if settings usually work OK today, it's a friggin miracle, as I can't
see WHERE load_settings() is called with the right parameters outside of
SettingsDlg::Popup() - this one is supposedly only called when that
window opens

Anyway, this probably explains why the settings randomly disappeared sometimes,
very annoying in my game as this records your progress.

2) I found a memory leak, but it's unrelated: the IGame created in
MainMenu::OnSettings() is not deleted when the Settings window closes.
SettingsDlg::~SettingsDlg() may be the right place to fix it, I suppose.

3) During 'pause' (ESC), the keys[] array is freshly allocated and
uninitialized, containing random junk : this gives a crazy behaviour if the
Logic() function reads from this array - In my game, the blockman was running
right while pushing neighbor crates up and down...
Maybe better to init all keys as 0...

4) About network: I realize I will probably never code a network game if I can't
test it. Excuse me if I'm Mondaydreaming, but I guess the only platfom which
would allow a hobby game programmer like me to code a network game, is an
engine which could handle network AND it's "emulation": Being able to run the
same code either with actual networking between 2 computers , or as 2 programs
on the same computer.
I can install 2 Ethernet cards if it requires 2 different IP addresses, but the
engine still needs to be cleanly multi-user : no "accidental" sharing of static
data, because this could make the program behave differently than on 2
computers.

[offtopic]

well... some time ago I was programming a network game using localhost to test it and when I wanted to test it via LAN, it simply did not function and i couldn't figure out why...

I borrowed a second computer so i could test it at frequent intervals via LAN and rewrote the whole thing and now it's working...

Just to say that I have made some bad experience using localhost...
[/offtopic]

Audric: Thanks for the bug reports!

1. You must be looking at an old version of the source because I already fixed that in 2.08.

2. It is indeed a memory leak and easy to fix. Thanks.

3. Same as 2.

4. Network code is being worked. Once there is sufficient progress, the API and the server will be released. You will then be able to setup a development configuration, be it on one computer (using localhost), a small network or any other way you can. There will also be at least one public server.

Those are some interesting ideas, especially the one with the chatroom being an implementation of IGame. But I think I'll keep it the way it is suggested in v2.08. I want the chatbox to be a reusable kind of widget so that you would still be able to talk with the other players if you wanted to while playing.

As for the server/client architecture of the system, I thought everything would be done through the central server. The server would keep a list of players and active games, the clients would send messages to the server and it would rout them to their destination. This probably wouldn't work for fast action games or situations where there are a lot of active games at the same time, but I think that won't be much of a problem...