I tried searching the FIFE site for hex but didn't find anything. Would you mind elaborating on how the hex system works for FIFE?

Quote:Original post by Numsgil
I tried searching the FIFE site for hex but didn't find anything. Would you mind elaborating on how the hex system works for FIFE?

Hmm I'm not sure if that fully got your question. ATM there is just support for correctly rendering and placing hex based graphics. With our geometries concept you can flexibly define the dimensions of your hex tiles. So if you already created a bunch of hex tiles it'll be far easier for you to simply write a new geometry for them instead of resizing all of them to different dimensions.

Currently there is no support for features like "turn based combat on the hex grid" as this would involve several things that haven't been implemented yet:
1. Path finding: while there is already some initial code in place, we're still trying to find the best way how to properly integrate it into the engine. If you're interested in details, take a look into branches/active/path

2. Scripted vs. hardcoded philosophy: while we're trying to provide a very flexible framework that is suited for basically all different kinds of 2d games, we don't intend to bloat the engine with features that could be implemented far better via scripting. So we'll try to provide a good scripting API (the design of it is something we plan to tackle quite soon (for more information take a look at this blog post).

So FIFE won't ship with support for a hardcoded turn based combat on a hex grid but the game creators will be responsible to implement this via scripting. This is far more flexible and customizable but it also requires more effort by the ones who create games based on FIFE compared to a hardcoded solution. We would like to ship FIFE with some example combat scripts that can be used as a basis for your own combat engine efforts, but as there are a number of other aspects that need to be tackled before something like that could be scripted, they won't be featured in the next major release 2007.2 at least.

I'm currently working on a sim game similar to SimEarth. I know it's stretching what the engine was designed for, but how easy would it be change potentially the whole map at run time, possibly something on the order of once a second? I guess this question is really asking how much precomputation needs to go into settin up the map.

Sorry for the slight delay :-/ University still keeps me busy.

Quote:Original post by let_bound
I know some of my "requirements" are nearly mutually exclusive (eg PDA and OCaml), but like I said I'm just dumping ideas.

We're currently playing around with SWIG and it looks pretty promising so far. Python support seems to be working fine now in our test branch and as SWIG does also offer support for OCaml this should really ease adding bindings for this language to FIFE later :-)

Quote:Original post by Numsgil
I'm currently working on a sim game similar to SimEarth. I know it's stretching what the engine was designed for, but how easy would it be change potentially the whole map at run time, possibly something on the order of once a second? I guess this question is really asking how much precomputation needs to go into settin up the map.

I seriously can't answer the question at the moment Numsgil. We're currently playing around with the extend approach for scripting instead of embedding and we plan to do some performance tests after the work on it has finished to see how much slower extending is compared to embedding.

So to really find out how FIFE would perform with your game concept you would prolly simply need to give it a test :-) We're currently still working on the scripting API of FIFE so I think you should wait for our next planned major release 2007.2. If everything works out as planned the scripting API will be in place and you could do some performance tests.