Version 0.3.8 (development)

[miyo]

I'll look into it. Did you change the version of the game you're using between loading and saving or anything?

I did just test it with clean saves-file... and same error. Sent you the savegame via email.

- Miyo

[miyo]

So assuming this version works well, would anyone be interested in a play-by-email game where we send the save file to each other by email? We could even try a four player game. If multiplayer turns out to be fun, I could look at implementing network play :-)

Skip the PBEM and implement network play. GNet (GNet is a simple network library, LGPL)

If there is going to be PBEM, I am in (playing might get really slow because of email and time differences).

- Miyo

[miyo]

Now that pressing 'n' gives you next unit how about 'h' for holding unit (undoable, unit is strategically/tactically on right position and should be considered done for moving).

Pressing 'c' (check) would make everything grayish (as when unit can not move somewhere) except your units that can still move or attack. Maybe it should also give greenish tile background for units that can still move and redish for units that can not move but can still attack (check that enemy is in adjacent tile).

If coloring background does not sound good... how about outlining tiles with that color? Or something else...

EDIT: see the FAQ for what the Orbs are for.

- Miyo

[miyo]

Let's put units to data/units/, one file per unit. The game scans the directory and loads units when it starts. Modularity.

This would make it easy to add new units (custom units for player created custom scenarios).

Maybe I am completely lost here, eh?

- Miyo

[fmunoz]

You can add as many units as you want simply use a miunit.cfg file and {include it} in the main config (game.cfg) file.
Just check them and see how the undeads and humans are added. (I done them so it's easy)

[miyo]

data/units/ and game scanning the dir when it starts would not require any tweaking for game.cfg. Less tweaking is good.

- Miyo

[fmunoz]

Maybe you are true, data directory is a bit mixed heap ... but I think thats is better to improve other aspects of the game first.

[Dave]

SDL has a networking library, SDL_net, which is what I'd use to implement network play. However I'm not sure how long it's going to be before I do that. Implementing network play is certainly not going to be 'trivial'.

How long would a multi-player game go for? 30-40 turns perhaps? More on a large map and with more players, less with players getting wiped out quickly.

If we could get at least one turn a day happening, that'd mean it should be over in a month. 2 turns a day means it could be over in a couple of weeks.

I must admit, I'm actually reasonably happy with the way the data/ directory works. I especially like how the game just loads in one configuration file: game.cfg, which includes other configuration files, instaed of the game having to know where to look for all different configuration files. One thing I might add though, which would satisfy miyo's request, is to have wildcards in the inclusions. So you could go {units/*} to include all files in units. Or, I might ditch the wildcards, and just make it that if you specify a directory, it'll include all the files in that directory. Main problem is how to order them, which is important in the case of scenarios for instance. I guess I could make them ordered using a string comparison on the file name so that scenario1.cfg will be processed ahead of scenario2.cfg

David

[Dave]

data/units/ and game scanning the dir when it starts would not require any tweaking for game.cfg. Less tweaking is good.

- Miyo

Okay, I have a compelling reason why I'm not going to do this soon: I know of no highly portable way to scan a directory in C or C++. The best I can do is opendir/readdir but that is only BSD and POSIX conforming, not ANSI C or ANSI C++ conforming. Yes it probably wouldn't be *that* hard to make it portable, but there are other more important things I have to do than researching which headers need to be #included in which operating systems, and I don't want to make it harder to port to new operating systems than I have to.

There is a solution with the current version which *almost* does what you want, miyo. Say you wanted to add a gryphon lancer (gryphon_lancer.cfg) and a barbarian (barbarian.cfg),

- make your directory, units/, inside data
- create a file, units.cfg inside units/
- at the top of game.cfg, place {units/units.cfg}
- create the files gryphon_lancer.cfg and barbarian.cfg with the unit definitions
- make the contents of units.cfg as follows:

{units/gryphon_lancer.cfg}
{units/barbarian.cfg}

That'll work. Now suppose you want to add a new unit, in horse_archer.cfg. All you have to do is add horse_archer.cfg to the units/ directory and then add the instruction {units/horse_archer.cfg} at the bottom of the file units.cfg

So, the only extra step to what you want to do is to add the {units/horse_archer.cfg} bit. You only have to add that in a less complicated index file, and not into game.cfg.

But yes, I do agree your suggestion is a good idea.

David

[miyo]

There is more than one way to do it. I agree that we can not do everything now. We should focus on getting our goals (which are?) done.

Is someone writing up all the ideas? This is "nice to have" and "sometime in the future".

- Miyo

[Dave]

Is someone writing up all the ideas? This is "nice to have" and "sometime in the future".

I think that sounds like you're volunteering!

David

[miyo]

Bug: save game in the middle of scenario, quit, load the saved game, complete the scenario, save game when it asks about it, quit, load saved game... -> The file you loaded is corrupted.

I'll look into it. Did you change the version of the game you're using between loading and saving or anything?

Dave has found the cure for this bug and I have tested it. Most likely we see it in next release.

- Miyo