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!

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - mvBarracuda

Pages: 1 [2] 3
Framework development / Time for a new FIFE release?
« on: March 02, 2009, 08:46:03 am »
The last official release was 2008.2 in July. Although work on rio de hola hasn't been continued due lack of manpower, there have been around 200 commits in the 8 months since then, fixing and improving a bunch of different engine modules.

Considering that rather large-scale changes are currently in the planning stages (redesign of the audio module and the renderer, utf8 support for pychan), I think it's a good idea to release the current trunk as official FIFE package.

There are a number of pros:
* Increase public awareness. Regular releases show that the project is still under somewhat active development. Especially as the latest meeting showed that there is still interest in improving the engine due the games that are utilizing and therefore depend on it.
* Build up confidence. Third party developers are usually extremely cautious to base their efforts upon an engine that has been "abandoned". A new release is a good way to prove that important bugs are addressed and that even new features got mixed in here and there.
* Stable release before potential major changes. As there are quite some severe changes planned for the next months, it's unlikely that we'll release a new version of FIFE before one of them has been implemented and tested. So if we don't release now, we might have to wait several weeks or even months.

Version numbering:
I would prefer a switch in the version number scheme of FIFE. To underline the shift to rather releasing somewhat stable trunk snapshots instead of polished versions of rio de hola together with the engine, I think a version scheme that includes the release date would be more suited. How do you feel about making 2009.03 (year.month) the next release instead of 2009.0(-r1) (year.nth release in this year)?

I'm more than willing to build the win32 release packages, compile a list of changes based on the trac commit listing and do some small release PR. I can't take care of providing linux source packages so in case we would like to provide a linux package as well, we would need a volunteer who could take care of it. Linux release packaging has been documented here:

What do you think? If there are no objections, I'll go ahead and compile something for win32 at the end of the week.

Framework development / Reintroducing meetings: date for April meeting
« on: February 28, 2009, 05:24:34 pm »
Our developer meeting just ended and we decided to reintroduce weekly meetings again. The results of the meeting have been compiled at this page:

You can already add your proposals to the meeting article at the wiki:

Happy voting!

Game creators corner / Project announcement: PARPG
« on: February 07, 2009, 05:15:24 pm »
PARPG is the working title of an isometric open source roleplaying game based on a post-apocalyptic setting. The project is currently still in its early planning stages. It will be a hommage to the golden age of RPGs of the late 90's and early postmillenium years. Main source of inspiration will be the Fallout series but also other classics of the genre, e.g. Arcanum and Planescape: Torment.

You've seen such announcements prolly over a dozen times before and the vast majority of them might have turned out as vapourware in the long run. There is no guarantee that PARPG might not suffer from the same tragic issues however I'm trying to explain why this project has a better chance of succeeding than some others that you've seen in the past.

My main source of confidence is my prior experience in the field of open source development. I was one of the founders of the open source game engine project FIFE and worked on the project over the course of three full years from 2005-2008. While working on FIFE I learnt a fair share about project management in general; but also about public relations, developer recruitment, maintenance of development-related infrastructure (SVN, Trac, Wiki) and software engineering in particular. This development background will hopefully help the PARPG project to succeed in the long run.

I know that it's impossible to remove doubts about the future development of the project at this moment. Some might still know me from my involvement in FIFE and I can hopefully convince the ones who don't know me yet with solid progress over the course of the next months.

More information about the project can be found here:

Framework development / The future of FIFE
« on: January 22, 2009, 09:16:21 am »
Quick and dirty copy & paste from our blog:
When I decided to step back from my position as project manager of FIFE so I could focus on my studies and private life back in September last year, I was hoping to find a new developer who would overtake my tasks and act as new project manager of FIFE. Unfortunately there were no long waiting queues of volunteers who would have liked to jump into this effort right away. On the other side I didn't invest much time and effort into finding a replacement for me as I was preparing for my final Latin exams back then. So now that that I got some spare free time on my hands, I'll tell you how you can contribute to the future of the FIFE project.

LinuxDonald, the former project manager of the FIFE-based OpenAnno project, recently got in contact with me and volunteered for taking over the project management duties of FIFE. I was quite happy that he's interested in this position as that's a good chance to resume the development of the project, that is currently on halt. The idea to create a cross platform open source isometric 2d game engine is one that I still believe in; it's just that I lack the time and motivation to continue supporting this project by being responsible for a vast number of tasks. Therefore I would like to help handing over the project to an active development team as much as possible.

The FIFE mission statement says: FIFE is a cross platform game creation framework. Exact engine feature list changes over time, but the following lists the main guidelines for development:
 * Games can be created with combination of engine, editor tools, game specific scripts and game content (e.g. maps, graphics and sounds).
 * Framework is not tied to any type of game (e.g. RTS, RPG), but instead provides flexible platform for all of them.
 * Framework supports different isometric views with addition of pure top-down view.
 * Instead of full 3D flexibility, engine focuses mainly on using high quality 2D graphics. This puts less demands on target platforms and also simplifies the framework and game development.
 * Purpose of the editor tools is to help to bind the game content with the engine and scripts.

When you hand over a project, you give away your control over the future direction of the project. While I'm quite sure that new developers might have a slightly different vision of what the FIFE engine should become, I'm positive that you'll follow the guidelines mentioned above at least as rule of thumb. My personal wish is to give a new development team the freedom to take the project into whatever direction they like. The old code is still in SVN and the releases are hosted at sourceforge. It makes no sense to me to restrict new developers to a vision of FIFE that they don't feel comfortable with.

I tagged the current trunk status as semi-official 2009.0 release in SVN. Semi-official as there are no plans from my side to provide official releases packages at sourceforge and do all the PR work that is usually related to such a release.

So what are the next steps? LinuxDonald and I got a couple of ones in mind:
* Redesigning the website and replace it with a more functional but also visually more fancy solution.
* Finding a graphics artists who could create a new logo for FIFE. We dropped the "Fallout" meaning in our name and replaced it with Flexible Isometric '''Free''' Engine. A designer created a draft for a new logo for us but unfortunately licensing is quite difficult. He seems to be unwilling to release it under a license that allows creating derivative works. Therefore we would prefer if somebody could create a new logo for us, releases it under a more friendly license and provide some kind of source file for it so that it could be easily modified later.
* Getting in contact with former FIFE developers to see if they would be interested in playing a role in resumed FIFE development.
* Setting up an IRC meeting for all interested parties to talk about the future of FIFE. Possible participants could be former FIFE developers, members of the OpenAnno & Zero-Projekt teams as well as every other person who's interested in the future direction of the project.
* Starting to recruit new developers to resume development. This includes: programmers, 2d & 3d graphics artists as well as additional project management staff to support LinuxDonald.

So what can you do? In a couple of ways:
* Monitor the blog in the next weeks. We'll keep you updated about our ongoing efforts.
* Hang around at our IRC channel:  #fife @ quakenet. Can't hurt to be around in there to know what's going on :-)
* Attend the FIFE revival IRC meeting. While we'll set up a thread at the forums where the future of FIFE can be discussed, having a meeting where we could bring almost all interested parties together sounds like a good idea. No date set for it yet but we'll let you know as soon as there is one.
* Join the new emerging team as programmer, artist or project manager.

This thread is for all feedback concernign the ongoing effort to revive FIFE development.

General discussion / New irc channel logging bot
« on: January 11, 2009, 08:07:09 am »
As our channel logging bot went down, phiker and the openanno team kindly provided a new #fife logging bot for us. Logs can be found here:

I hope that helps with the project revival process.

General discussion / My departure
« on: September 10, 2008, 03:44:21 pm »
Hello lads :-)

The majority of you have been already informed about it by me at the IRC channel but for the ones who didn't follow the blog and IRC channel lately: I'll step down from my position. It was a great time but after three years I want to focus on my real life and university again.

Detailed explanation can be found at the developer blog:

Thank you for the great time!

General discussion / Renderbackends: do you use SDL or OpenGL?
« on: August 27, 2008, 02:32:16 pm »
Hello dear FIFE users. One of our new developers is currently digging through the FIFE sourcecode to find spots where the rendering performance of the engine could be improved. The same developer recently fixed a hard to track down segfault issue that affected some Linux users that tried to use the OpenGL renderbackend of FIFE. Now that a workaround is in SVN we're asking ourselves how many FIFE users are still running the SDL rendering backend that offers a poorer performance than the OpenGL one.

We're thinking about some optimizations that could really speed up things for all OpenGL users but these changes might break the support for the SDL renderbackend. How many of you are still using the SDL backend? Why are you using it? Do you think it's reasonable to remove the SDL backend in case this would help to vastly improve OpenGL performance?

Vote and discuss :-)

General discussion / A new name for FIFE [final poll]
« on: August 05, 2008, 07:49:26 am »
Heya :-)

Reasons for changing the name can be found at this thread:

- Every registered forums user can take part and vote for two names!
- The poll will end at the 31st of August, so you got over 3.5 weeks to vote.

- All interested developers can take part in the discussion process after that. We'll try to agree on one new name / acronym meaning and start with the option which got the majority of the votes in this poll.
- We should be able to agree on one option until the project birthday at 2008/09/11. In case we can't agree on a new name, the key developers jasoka, jwt, mvbarracuda & phoku will try to decide on one.

Happy voting. If you got questions about the whole name change process, shoot right away :-)

Framework development / Improving the scons build scripts
« on: July 22, 2008, 02:01:22 pm »
The FIFE build scripts have been extended and modified since we founded the project almost 3 years ago. Features and improvements have been added incrementally but unfortunately we didn't find a scons expert who could focus on maintaining the scripts over this time. Currently the scripts themselves as well as the whole build system suffers from some problems:
* Platform specifics are spread in a bunch of different files.
* There is no documentation about the build system. I'm not sure how common and useful it would be to document the build system but from my point of view documentation would ease maintaining it in the long run. A summarization of the build system could be reside at the wiki while we could use epydoc to document the python build scripts directly.
* Unittest building is broken on win32 if used in combination with mingw. Proposal how this could be resolved can be found here:
* Build scripts sometimes don't use common scons idioms but work differently. Examples can be found here:
* More ideas to improve the scripts: &
* SCons seems to have a hard time to properly detect dependencies on some Linux distros. SDL_ttf is one of these dependencies that regularly give users some headaches. Might be worth investigating if there is a way to improve library detection on these distros.

* Create a new branch where the build system could be cleaned up without risking to break trunk building. (already done, branches/active/buildscripts_rewrite)
* Get all build system patches into SVN as soon as possible to prevent merge issues later. vtchill and sleek began to modify the build scripts recently.
* Clean up build scripts and replace custom solutions with common scons idioms where possible.
* Document the build scripts via epydoc & summarize how the build system works in general at the wiki.
* Merge back changes from the branch to trunk as soon as the overworked scripts have been tested on a couple of Linux distributions and Win32.

Feedback please!

At first I want to congratulate the whole team on the recent 2008.1 release. This was quite an important step for us as we finally got rid of all the license issues and can concentrate on new tasks for the 2008.2 release now.

The primary reason for bringing up this thread is: collecting the plans, ideas & wishes of all developers for the next release. I'll start with my ideas but hopefully the others will join me so a lively discussion starts :-)

Replacement of Reiner's graphics:
The current Rio de hola version heavily utilizes graphics from Reiner's tilesets site. Unfortunately Reiner's graphics often lack properly rotated versions and we can't simply modify and rerender them as we just got access to prerendered bitmaps but not to the original 3d models.

Fortunately two artists joined the gang recently: wulax & kaelis :-) welcome on the team mates. My proposal for the next release is to replace at least some of Reiner's graphics with own versions from our artists. This would offer a bunch of advantages:
- We could easily render the graphics for all needed perspectives that we would like to support (at least 4 rotation angles for the Rio de hola game)
- We can adjust the graphics easily as our modelers would release their models under a license of their choice.

We wouldn't need to replace the agents as they're available for eight different rotations and creating good organic models seems far more complicated than non-organic modeling.

New website:
I haven't given up on replacing our current website with a new one that features a consistent design among the majority of the pages. I'll get in contact with a webdesigner who wants to help us with the new page and we can hopefully start the work soon. Unfortunately university kept me busy lately so there was little to no progress in this field but I'm positive that we can change that soon.

New name:
Slightly related to the new website is the proposal to change the name of the FIFE acronym. We haven't really decided on a new name yet and if the team can't really agree on a new name / meaning of the acronym, I propose to simply stick to the FIFE name but express that the acronym has no specific meaning anymore. The main reason why I would like to get rid of the old acronym is that we don't really have much with Fallout in common anymore.

Fixing unittests & build system improvements:
A ready to build C++ unittest solution for MSVC2005 is still missing; it should be a pretty easy copy, paste & modify job from the MSVC2008 solution but somebody would need to look into it to make it happen.

Furthermore the C++ unittests are completely broken for mingw / scons. Fixing the mingw / scons issues seems to be quite complicated so we would need a gcc / mingw / scons expert who would volunteer for digging through all of this. vtchill recently mentioned that he considers to improve our build scripts so he might take a look into the mingw unittest issues as well.

VFS improvements:
It seems that Wuntvor got some time on his hands ATM as he just passed his exams for this semester. Therefore we should start discussing if the vfs needs any improvements and how we could implement them. We considered to use physfs in the past so it might be worth bringing up this topic again and discussing pros and cons.

Polished Rio de hola game:
Last but not least the next release could really shine in one aspect: it could feature a somewhat polished looking Rio de hola client. We don't want to create a full-featured game but it would be great if we could add at least some gameplay to the 2008.2 release. Some quick ideas from the top of my head:
- The boy character should be able to fight the bees (health points, attack / defense statistics, some kind of potion to heal the character)
- Dialogue interface to talk to other characters.
- Some kind of simple "quest log" that contains notes, quests and stats (killed bees, number of persons talked to, karma).

I'm sure that the programmers actually got a lot more ideas so share them with us :-) After initial discussion took place we should start creating trac tickets for agreed upon features.

Feedback please!

EDIT: austin just reminded me that I wanted to put a possible release date here. As we released about 3 milestones per year we might be able to get the 2008.2 release out between mid of November and end of the year. No need to hurry in case we feel like the release is not ready yet but having a kind of target release span might help with planning.

General discussion / FIFE SVN repository upgrade to Subversion 1.5
« on: July 09, 2008, 03:40:50 am »
Our SVN and trac hoster just sent me a mail today stating that they offer the choice to upgrade our repository to the new SVN release 1.5.

This is basically an optional upgrade and we could stay with the current SVN release 1.4.x as well. Here is the list of improvements that comes with Subversion 1.5:

Looks like some huge improvements especially easing merging branches. Should I go ahead and upgrade our repository to the new version? Feedback please!

General discussion / FIFE development: the good the bad and the ugly
« on: March 19, 2008, 09:22:48 am »
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 have been involved?
2. What is in your opinion the most important aspect where FIFE development could be improved? Ideas how to actually resolve any issues are appreciated but are not a requirement. It's often easier to simply name where FIFE is lacking ATM and we can think about solutions for these problems together later.
3. Where does FIFE development shine? To which development methods should we stick because they work out pretty well for us?

Thanks for reading all of this. Feedback to any of the points is really appreciated.

First feedback from Wuntvor (copied from another thread):
(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. :)

Framework development / Win32 compile SDK
« on: March 19, 2008, 08:03:30 am »
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.

Framework development / Trigger support
« on: March 18, 2008, 10:32:56 am »
Fast copy & paste from the other thread:
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. Voice your worries about trigger performance there.
2. Discuss how triggers could be best integrated into the engine and what role the model change management can play in this field.
3. Start the implementation after blurry points have been cleared up.

Framework development / Networking support
« on: March 18, 2008, 08:45:34 am »
Fast copy & paste from the other thread:
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.

Pages: 1 [2] 3