FIFE - a cross platform isometric game engine

[yipsl]

My question is will it actually be usable by the average schmuck? In theory it's an excellent idea but I've seen way too many development tools that are too complex to used by most people.

While any open source or fan effort is good, I really do not enjoy isometric. I really prefer first person exploration CRPGs, whether they are party based like World of Xeen through Might and Magic VIII, or single character like Arena, Daggerfall and Morrowind.

3D and physics has led to the downsizing of RPGs. Physics belongs in first person shooters and last generation 2D can still look good enough to sustain a believable and large world to explore and quest in.

As for the complexity of tools, my modder wife had hoped that Two Worlds would have a Morrowind style CS, but that beta test sold as a finished game will only have tools given to the groups who can actually code and create high level content.

I suspect that FIFE is in the same category as NWN, Two Worlds and Half Life 2 modding, that some programming skills will be needed and it will be a team effort. That makes me appreciate Morrowind even more since it opens up modding to people who are artistic and want to do new races, clothes, retextures or weapons and armor. People who own Paint Shop or Photo Shop but who can only do a bit of scripting and can't actually code C.

Fuck it, it's 2006, we've done the nineties already. I'm hanging out for Fallout 3 and JA3, and find myself really pissed off with what Chris Sawyer did with Locomotion TEN YEARS after Transport Tycoon!

Tiny steps, not great fucking stupid leaps that challenge our latest and greatest gaming machines, but progress nonetheless.

Don't get me wrong, I'm not dumping on this thing by a long way - there are a boatload of folks who have been hanging out for a tool like this for longer than I can remember. The guys who have been working on JA 1.3 deserve medals (especially because JA3 will probably be ALL graphic glitz with no gameplay, as usual - ditto for Fallout 3, I suspect).

What I fear is being missed is the 'middle ground'. On the one hand we have Total Graphic Whoredom, and on the other, Hardcore ISO retro. I guess the Bioware stuff bridged the gap a bit a long time ago in a way, but that WAS a long time ago!

But I rant. I love the idea of an RPG creation machine that favours gameplay, interraction, consequence, and all the things we all love. But (as I said up front) the graphics just look naff today. IMHO.

And to be quite honest, I'd much rather an antiquated ISO engine with a decent game attached to it than a shiny showpiece with no gameplay. But surely we can have decent gameplay with decent graphics? Please?

Am I the only person here who wants a genuine first person view, 2D or 3D, with or without physics, but with physics done RPG style if it's done at all? By RPG style physics, I don't mean how a troll tumbles down a hill after being killed, but how a table can be set in the player character's house?

I want first person CRPGs, and I'd love a party based first person CRPG. I don't want Half Life 2 morphed into an action RPG and I don't want Baldurs Gate. I play Baldurs Gate, but with a bit of suspension of disbelief. I tell myself it's an RPG and not a small unit tactics RTS with RPG elements and storyline.

Is anyone working on a first person CRPG engine? There's supposedly a fan project to recreate the classic Might and Magics, but I haven't heard anything about it in years.

 

[mvBarracuda]

New FIFE win32 test binaries of the upcoming FIFE 2007.2 release are finally available

Download them here:
http://members.fifengine.de/bin/FIFE_r1222_win32.exe

 

[mvBarracuda]

Update time Progress was rather slow in the last weeks but there's a bunch of interestings things to report about nevertheless.

So here we go:
http://mirror1.cvsdude.com/trac/fife/en ... 6/25/12.05

 

[mvBarracuda]

Time for yet another update here

The progress of the last two weeks is quite encouraging. We've decided to give the extend approach for scripting a try in a separate branch but it looks like that this branch will replace our current trunk version quite fast. The work on it isn't finished yet but it seems that the performance drawback of the extend approach should be bearable; some initial tests (although with work in progress code and just on tested a Linux system) did show almost no performance drawbacks at all.

For anyone who's interested to know more about it and is not afraid of playing around with some work in progress code, check out our extend branch in SVN:
branches/active/extend

One major advantage of the extend approach in combination with <a href="http://www.swig.org/">SWIG</a> is that you'll be able to get FIFE running with bindings for your favourite scripting language quite easily. We do currently play around with Python support and that works quite well. Additionally we'll maintain support for Lua bindings as Lua was our language of choice before we decided to try something different than embedding the scripting language into FIFE. It shouldn't be too hard to create Ruby or OCaml bindings for FIFE either and if we find somebody who maintains these bindings, they'll find their way into our Subversion repository so you won't even need to invest time to generate the bindings yourself (although SWIG makes it rather easy in most cases).

Here is a nice screenshot from one of our recent test sessions. It shows the FIFE console that now can execute Python code e.g. for ingame manipulations or debugging your FIFE-based game:

Besides the work on the extend branch we're currently trying to fill our wiki with use cases for some possible FIFE-based games. That's because we intend to tackle the design of our scripting API after the work on the extend branch has finished. There is already a pretty small API in place but as it was written as proof of concept and for doing initial scripting tests it is neither consistent nor feature-complete. So we're trying to collect some real game examples first, analyze them concerning their requirements for a scripting API and plan to come up with a consistent design for our API after that.

If you consider to use FIFE for an own game in the future feel free to lend us a hand by contributing to the use cases. And don't be afraid: there are already a bunch of examples listed there that should make it easy for you to get started. If you would like to contribute but don't understand the concept of the use cases or got other related questions feel free to ask them here or at the talk page of our use case wiki article:
Use cases for the FIFE scripting API

And last but not least we're still searching for interested programmers who would like to collect some experience working on a rather large scale group project And we're usually kind guys and don't bite so if you want to find out more about us before you sign a lifetime contract with us feel free to visit our irc channel
#fife @ quakenet

 

[Higher Game]

Why is there an FPS counter there? (clueless about programming)

 

[OsirisGod]

Why is there an FPS counter there? (clueless about programming)

In order to get an ideea of the performance when writing a game , a FPS counter comes in hand , you can alpha test with it and identify possible bottle necks and other performance issues on the graphic side, i wish i had better english skills to explain this, but it does actually help in 2d or 3d in similar ways.

 

[mvBarracuda]

OsirisGod is right here

An FPS counter is a good way to see if there sudden performance chances in different revisions. You could also do profiling with a debugger, e.g. valgrind but this takes quite some work and time so the FPS counter is the easier solution to discover such issues at least (though a debugger is likely to be needed for fixing the issues nevertheless).

Additionally it's a good way to see if the fps limiter is working. We did add a way to lmit the rendered frames per second for FIFE; this saves important CPU time that can be used for other tasks, e.g. pathfinding, scripts, etc.

 

[mvBarracuda]

Yet another FIFE update coming to you

The work on the extend branch is coming along quite well lately and our current lead programmer Jasoka decided to summarize the current status from the developer's point of view. He does comment on the new Python support of the engine and raises some points how the modularization of FIFE should work.

For everyone who's interested in reading Jasoka's full text, feel free to check it out at our developer blog:
http://mirror1.cvsdude.com/trac/fife/engine/wiki/2007/07/11/18.44

 

[mvBarracuda]

Update time

We're currently reworking our XML map format as we found a number of inconsistencies that we failed to foresee when we initially designed the first version of our map format :-/

Fortunately (or unfortunately, that really depends on the perspective) there are just two FIFE-based games in development at the moment so we decided to address these issues as soon as possible to reduce the number of affected projects that will need to slightly adjust their map markup to work with the latest FIFE code.

Updated FIFE map format (draft)

The good news is that the reworking of the map format is a first step and part of our strategy to finally tackle the monster that FIFE developers call the "map editor". So there is actually hope that people who start to explore the world of FIFE with our next planned release 2007.2 won't need to worry about these changes at all (if we manage to finish a first version of our map editor tool until then).

Jasoka and jwt did invest a large amount of time to refactor important parts of the engine, kick out singletons and remove bi-directional dependencies between the different engine modules thus leading to a far cleaner engine structure. The whole refactoring process is still ongoing and everyone who's interested in what we're currently working on should check out our metamodel branch in SVN and take a look at the SVN changelog of the last weeks

Metamodel branch @ SVN
SVN changelog

Is anyone working on a first person CRPG engine? There's supposedly a fan project to recreate the classic Might and Magics, but I haven't heard anything about it in years.

This might be interesting for you:
http://dotg.sourceforge.net/

 

[elander_]

I see you are working with Python. That's a nice move.

Fortunately (or unfortunately, that really depends on the perspective) there are just two FIFE-based games in development at the moment...

As an experiment I could try to adapt Daggerfall to a TB version using FIFE. All the game models are in 2d sprites so this would not be a problem. The original FPS combat sucked anyway.

Do you a have a huge manual in pdf that we can download and read offline? That would easy things a bit.

 

[OSK]

I'm not completely sure what this SWIG does. Would this allow me to program portions of the game in C++ and allow it to be used by Python code?

As an experiment I could try to adapt Daggerfall to a TB version using FIFE. All the game models are in 2d sprites so this would not be a problem. The original FPS combat sucked anyway.

That'd be amazing…

 

[mvBarracuda]

SWIG generates the binding wrappers for you so you can use FIFE in combination with:
* Python (we do already ship the wrappers with our code so this will be supported right out of the box)
* Lua
* Ruby
* OCaml
* A bunch of other (scripting) languages

For more information:
http://www.swig.org/

And no: as the new branch is still work in progress, there is no PDF that explains everything in detail. We're currently reworking our developer documentation so although it far from complete, this should give you a pointer into which direction we're heading:
http://wiki.fifengine.de/index.php?titl ... umentation

If you would like to play with work in progress code feel free get your hands on the files from SVN now. Otherwhise you should prolly wait for the official 2007.2 release though I really appreciate early feedback as we can address possible issues before we ship the major releases to the public.

 

[mvBarracuda]

Welcome to yet another FIFE news update

It was pretty quiet lately, not because we would have been lazy but because I was busy with my exams and had no time to write about our most recent efforts. Nevertheless there was of course a bunch of work going on behind the scenes and I'm happy to have finally found the time to summarize it for you. There are several topics to talk about:
* The send them in! contest is over and we finally have a winner.
* The work on the new metamodel branch is coming along quite well.
* The FIFE team agreed to work on a new techdemo in cooperation with the Zero-Projekt team that explains the features of FIFE.
* The FIFE project turns two rather soon Time for a birthday party.
* fifengine.de has been slightly updated with the help of the new developer NickWarner.

You can read about all these topics in detail at our most recent FIFE developer blog update. Have fun

 

[Keldorn]

It's great to see that folks are keeping isometric glory alive, and expanding it's contemporary horizons and applications.

 

[mvBarracuda]

It's great to see that folks are keeping isometric glory alive, and expanding it's contemporary horizons and applications.

Thanks for the heads up

We'll release screenshots of the upcoming techdemo that we're working on with the Zero team as soon there is something to show. The sad lesson we've learned is that 95% of the users simply won't read lenghty texts even if they contain useful information but they'll happily react to any updates that feature new media. So we'll try to deliver something to you folks soon

 

[denizsi]

As an experiment I could try to adapt Daggerfall to a TB version using FIFE. All the game models are in 2d sprites so this would not be a problem.

Wouldn't you need sprites that are rendered or created for isometric angle? It might not look nice with sprites made for first person.

The original FPS combat sucked anyway.

Not really. Whatever, are you working on this?

 

[rpgcodexusername]

can you do raycasting to determine line of sight?
can you do other types of games?

 

[mvBarracuda]

can you do raycasting to determine line of sight?

Why not?

I'm not sure how modern line of sight algorithms work but I don't see any design decision that would prevent integrating line of sight via raycasting into FIFE. Note: we'll offer a line of sight system that ships with later releases so you could use what already comes with FIFE. But as we haven't finally integrated pathfinding yet (though there seems to be progress ), I guess it will take some time until we see a ready to use LOS system that ships with FIFE.

can you do other types of games?

Care to elaborate?

I theory FIFE should be suited for all types of 2d games however it was designed with RPGs as primary target platform in mind. I'm pretty sure that it would be perfect to create 2d adventure games with it nevertheless. There don't seem to be many isometric adventures but I don't see any reason why it shouldn't be possible with FIFE. Strategy games might be possible too but there are a number of possible upcoming issues we can't foresee at the moment.

Therefore we're working hard to finally release 2007.2 (though I'll try to convince the others to improve our documentation together before we release anything to the public; people who can't wait can always get the sources from SVN and build them). After the 2007.2 release we hope that there are actually some people who start building games based on FIFE. Depending on their feedback we'll try to improve the engine and see if FIFE is also suitable for all different kinds of 2d games.

 

[mvBarracuda]

We can't really believe it either but our calendar says that it has been almost two years now since we started to work on this very project. At the 11th of September 2005 a group of naive but enthusiastic individuals agreed to found a development project to create an improved Fallout-like engine for roleplaying games. Although the focus shifted to become a more general and flexible 2D engine, altough new members joined and old ones left the team, we're still around and the recent progress gives us the hope that there'll be a bunch of birthday parties to celebrate in the next couple of years To celebrate at least our first two years we invite every developer (active, inactive, ex or even simply interested to get involved) and of course every guest to visit our IRC channel at Tuesday, 2007/09/11.

If you always wanted to get to know these crazy FIFE people here is your chance. As the majority of the FIFE developers are set in Europe you will probably need to wait for the evening hours (GMT) to get in touch with project members though. You could even try to obtain an answer to the question when 2007.2 will be released. Though it's likely that we'll answer: ''When it's done''. Not because we're cruel but because we don't know it either Anyway: we hope to see all of you at Tuesday.

Let's get this party started

 

[Blacklung]

I'm definitely no programmer, but this is looking pretty neat. Still, I'm wondering if anything, as far as actual games, have yet to be released using FIFE. It would be nice to actually see what some capable programmers have done, even with 'incomplete' builds of this engine.

 

[mvBarracuda]

You've got a point there Blacklung We know about this issue and try to address this now:
http://mirror1.cvsdude.com/trac/fife/en ... ooperation

 

[rpgcodexusername]

you mentioned there was no pathfinding?
cant do much without that,

 

[mvBarracuda]

Check out the latest SVN code

There is a basic pathfinding interface in place now. This will be further improved, but if you got some programming skills you can already play around with it or build a more sophisticated pather based on it:
http://mirror1.cvsdude.com/trac/fife/en ... nearpather

 

[mvBarracuda]

Finally a first screenshot of the upcoming techdemo that is a cooperation of the Zero-Projekt team and the FIFE staff. Looks like they make fun of poor little Barracuda :-(

 

[mvBarracuda]

To bring up the most important fact at the beginning: the FIFE team will finally release the 2007.2 milestone to the public at Wednesday, the 10th of October, 2007. Over five months have passed since the 2007.1 milestone had been released at the end of April and a lot has changed since then. Now that the most important changes are in place and work we feel that it's time for another release to give the community a sign into which direction the project is heading.

Let's summarize the most important changes for the 2007.2 release and have a (small) look into the future of FIFE as well.

After having utilized Lua5 for the scripting side of FIFE for over 18 months we agreed that it would be worth taking a look at SWIG again. SWIG was promising as it offered a way to use our engine with a number of scripting languages; furthermore we could get rid of the semi-manual lunar.h bindings approach this way as well. We ran into some hurdles while trying to integrate SWIG into FIFE but in the end it worked out quite well. Now we had the ability to wrap up the engine into python instead of the old way of embedding the Lua library into FIFE.

The so-called metamodel branch was an undertaking to seriously redesign major parts of the engine. We decided to go for an MVC (model - view - controller) architecture pattern for FIFE and refactored the engine modules accordingly. Another aim was to remove unneeded bi-directional module dependencies to have a clean module hierarchy:
http://wiki.fifengine.de/index.php?title=Engine_Core

The Zero-Projekt team agreed to work with the FIFE developers on an example game for future releases together. This way we can give game creators a starting point and show what can be done with the engine. Furthermore working with the Zero team directly together brings up a number of advantages for FIFE:
* We won't need to worry about producing content for the example game.
* We're in contact with game creators so we get feedback what works well and what aspects should be improved.
* We can test and adjust the FIFE API while we work on the example game. This wouldn't be possible without building an actual game on top of the engine.

A first snapshot of the example game will come bundled with the 2007.2 release. Don't expect too much: it is a work in progress project and especially the first versions will naturally lack a lot of polish!

After the release of the 2007.2 milestone we plan to finally start working on the editor tools for FIFE again. We tried to do so several times before but everytime something went wrong: editor programmers disappeared and later we did find several engine issues that prevented building an useful editor tool on top of the engine.

Now that the engine is in pretty good shape after the metamodel refactoring, we feel that working on the editor tools will bring up better results this time. Jwt, who also wrote the new python-based maploaders for the 2007.2 release, does currently investigate how we could create python-based mapsavers. This is meant to be the first step for the editor tools.

Anxs & prock are currently redesigning the FIFE audio module in a separate branch. If everything works out as planned we might be able to ship the new improved audio module already with the 2007.3 release. If you want to read some detailed information about the audio module redesign, head over to the wiki:
http://wiki.fifengine.de/index.php?title=Audio_Design_Documentation

Now that we're heading to the finish line we can need every helping hand to test the upcoming release. Furthermore help with packaging would be appreciated as well. Therefore we invite every interested community member to join our project IRC channel to lend us a hand. We hope to see some of you there. If you're too busy, it would be great if you could be around at the release day to celebrate the new milestone with us at least
http://wiki.fifengine.de/index.php?title=IRC

And finally after all the text, some new eye-candy as well. This is a screenshot of the product we're working on together with the Zero-Projekt team. This content won't ship with the upcoming 2007.2 release and is work in progress.