FIFE forums

Please login or register.

Login with username, password and session length
Advanced search  


FIFE 0.4.0 has been released on 15th of January, 2017!

Author Topic: The current status of the project and the planned changes for the 2008.1 release  (Read 2965 times)


  • Administrator
  • Sr. Member
  • *
  • Posts: 411
    • View Profile

EDIT: I copied large passages of this thread to other relevant threads the the forums. Please reply with your feedback there in case there is a link to the specific thread.

Hello fellow FIFE developers :-)

The purpose of this thread is to:
1. Summarize the currently ongoing development in the different fields of the project. This kind of information is useful for developers and users who would like to follow the progress of the project in detail.
2. Clear up some blurry points about the upcoming 2008.1 release.
3. Ask for feedback from all active developers. It's quite natural that developers usually focus on their engine module of choice so this thread should help to collect feedback from all sources to have a kind of bigger image of the direction of the project in mind.

So let's start with the first point.

The new website:
We're currently planning to replace the old website with a new version that shares a common design amongst the majority of the website sections. The most important ideas for the new website are currently summarized at the wiki sandbox:

Qubodup, a member of the freegamer forums, volunteered to help us with the design of the new website. We're planning to introduce a new mediawiki theme for the website (it's explained in more detail at the article linked above). You can take a look at the current status of the work in progress theme here:

Unfortunately qubodup is currently quite busy with university exams so he won't have much if any time to work on the new website for the next 4-5 weeks.

How do you like the new bright colour scheme so far? Qubodup considered to use this colour scheme for the new FIFE website:

All kind of feedback in this field would be appreciated. I'll open up a new thread for the new website at the forums tomorrow so we can discuss all related aspects there; please read the website proposal at the wiki! It would be great if Lamoot would have some time to help with brainstorming for the new website. Though I don't know his schedule so please let us know if you would have some time on your hands in the next days and weeks Lamoot.

Link to discussion:

License change:
I did try to reach the developers who didn't reply to the license change proposal mails yet. Unfortunately none of them replied :-/ It seems that code of the following developers still resides in trunk:
1. Vovansim: C++ boost unit tests
2. Arron / undeadinsanity: screenshot code (might be based on some book examples and he might therefore not hold any copyright on this implementation)

My personal proposal is:
1. Create trac tickets to remove / replace the mentioned functionality (I'll take care of writing the tickets)
2. Send out a final license change agreement email and wait until the developers have agreed to the change
3. Actually remove vovansim's & arron's code
4. Ship the 2008.1 release under LGPL

As far as I can tell all developers would be fine with both license proposals (GPL + exception & LGPL) but the majority of the active developers seems to favour the LGPL because of its clarity. If nobody objects I'll word a final license change email that states that we want to switch to LGPL and asks for the agreement of all developers who contributed code to the project.

Link to discussion:

New name:
We considered to change the name of the project with the 2008.1 release to reflect that we've moved away from our Fallout roots and became a far more flexible engine than initially planned. There are basically three options:
1. A new name for the project.
2. Stick to the FIFE acronym but change its meaning.
3. Stick to the FIFE acronym and don't change the meaning.

So far some developers and users posted their opinion at the forums but it would be great to have more feedback :-) Furthermore I'm not sure how the final decision should be made. On one side it makes sense to ask all developers who contributed to FIFE, on the other side there are developers who invested a lot of time into the project and had / have major influence on the direction of the project. Would it be fair to let the majority decide?

I personally favour sticking to the FIFE acronym but to change the meaning of it. Would be good if we could get rid of the Fallout reference in my opinion. The proposal "FIFE Is a Flexible Engine" sounds pretty nice to me. No deeper meaning behind it, just a flexible engine :-) But all kind of feedback is of course appreciated. I don't want to enforce my personal preference.

Link to discussion:

Trigger system:
Joeh, a new AI programmer joined the team about 4 weeks ago. He is currently working on integrating trigger support into FIFE. There is already some initial trigger code in SVN and but there are a couple of open questions that we can hopefully clear up together :-)

Jasoka did recently introduce model change management functionality into trunk:

It looks like this model change management will help us to decrease the performance impact of triggers as we would just need to check the conditions if the model has changed somehow. Joeh mentioned that he's still a bit worried about performance impact of triggers as well as how to properly integrate them into the rest of the engine.

Therefore I propose the following steps:
1. Create a trigger support thread at the development board of the forums where we can discuss the topic in detail. EDIT: The trigger support thread can be found here now:
2. Voice your worries about trigger performance there.
3. Discuss how triggers could be best integrated into the engine and what role the model change management can play in this field.
4. Start the implementation after blurry points have been cleared up.

Link to discussion:

Physfs branch:
Wuntvor (aka aldart) is currently working on physfs ( integration in a separate branch:

So far the work on it comes along quite well but we would need to test the branch on all supported platforms before we could merge the code back to trunk. I've tested it under win32 / scons / mingw and it works fine here. Jwt tested it on linux and he mentioned that some of the unit tests seem to fail now. I can't run the C++ boost unit tests here as they're broken for scons / mingw.

It would be useful if all active developers would find the time to give this branch a test and report back if it works for them. You should use physfs 1.1.1 in combination with this branch. For win32 users there is a physfs addon for the compile SDK:

Please report back in this thread if building the branch works for you and if you can run the unit tests successfully:

If there are no major issues with the branch we could add physfs 1.1.1 to the ext directory of the branch so *NIX users could build it via scons ext=1 . After that we should merge the branch back to trunk.

Link to discussion:

Networking branch:
Trapdoor, another new developer on the team started to add networking support to FIFE. A first branch with his code can be found in SVN:

There are a couple of open questions concerning this branch that we can hopefully clear up.
1. What's the current status of the branch? What does already work and what still needs to be done?
2. Do you have a kind of roadmap for networking support in mind trapdoor? Anything the other developers could help with?
3. You mentioned that you would like to work on this networking functionality for a game development application. Is there any personal deadline or one set by the studio you're applying to?
4. The network support will be based on bsd sockets. Some developers were a bit worried about the security aspect of a pure socket solution. On one side trapdoor needs a socket programming project for his application on the other side a different solution e.g. the Python-based Twisted networking library ( might be the better suited for the project. Is this a conflict and if so what's the best way to resolve it? Maybe this isn't not a conflict at all? Feedback concerning this point would be really appreciated.

Last but not least it might be useful to merge back changes from trunk to this branch from time to time to avoid bigger merging issues later.

Link to discussion:

ffmpeg branch:
Joshdan is currently working on a branch to introduce movie support into FIFE. He utilizes the ffmpeg library for this purpose. The work in progress code can be found in SVN:

Furthermore Joshdan recently elaborated on the current status of the branch and his plans for the next steps:

Here are a couple of questions and proposals from my side:
1. Did any linux user had the chance to test this branch on his system? Did building work for you? Did you see the video when you ran island_demo? Here is a screenshot of what it should look like:
2. Wuntvor tried to merge the changes for MSVC 2008 support from trunk to the ffmpeg branch. Building the branch with MSVC 2008 worked fine but the video was not displayed though you could hear the sound of it. Should we try to merge back the latest trunk changes to the ffmpeg branch nevertheless to avoid merge issues? Furthermore this would be essential if we would like to test the branch with MSVC 2008 as support for it was introduced after the branch was created.
3. In case we don't break the branch with the changes we should try to merge back the latest changes from trunk as soon as possible IMO.

Link to discussion:

Win32 SDK
A new version of the win32 compile SDK for FIFE is currently in the making. Planned changes:
- Upgrade SWIG to 1.3.34
- Add ffmpeg support
- Official MSVC 2008 support
- Upgrade boost to 1.35.0 (for mingw, msvc2005 & msvc2008)

There is already an experimental SDK addon that adds MSVC 2008 support. However this addon is based on a SVN snapshot of the upcoming boost 1.35.0 release and Joeh had some weird segfaults with it that happened after running the island_demo for about 5 minutes.

We should wait for the final boost 1.35.0 package and release a new version of the compile SDK after that.

Link to discussion:

As I haven't worked with pychan yet I don't have a slight idea what the current status of it is. It would be good if Phoku or any developer who has worked with pychan could elaborate on the current status and on possible planned features.

Phoku recently founded his own game development project:

Having an own project now does prolly mean Phoku will have less time for FIFE and pychan :-/ It might be a good idea if we could collect all kind of feedback and proposals in the pychan thread so in case phoku finds the time to look into pychan again later he would already know what the community would like to see in future version of pychan.

Furthermore it would be useful to know if you have any kind of roadmap for pychan in mind Phoku. In case you could list your plans for it we could create trac tickets and other developers have the changce to disburden you by implementing some of the planned features.

Link to discussion:

Sja & vja, the two new audio programmers on the team are currently working on integrating openal-soft into FIFE:

OpenAl-soft is an improved OpenAL implementation for *NIX systems. The project was founded because the openal-soft maintainer was not satisfied with the way Creative Labs handled the OpenAL development (especially the Linux support).

The initial idea was to add OpenAL-soft to our ext directory in SVN so linux users could build it via scons ext=1. However openal-soft seems to rely on a file called config.h that gets generated by cmake (the native build system that openal-soft uses). We would need to port parts of the cmake script to scons in case we would like to implement the ext directory solution.

Another alternative would be to simply add a note to the wiki that openal-soft could / should be used instead of the normal openal package. In this case we would leave the library decision to the user.

Both approaches offer advantages and disadvantages:
- The ext approach would make it easy for users to install openal-soft and they won't need cmake for this purpose. The main disadvantage is that we would need to update our scons script in case we would like to add newer openal-soft releases later that come with a modified cmake script.
- The approach to leave the decision to the user offers the advantage that we wouldn't need to take care of openal-soft integration. The main disadvantage is that users are forced to install cmake if they would like to use openal-soft.

What do you think about these two approaches? Do you have any preference? Would be good to have some feedback by our Linux-based developers. Win32 users would stick to the normal OpenAL sample implementation that comes with the win32 compile SDK as OpenAL support by Creative seems to be better on this platform.

Link to discussion:

Datasets branch
Jwt is currently working on a datasets branch. Initial code can be found in SVN:

The datasets branch is meant to test the new FIFE package specification proposal:

As a bunch of changes in this field would break the island_demo in trunk we decided to work on this in a branch. My only questions concerning the datasets branch are:
1. What kind of changes are already in place?
2. Which additional changes are planned?
Content restructuring:
The currently ongoing content restructuring is also related to the new package specification proposal. Jasoka uploaded a zip file with the current status of the restructuring into SVN. It can be found here:

Caution: you won't be able to run the rio_de_hola client from the zip archive yet. There are still a couple of changes planned and AFAIR the whole content restructuring depends on the ongoing changes of the datasets branch as well. A better explanation from jwt or jasoka would be appreciated nevertheless :-)

Furthermore Jasoka uploaded some new python scripts for content creation to SVN ( &

My only question concerning the content restructuring is: which tasks should we tackle after the content restructuring is over? I hope that we could start building maps for the island_demo / rio_de_hola game but I'm not totally sure if there are other showstoppers that we should tackle first before we should try to start building the new maps.

Map creation
The last point was already brought up at the content restructuring discussion. ATM there is still the 2008.0 island_demo map in SVN. We've planned to replace this map with two new maps:

Here are a couple of questions from my side:
1. Does anyone have experience with creating basic overview layouts for maps? I'm hoping that our graphics expert Lamoot could contribute in this field.
2. Is there anyone who would like to build the maps for the island_demo? If we can't find somebody for this task I'll volunteer to take care of it myself. But maybe Lamoot or plcstpierre would be interested as well :-)

General feedback:
We're almost done :-) The last point is about general feedback. Here are a couple of questions and I would appreciate all kind of feedback and criticism. If you feel that something is not going into the right direction I'm more than happy that somebody brings up this issue so we can start to resolve it.

1. How do you feel about the general development of the project since you've involved?
2. What is in your opinion the most important aspect where FIFE development could be improved?
3. Where does FIFE development shine? To which development methods should we stick because they work out pretty well for us?

Link to discussion:

Thanks for reading all of this. Feedback to any of the points is really appreciated.
« Last Edit: March 19, 2008, 09:28:20 am by mvBarracuda »


  • Developer
  • Newbie
  • *
  • Posts: 9
    • View Profile

That is one hell of a post!  ;D Since it touches so many topics, I'll try to only comment on those things where I feel I have something to add (just assume the rest looks fine to me:) ) and where your post doesn't mention that a separate thread should be created.

New Name
I agree that the name should be changed, and I'd also say it should remain FIFE. I'd prefer if it wasn't whatever you call those clever acronyms that contain themselves, but I don't have a better idea so that works for me as well.

Since I am the one "responsible" for this branch, I just want to reinforce with this that what the branch mainly needs now is people testing it, and, if it's on linux, it'd also be nice if they could try to fix it. This would include things such as adding "scons ext=1" support for physfs, fixing tests or whatever there is. Under Windows, all clients run (though there may be more subtle errors) and all tests work (besides one that fails because loading a non-existant image no longer throws an exception, see the commit by jasoka on trunk that caused this).
Please post your results with testing it (whether successful or not) in this thread

I'd suggest leaving the cmake dependency in. I am pretty sure PhysFS will require it, too, and investing time into a work-around just doesn't seem worth the effort. We require people to install other libraries and tools like swig or boost, so why not cmake?

Content restructuring / Maps
Sounds very good to me. What isn't so clear right now, at least for me, is how this is going to work ingame and in the editor. What I imagine would be that all packages are simply mounted into a common hierarchy, so that people using packages don't have to care what package a certain object is in (which would also make it easy to override things from a different package), so it'd all reside in one common tree. Is that kind of what's planned?

General feedback
(I'll skip point 3 for now, as I find it hard to separate from 1+2 right now)

1. In general, I am really surprised at how easy it was for me to jump right into things. Everyone on IRC has been very supportive, and if there's something to discuss, there's always an open ear. The infrastructure (like the build system incl. the sdk) is very good. In general, there is a lot of progress, new things are being worked on all the time and I feel the team is "getting things done".

2. I feel that FIFE may sometimes have a lack of direction. Maybe this is just because I'm still new, but I can't say that I can see a clear "vision" of what FIFE is going to be. Of course, there is a lot of material on the wiki, but it is not always helpful when looking at specific issues. This does have its advantages, and I'm not proposing some kind of dictator who tells me exactly what and how to write it, but in my opinion some more direction might make us more productive.
The only other thing I can think of right now is that sometimes the ticket system on trac could be used more, although I am very much guilty of that myself.

That's all I can think of right now. Again, I may have missed a lot of things being still rather new myself, so please excuse me if that should be the case. :)