FIFE - a cross platform isometric game engine

[Ladonna]

Graphics are nice.

However, could you tell me what mechanics of the Fallout engine you are NOT putting in? Floating text option will be available for example?

 

[mvBarracuda]

The water could use some work, and most of the trees like like fantasy fare instead of post-apoc, but overall it's great stuff there.

As I said: these gfx haven't been created from scratch but taken from Reiner's tilesets.

Our aim was to create an example map that looks un-Falloutish to show that FIFE isn't a Fallout emulator but rather a creation system for all different kinds of cRPGs. That's why we've used a tile and object geometry that is different to Fallout too. We've used a diamond shaped tile and object grid for this map, but you can define your own geometry pettry easily in the map file itself.

Graphics are nice.

However, could you tell me what mechanics of the Fallout engine you are NOT putting in? Floating text option will be available for example?

Floating text is on our list, though not for the 2007.1 release. We currently got problems again finding active programmers so I guess we'll try to fix the existing (especially map-related) bugs and release 2007.1 before we add any new features. Though it should be pretty easy for you to write your own floating text function in lua

 

[OSK]

Pardon my laziness to read through this topic and my ignorance on the subject, but what exactly does a (or maybe more specifically, this) game engine do from a developers point of view?

 

[mvBarracuda]

Pardon my laziness to read through this topic and my ignorance on the subject, but what exactly does a (or maybe more specifically, this) game engine do from a developers point of view?

From a developers point of view FIFE should become a whole game creation framework so indy developers can create their own 2D ISO RPGs with it.

So apart from creating the graphical assets with your 3D modeling programme or with photoshop, FIFE wants to provide you tools to convert these assets into working game content. As the engine is cross platform, you can distribute your FIFE-based game on Win32, MacOsX, Linux and BSD variants and all of these platforms can be supported without any need to address any cross platform issues by the game creator.

I hope that explains the basics behind the engine, feel free to ask more questions if I didn't really explain what you wanted to know.

 

[OSK]

Hmm… I can't think of a way to ask these questions without sounding like an idiot, but I guess I have to learn sometime.

I'm a computer science major. I know how to program, but my experience with graphics has been limited to simple Java applets/applications. Unless I'm mistaken, it sounds like the engine handles rendering. Does it also include classes for collision detection and common RPG related functions?

I guess basically what I'm trying to ask is how does this aid someone with programming experience in creating a 2d Isometric RPG?

Thanks for taking the time to respond to my questions.

 

[mvBarracuda]

Hmm… I can't think of a way to ask these questions without sounding like an idiot, but I guess I have to learn sometime.

Hey you don't sound like an idiot at all Actually these are some pretty smart questions, so here we go.

I'm a computer science major. I know how to program, but my experience with graphics has been limited to simple Java applets/applications. Unless I'm mistaken, it sounds like the engine handles rendering. Does it also include classes for collision detection and common RPG related functions?

The task of the engine is to take care of all low level functions so the game creator does not need to write code for that. This basically includes:
* Audio handling
* Font rendering
* GUI widgets
* Input processing
* Map rendering
* Pathfinding
* Scripting (we use Lua 5.x as scripting language)
* VirtualFileSystem
* XML parsing

Despite the low level functions, FIFE does leave creating the game logic to you. So you're responsible for writing rulesets, creating quests, scripting NPCs, etc. All of this can and will be done in Lua. However we do of course try to bundle some example Lua scripts with FIFE so game creators have a good starting point for their FIFE efforts. I hope this feature list helps you to get an impression what the engine does or plans to do and what it not aims for:
http://wiki.fifengine.de/index.php?titl ... e_features

I guess basically what I'm trying to ask is how does this aid someone with programming experience in creating a 2d Isometric RPG?

At first I need to say that you're totally right with the point: you could create all the stuff FIFE provides on your own, if you have programming knowledge. However not every programmer has programming knowledge in every area. Some programmers know AI coding but have never written a virtual file system. The majority of the people here might have just basic programming knowledge and wouldn't be able to implement any low level feature.

Here is where FIFE comes into play: we provide and test the low level features for you and design the file formats. E.g. there is no real standard format for 2D animations or maps, so we had to design our own formats. You could of course do this yourself but all of this tasks takes you away from what most people here would like to do: create a game.

Furthermore FIFE plans to provide all the little tools to get the content (scripts, maps, gfx) into the engine / your game. You can write all these tools yourself with programming knowledge but this way you'll work around 6-12 months on the engine / tools before you could start to work on your game. FIFE gets rid of these issues by letting us write an engine while letting you create a game

Thanks for taking the time to respond to my questions.

Ahh well, you're totally welcome We're happy that this project does get some interest here so I'm ready for more questions if you want to know more about FIFE.

 

[OSK]

Thanks again for taking the time to answer my questions. This is something I'll definitely check out!

 

[mvBarracuda]

It's done After over three months of hard work, we've fixed the last issues today and released the 2007.1 milestone of FIFE. The most important improvement is the new custom map format that can be considered as stable. We created a demo map for this release for a number of reasons:
* Show the modders how the FIFE map format and specific concepts like the tilesets, archetypes and prototypes work.
* Set up a starting point for modders so they can get into the world of FIFE more easily.
* Create something that looks totally unFallouty to get away from the "FIFE-is-just-a-Fallout-emulator"-image. Welcome to the Isle of FIFE

Here is a screenshot of our new demo map, using graphics from Reiner's Tilesets:


New features since the 2007.0 release:
* Stable custom XML map format for FIFE including our demo map to show the new features and syntax of it
* FPS limiter (can be set in fife.config) to save important CPU time for future tasks (AI, pathfinding, etc.)
* Tile and object coordinates can be displayed (press "c")
* Color key overriding for Fallout transparency effects (see content/gfx/fallout_overrides.xml)
* Fixed DAT1 decoding code (bug was introduced with the DAT1 rewrite)
* Major map model classes have been exported to Lua and are now accessable via the console
* Map size dependant, configurable geometries
* Colorkeying for the SDL renderer
* Add custom VFS sources via vfs.addSource (see content/etc/vfs_sources.txt)
* Increased startup speed with FO2 DAT files
* Enhanced camera with support for multiple viewports (see content/scripts/demos/map_control.lua)
* Built against SDL_image 1.2.5 and guichan 0.61 now (Win32 binaries)

Get the win32 package here:
http://downloads.sourceforge.net/fife/FIFE_2007.1_win32.exe

Get the src package for linux, mac and kind of other POSIX systems here:
http://downloads.sourceforge.net/fife/FIFE_2007.1_src.tar.bz2

Install guide:
1. Unpack
2. Read README.txt

 

[MisterStone]

If I won the powerball lottery today, I'd pay someone a multi-million dollar grant to do a nice Wasteland re-make with this engine. Failing that, I'd at least have time to write it myself...

 

[Ladonna]

Has anyone of the more tech savvy guys here checked out FIFE yet? Thoughts?

 

[galsiah]

Yes - very briefly.

Some thoughts:
It's got potential, and quite a bit is done.
A load of stuff isn't done - you can't do anything useful with it as a user at present.

However, when it is done, it'd save a lot of time even for experienced programmers. For novices, it'd save a huge amount of time, since you won't have to learn all the low level stuff. Therefore, if you assume that it will get finished in a reasonable time-frame, it might make sense to wait for FIFE, rather than trying yourself.

Earlier in the thread, mvBarracuda suggested that you can concentrate on working on the game rules/systems/setting etc., while the FIFE team make the engine. The trouble is that you can't really do that until you at least know exactly what FIFE will support (you needn't know everything that it'll support, but you need to have a guaranteed basic framework). Ideally you'd want the Lua interface specified completely, so that (in theory) you could write your game using Lua scripts before FIFE is finished.

[Patronizing analogy]
Think of your finished game as a cake. FIFE provides the ingredients (the engine), and you provide the recipe (Lua scripts).
Ideally, you want to know exactly what ingredients will be available, and their exact description. You don't need the ingredients to be ready in order to write the recipe - but you do need to know exactly what will / will not become available. A fully specified+documented Lua interface is like a full description of ingredients and ingredient properties. Once you have it, you can write your recipe/scripts without difficulty.

If you don't have that completely specified list of ingredients, all is not lost. You might have more vague, general descriptions - e.g. you know you'll have something sweet, some kind of doughy stuff, something crunchy.... In that case, you can't write an exact recipe with exact ingredients. You still can write a more abstract recipe though - e.g. take 2 parts sweet stuff, mix with 8 parts doughy stuff, cook until golden, sprinkle 1 part crunchy stuff.... So long as you only needed a sweet, doughy thing with crunchy stuff on top, all is well.
You can do this kind of thing if you know what features FIFE will provide, but not exactly how. You can write most of you scripts in more abstract terms (e.g. rather than "add the strawberries", you'd say "add the fruit"). You'd finish most of your Lua scripts in those more abstract terms. Then when the FIFE interface is finished, you'd write a few scripts to translate your abstract scripts (recipes) to use the specific interface (ingredients). So, once you know that you have strawberries, you add a note to your recipe saying: where you read "fruit", use "strawberries". In general things might be trickier: some high level concepts might map to quite a few interface functions (your "doughy stuff" might require several component ingredients - so you need to write a mini-recipe for dough).

If you don't even have a vague idea of the ingredients (i.e. FIFE functionality/interface aren't clearly specified), you've got no way to write a recipe, so you're screwed. (currently the case I think(??))
You're also screwed if the ingredients never turn up - i.e. FIFE doesn't get finished.
[/Patronizing analogy]

Hopefully, there will be a more completely specified FIFE-Lua interface some time soon. If more people were able to start on scripting, it might even stimulate the development of the engine to an extent. (or not)

I've never used Lua, but having skimmed through a brief description, I can say that it looks like a hive of vice and depravity (redefinition of functions without so much as a change of scope or a by-your-leave :shudder.
It's fairly easy to get started with though - I just tried out a few disturbing bits and bobs with LuaEdit. I used LuaEdit_3_0_2a.zip, but perhaps LuaEdit_3_0_3RC.zip would be better?? You can simply start a new "unit", type a script, then run it. Other than oddly not having the output window open as standard (under View->Debug Windows->Lua Output), there aren't any barriers to getting visible results in minutes.

The manual that comes with the editor isn't for beginners though. Try here instead.
Again, I'm not a Lua user (yet ), so I don't know how simple it is to get into for beginners. That tutorial would seem to imply that it's not entirely daft though. Since it would be useful for FIFE (if/when it's workable), it might be a reasonable place to start.

@mvBarracuda Any idea when/if specifics of features/interface would be clear? Would it be possible to specify a complete basic interface any time soon? Is there already one I've missed?

 

[Ladonna]

Thanks for your patronising Analogy Galsiah :wink:

If the ingredients are eventually specified, I may get back to the kitchen. Until then I will await further developments and ask another question on my programming thread.

 

[OccupatedVoid]

Thanks for your patronising Analogy Galsiah :wink:

If the ingredients are eventually specified, I may get back to the kitchen. Until then I will await further developments and ask another question on my programming thread.

You mean the Sarvis vs. Bryce thread?

 

[Ladonna]

You mean the Sarvis vs. Bryce thread?

Oh, don't worry, it happens every time with any thread I make. It might be different people that do the hijacking, but the e-penis fighting is the same. I just try to push on past the tit pictures, math jokes, furry posters, and other assorted Codex novelties....eventually the sane people return to get back into the discussion

 

[mvBarracuda]

At first I want to thank you for spending quite some time on the analysis of FIFE

Hopefully, there will be a more completely specified FIFE-Lua interface some time soon. If more people were able to start on scripting, it might even stimulate the development of the engine to an extent. (or not)

We know about this issue and a rather stable scripting API is planned for the 2007.2 milestone. We schedule about 4-6 months for every milestone so it's realistic to say that you should see a stable scripting API for FIFE in the next 6 months.

I've never used Lua, but having skimmed through a brief description, I can say that it looks like a hive of vice and depravity (redefinition of functions without so much as a change of scope or a by-your-leave :shudder.

Ahh well, Lua is quite industry-proven when it comes to game development. Here is a little list from wikipedia of games which used Lua as scripting language:
http://en.wikipedia.org/wiki/Lua_%28pro ... e%29#Games

They did forget to mention quite some games like Stalker and also the LucasArts games that were based on the GRIME engine (Grim Fandango, Monkey Island 4):
http://en.wikipedia.org/wiki/GrimE

@mvBarracuda Any idea when/if specifics of features/interface would be clear? Would it be possible to specify a complete basic interface any time soon? Is there already one I've missed?

As I said: a stable scripting API is scheduled for the 2007.2 milestone. There is already some a kind of example API in place but there are major changes planned for scripting, e.g. we plan to remove our currently threaded scripting system with a more simple approach because it turned out to be more complicated than initially planned.

If you need more information about the 2007.2 milestone, our roadmap is a good starting point:
http://mirror1.cvsdude.com/trac/fife/engine/roadmap

 

[freegamer]

Since FIFE is open source, worst case scenario, you can always add any missing "ingredients".

Most likely scenario is that they would be happy to implement any feature requests if it meant a cool game running using their engine.

 

[OccupatedVoid]

What are your thoughts on drive-by contributors, mvBarracuda?

 

[mvBarracuda]

What are your thoughts on drive-by contributors, mvBarracuda?

Well, as long as programmers follow our coding standards, we're happy to include patches by "lose developers".

The only real issue I see with this is that we can't annul the rules that apply for regular developers for "drive-by contributors". That mainly applies to design questions: if someone proposes a certain design for a certain feature, it's likely that the other developers got ideas how this could / should be solved; prolly not for every small feature but surely for larger ones. So it would be a good idea to peek into our IRC channel or send a short mail to our mailing list and ask what the other devs think about it. In 95% of all cases they won't have any reservations, but it's a good idea nevertheless because their feedback might help to find the best design for this feature.

 

[elander_]

If you used Python instead of Lua that editor might actually interest me. Lua only advantage is that it can be compiled with your editor and is very small but is that really more advantageous than a having a language that is much widely known and has a ton of high quality extensions for moders to use?

 

[Mayday]

"If you used Python instead of Lua that editor might actually interest me"

Same here.

 

[mvBarracuda]

If you used Python instead of Lua that editor might actually interest me. Lua only advantage is that it can be compiled with your editor and is very small but is that really more advantageous than a having a language that is much widely known and has a ton of high quality extensions for moders to use?

Okay here's the trick: if we would go for using LuaGUI, our custom Lua wrapper for Guichan, there would be some advantages for the engine itself. Because we would need to improve the current guichan code quite heavily so it's suitable for an editor; however that means we could use this heavily improved GUI code for the engine too so modders could use this improved features for their games.

I should have stated this ealier: ATM it's most important to the team that we finally get an editor, we don't care in which language it is written / what library is used as long as two simple rules apply:
1. Open source
2. Works cross platform (Linux, Win32, Mac)

So if any python programmer is interested to give this a shot, we would be _very_ pleased

 

[elander_]

If you advertise on the Python and Pygame forums you may get some good help there:

http://z7.invisionfree.com/pygame/
http://python-forum.org/py/index.php

 

[mvBarracuda]

If you advertise on the Python and Pygame forums you may get some good help there:

http://z7.invisionfree.com/pygame/
http://python-forum.org/py/index.php

Thanks We already got about two dozen of FIFE threads on the net and although I don't think that we'll find somebody there, I'll give it a try.

 

[mvBarracuda]

The last weeks were quite busy for the majority of the team members so there was we've published no news update since the release of the 2007.1 milestone about 4 weeks ago. Now we've found some time over the weekend to summarize all the events that happened in the last weeks to give you can overview about the current status of the project.

The full article can be found at the developer blog and covers a bunch of topics including some remarks about the feedback concerning the recent release, news about the upcoming universal binaries for Macintosh systems, an update about the SVN and wiki restructuring process and the reintroduced MSVC 2005 and new KDevelop support for FIFE. Have a nice read

 

[mvBarracuda]

About FIFE
FIFE is an open source 2D engine that aims to become a whole framework for the creation of cross platform (Linux, Mac, Win32) roleplaying games. Although we are having trouble getting the development started on the editor, we aim to include modding tools in future FIFE releases. The project is in development for almost 21 months now (ohh, we're getting old :-/) and we did release several public milestones of the engine over this time.

The latest release, entitled FIFE 2007.1, shipped about one month ago and features our first larger custom map for FIFE. The engine supports some of the assets of the Interplay RPG classics Fallout 1 & Fallout 2. The Fallout assets served as test content for the engine but we've moved away from our Fallout roots over the last year and FIFE is slowly becoming a general purpose 2D RPG engine, suitable for the creation of all kind of roleplaying games.

Here is an impression of our demo map that shipped with the 2007.1 release:


About the contest
The demo map shown above was created with free graphics from Reiner's tilesets site. We're trying to build a community around FIFE and we're also of course trying to get them involved in the project. A first step into this direction is our upcoming graphics contest, called: Send them in!.

The contest will start at the first of June, 2007 and the end of it is scheduled for the first of August, 2007. There are basically four different categories in which you can take part: floor tiles, roof tiles, static & animated objects and animated characters. You can take part in more than one category but there are certain requirements for each category; if you want to win the prize of the contest, you'll need to fulfill them.

So what is the prize? FIFE programmer Phoku offers to code an (useful) ~10 man hours feature into FIFE for the winner. This is probably a good way if you're considering to use FIFE for an own project but one important feature is still currently missing in your opinion. Although there will be no monetary compensation as the whole team works in their free time on the project, we're hoping for a bunch of interested participants nevertheless.

We're aiming to use the contributions of all participants of the contest for a new demo map that will hopefully already ship with the upcoming 2007.2 release.

More information
You want to know more about FIFE and the Send them in! contest? Our project site and the development wiki are good starting points for you. Our wiki features a separate rather detailed article that is dedicated the contest. All details about the rules of the contest, license-specific issues and the different contest categories can be found there.

If you still got questions about this upcoming event, feel free to visit the team at their project irc channel or ask your questions directly at the talk page of the corresponding article. You'll need to register at the wiki to get write access. We were not keen to enforce wiki registration, but the spam attacks of unregistered bots are really getting on our nerves and waste our time that could be invested far more useful.

We want to thank every interested graphics artist who takes part to support an work in progress open source project