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.

Messages - chewie

Pages: [1] 2 3 ... 8
Framework development / Re: Prioritizing our time/efforts
« on: April 03, 2012, 03:26:09 pm »
As FIFE 1.0 is a really big and important milestone it should IMO include these things: (no order, prolly not complete yet :D)

  • Improved Font support (see meeting log; drop size, color etc. into FIFE, get font back from a central point etc)
  • Scene management
  • Render unification
  • Particle system
  • Movie support
  • Solid toolchain (editor, helper scripts like create atlas / all xml stuff)
  • A solid demo which shows all aspects FIFE can handle, 2 completely different ones would be even better to also show flexibility
  • Full CEgui support as replacement for guichan in the long run
  • Solid sound code (preferably without OpenAL)
  • Solid documentation, both API-wise and in terms of examples
  • Solid web site which provides an easy entry point into the fife world (connecting & presenting fife client projects etc)

My main thought about it is that there be less "Oh, FIFE can't do XY" statements from outside spectators and instead more "Wow, I had no idea FIFE can do that" statements. 8)

Very important task IMO:

Unification of FIFE-object management aspects. ATM there are things which are managed by FIFE and retrievable by the client (e.g. images, instances, layers, maps, cameras etc..) and there are things which are not managed by FIFE, instead each client implements (should implement) a small manager on it's own. From the top of my head those FIFE-objects are:

  • RendererNodes
  • SoundEmitters
  • Fonts (managed by pychan)
  • Animations (not managed by the client, auto-management by FIFE which is not very flexbile)

I bet there are some more, and the general idea why this is bad: there is this pending owner ship problem between python & c++. With a proper fife.engine.get(manager, component, id) system, this could be adressed althogether and clients won't attempt to store fife-objects on their own (and therefore prolly introduce problems in their code if not done correctly) and instead only have to store the means on how to get the fife-object (e.g. layer.getInstance(instance_id))

Some ideas into this direction are the current implementation of the ImageManager, the pending thoughts about SceneManager, FontManager etc.

Framework development / Re: FIFE website redesign
« on: March 23, 2012, 04:20:12 am »
Great work rivon =)

I'd vote for the second version of the features-screen.

Game creators corner / Re: Variable height terrain
« on: March 21, 2012, 04:41:17 am »
I'm pretty sure FIFE could handle something like that but I'm not sure how easy it would be.  I'm not aware of anyone who has tried something like this before.  The biggest challenge might be content creation (the tiles themselves), map creation, and pathfinding.  I'm not sure how gameplay works and how the characters move from tile to tile.  Only thing I could suggest is to try to throw a proof of concept together and see what the roadblocks might be.

Helios is working on mulitlayer pathfinding in the cell_pathfinder-branch - a prototype for this kind of game might be a good test for the new features. :)

General discussion / Re: Python and C++
« on: March 17, 2012, 08:29:18 am »
I wasn't aware that FIFE also included pathfinding and map loading/saving. I only recently started reading about the project. That's cool.

Now, I've read in other threads that FIFE is pretty flexible and modular. I also understand that it's inspired more by FO1+2, than other games in the series. What I'm wondering is how well it would adapt to being utilized in a system more akin to FOT. Some of the features to which I am particularly referring would be the continuous turn based (i.e. real time) combat, stances (standing, crouched, prone) with applicable modifers. Basically, my eventual goal is to create a mod, but using FOTs gameplay, though I'm less concerned with some of the party features like being able to control every other character's action. Can FIFE do that? Thanks.

In addition to rivons post here some additional infos:

In FIFE, things like "standing, crouch, prone" are not hardcoded - as those are only "actions" defined by you - and which are linked to certain animation files.

There is also no combat model hardcoded in FIFE, as it doesn't exist. That's the clients job to implement a fitting management of all participants of a combat session.

Maybe this example will help you to understand what FIFE does (in this regard, combat + entity handling) for you, and what you have to add in your (python) code:

- you create a map, design it by adding ground floors, your buildings, your 'agents' (npcs, critters) etc. - internally those are ALL FIFE Instance objects
- assign unique identifiers to the objects you want to work on your code with
- in your client, ask fife to give you a particular object by handing over the unique id
- voila, you now can control this instance. If it has action (is animated), you can ask FIFE to play a certain action

It's totally up to you what you do with this control - you can e.g. write code to let an instance behave like a locker (open door, close door etc.) - or you can write code to let it act like an npc.

And of course, there is so much more - prock already mentioned a few of them already. You can do a lot of stuff with FIFE, you just have to write the propper "managing code". That's why FIFE is so flexible, and that's why you can create all kinds of (isometric / topdown 2D) games with it - be it an RTS, a cRPG, a Jump'n Run (see the shooter demo in demos/shooter), a card game etc...

Good luck with your project - and in case you give FIFE a try - don't forget to stop by at the IRC channel if you run into problems =)




So far I extracted these workarounds from the Zero framework:

Font management - ATM FIFE uses the gui lib for font handling, even for non-gui related fonts (e.g. fonts that are used via the GenericRenderer). I recommend we add a proper fontmanager (e.g. like the new image manager) and make fonts resources (like sounds, images etc) instead of gui elements. Personally, I´d say this has a high priority as the current solution is a hack.

Video support. ATM FIFE has no video support; therefore we scripted a Intro-Video (*click*) by using the renderer directly (think timers & a lot of work). It would be nice to just give FIFE a video file instead and place it either within (special) gui elements and/or have the ability to let FIFE play videos if no gui is present.

Sound management - already described by prock here:;boardseen#new
Like font management, I´d say this is mandatory as a good sound support is important for games (just being able to play a sound is not enough). Also, current sound implementation has some issues, like bad performance (sound file access introduces lags, especially noticeable if animations are played). We wrote a simple soundmanager for Zero, mainly to handle all registered soundfiles AND for providing different sound channels (video, music, sound fx ...). The channels can be controlled via sliders in the options screen (*click*) to allow the player to e.g. mute ambient music and set special fx volume to desired values (etc.).

I´ll keep digging, I bet there are some more workarounds we use :D

Help and troubleshooting / Re: importing fife in eclipse pydev
« on: September 22, 2011, 06:51:33 am »
check if scons created a /usr/lib/python26/ dir and moved the fife library into the dist-package dir there. If so, scons assumes you are using python 2.6, while eclipse tries to use python 2.7 - which of course have to fail.

I myself use python 2.6, so I have no experience on using FIFE with python 2.7. But so far, I know that only python 3.x doesn´t work, while 2.7 should. So there is a good chance that once you told either eclipse to use 2.6 or scons to use 2.7, it will work.

Help and troubleshooting / Re: importing fife in eclipse pydev
« on: September 21, 2011, 09:53:14 am »
How did you build FIFE? With scons, it is

scons ext && scons && sudo scons install-python

The last call "copies" FIFE to the dist-packages dir of python in /usr/lib/python2.6/ (hence it needs root access). I am not sure right now, but my guess is that the demos try to use the built engine first, and then start to look for a globally installed FIFE.

So 'from fife import fife' needs FIFE in python2.6/dist-packages or wherever python looks for modules.

Help and troubleshooting / Re: Weird SDL_ttf problem on Debian
« on: August 08, 2011, 09:26:59 am »
Yet another weird story about SDL_ttf.h & scons:
(ubuntu 9.10)

Seems like scons ate itself after a few compilations of FIFE - so I was forced to delete all temporary build files manually (scons started using weird paths during compilation, e.g. engine/.tws3-z/core ...).

After cleaning up, a fresh scons call was unable to find SDL_ttf.h, so I disabled the lookup for this lib. Scons compiled just fine afterwards, but of course FIFE had a problem once it should handle fonts. So I recompiled FIFE, with scons being allowed to look for SDL_ttf.h again. And... surprise, now it was able to find the lib. From this point on, I again had a working scons & FIFE environment.

My advice: before starting fiddling with *.pc files or re-linking files within the FS, just try this "trick". Or in other words: blame scons and it´s caching (at least my guess is that there goes something wrong) before blaming your machines setup.  :P

Game creators corner / Re: Little tip on key state handling
« on: January 30, 2011, 11:15:57 am »
Yep, that´s a common technique to condense code in such cases - you can e.g. also use that method for FSM implementations or every other code parts which behave like "switch" checks.

Help and troubleshooting / Re: MacOSX crash issues
« on: September 08, 2010, 09:46:06 pm »

 When I looked at the SDL source code and did some gdb debugging, I noticed that there is a variable 'current_video' that is supposed to be pointing to SDL_VideoDevice struct,  it seems that this variable is not being initialized correctly when the game main window is not started in the foreground.  Any help in this matter is greatly appreciated as this issue is holding me from starting my project using FIFE.


Missing variable inits are bad. So this _has to be fixed_. I suggest a ticket for this issue - and if you can provide your current findings (code file / line / etc) this one can be investigated & fixed a lot faster :)


Introduce yourself / Re: Hi FIFEsters, Thanks for the invite!
« on: August 23, 2010, 05:45:15 am »
They did it!  ;D

Welcome to the FIFE community  :) As the screenshots tell me, the force is with you - looks really impressive, considering the "short" time you are working with FIFE.

Best of luck to your team & cheers,

Help and troubleshooting / Re: compile FIFE on linux 64Bit
« on: August 19, 2010, 10:21:56 am »
We had a similar report here about 64bit windows ->

Solution seems to be to use a 32bit version of python.

Help and troubleshooting / Re: Editor crashes
« on: August 17, 2010, 08:46:13 am »
Thanks for the investigation Auree :)

The suspicious revision not only has changes regarding the shooter demo but also modified an important core module: fife_timer

Pychan uses timers all over the place for the event management (see in extensions/pychan/ ), and my guess was / is that something goes very wrong here.
FIFedit makes heavy use of pychan and especially events. So it is more then likely
to me, that we have to fix the timer module.

I experience the same segfaults you do, sometimes up to 5-6 in a row. If the editor does not crash, I hit the "save map" button ...  nearly every second  :/
(Ubuntu 9.10, 32bit, Python 2.6.4, SWIG Version 1.3.36)


Auree and I installed a self.thisown = 0 in which seems to solve our segfault-problem for now.

This is by no means a solution, but looking over FIFE::TimeManager and FIFE:TimeEvent we found that:
* TimeManager doesn't cleanup old timers, just manages his event vector for the TimeManager::update() calls
* Helios don't like the return; in the TimeEvent deconstructor
* Helios monitored the TimeEvent deconstructor - and it is called from somewhere

So as we are talking about segfaults, which part of FIFE is deleting old TimeEvents? Events are registerd by clients all over the place - but can we rely on python's gc to delete them?

Game creators corner / Re: Fife battle question
« on: August 01, 2010, 07:30:25 am »
Moin :)

Just stumpled across this thread - and got an idea. The old battle isle series had a main topdown map while the battles were integrated by showing a small video within the minimap area. While FIFE for now hasn't any video support, it can load several maps simultaniously & handle different cameras.

My idea would be to load two maps and give each map one camera. The "battlemap" doesn't have to be huge - just contain some cells to place the opponents and some ground tiles and the main map could still be displayed. I havent tried it yet, but it should also be possible to resize the battlemap camera during the fight. All other features like zooming in, rotating etc. are also supported - the more I think about it, the more I like the idea :D

Small mockup:
(made with located in fife-svn/trunk/tools)

Help and troubleshooting / Re: Weird SDL_ttf problem on Debian
« on: March 04, 2010, 03:17:41 pm »
btw - the correct command is

Code: [Select]
scons ext
to build the fife dependencies. But I guess that doesn't solve your problem.

Pages: [1] 2 3 ... 8