   FIFE - a flexible modable ISO engine asking for your feedback!
Fact sheet:License: Open source GPL 2.0Platforms: Win32, Linux, MacLibs: SDL, OpenGL, boost (and some more)Suited for: all kind of isometric 2D gamesCosts: FreeNote: I wasn't sure if these kind of "show your project" posts are allowed in this part of the forums. However I think that the concept is really interesting for all kind of people who're interested in ISO games so I posted it here. Feel free to move the post if you think that it doesn't belong here.About FIFE:FIFE stands for Flexible Isometric Fallout-like Engine. Just like the name of our project suggests we work on a new open source engine for all kinds of isometric games. The people working on it got a RPG background but it should be possible to customize the engine so it even works for other ISO games like RTS. The engine started as a Fallout-only project but we recognized very fast that it offers the potential to be used as a general 2d ISO engine for the development of cross platform RPGs.Why FIFE?Half-life 1 revolutionized PC gaming back in 1998. The most important part of Half-life wasn't the great game with the story but the engine behind it IMHO. HL1 was the first game that offered good modding support combined with a company that provided useful tools to support the new growing modding community. Today there are a bunch of good open source 3D engines out there like Ogre or Irrlicht. However there are several problems:1. These are mostly GFX engines. That means they focus on gfx code while they provide just few code that is needed to make a fully working game with them.2. More important: they've been made for the creation of 3D applications. But unfortunately there is no flexible 2D ISO engine (that I know) that is comparable to what Ogre and Irrlicht are for 3D games.So our aim is to "revolutionize" 2D ISO games as HL1 did it with 3D games quite some years ago. We want to create a platform for the creation of isometric games that all indie developers can use for their games so they don't need to create something from scratch. We focus on good modding abilities so we'll bundle the engine with an easy to use and full featured editor tool called FIFEdit.The advantage over other engines is that FIFE is meant to become a full game engine. So we don't only provide 2d gfx code for the rendering but also feature code that allows the modders to easily script game logic. FIFE supports SDL & OpenGL rendering modes and is uses different open source cross platform libraries. This way the engine and the editor (that uses Qt4) will run on Win32, Linux and Macintosh. So we can ensure that game developers can easily provide their games as FIFE mods that run all kind of platforms without needing to care about writing cross platform code themselves.Our editor will support a plugin system so you can easily add new features that are needed for specific kind of games; e.g. RPGs or RTS games.The current status of the project:The FIFE project is about 9 months in development now and we have released three public pre-alpha versions of the engine on sourceforge / freshmeat in January and May 2006.The gfx part of the engine is the most "mature" one at the moment. The rendering code is encapsulated well with a "renderbackend" approach; so you can easily work on the OpenGL part of the renderer without being afraid of breaking something on the SDL side. Our coders are currently working on the map model to be able to integrate some first game logic code later. You can already script a GUI using lua code; lua will be used as scripting language for all game logic too.The second part of the team is working on the new FIFE editor FIFEdit. The design phase has been just completed and the work on the code started. You can view the design document with all planned features for FIFEdit here:FIFEdit design documentYou can also already access Fallout 1 / 2 .dat archives and display maps, view animations and listen to the original .acm sound files. But I guess this information is just important for the Fallout fans here. The Fallout maps just serve as example implementation to show what's already possible.Intention of this post:We would like to know what you think about our idea of a flexible isometric engine that focuses on modding abilities. Do you think this concept will work out or isn't it worth the hassle? Are there other projects that want to achieve something similar? Do you think that our engine is worth being used later or is it easier to create an engine from scratch for indie teams that plan to create ISO games?Are there ISO fans out here that really like the idea and want to support us working on the engine? What kind of features would be really needed to make this engine attractive? Which parts of our design documents are well worked out and what's missing? Feedback is really appreciated :-)FIFE design documentsMore information:FIFE help wanted thread @ GamedevFIFE homepageFIFE development wikiFIFE screenshot sectionScreenshots:These screenshots were taken using FIFE with the original maps from Fallout 1 / 2. You'll need a valid copy of the Fallout games to load and display these maps; FIFE doesn't come bundled with copyrighted material![Edited by - mvBarracuda on June 4, 2006 11:36:57 AM]
  Very cool! I like it a lot.   ;  This is really nice. Hope you finish it.Good luck.   ;  I would love to try out FIFE and will do so as soon as I stop getting my ass kicked by work and school and my own project simulatenously. [sad] BTW everyone: giving feedback of "its good, I like it" or "its bad, needs to be better" are not very helpful statements. Rather, you should explain why you think that it is good or bad, and what particular elements of the design stand out to you in either a positive or negative way. I know its not really my place to say that since I'm not involved with FIFE at all, but I have a bad habit lately of being overly pedantic these past few days. [wink]   ;Quote:Original post by RootsI would love to try out FIFE and will do so as soon as I stop getting my ass kicked by work and school and my own project simulatenously. [sad] BTW everyone: giving feedback of "its good, I like it" or "its bad, needs to be better" are not very helpful statements. Rather, you should explain why you think that it is good or bad, and what particular elements of the design stand out to you in either a positive or negative way. I know its not really my place to say that since I'm not involved with FIFE at all, but I have a bad habit lately of being overly pedantic these past few days. [wink]Right, and why would you like to try it out?   ;  Because I've had my eye on the FIFE project for a while and have skimmed through various aspects of the project (wiki and source code), but just haven't had the time to look at it as much as I would like to. A flexible open source and well-documented isometric engine is a great thing to have around and would reduce the development time/cost for many indie game designers. That's why. [grin]   ;  It seems like a good idea for an engine! Having worked with Isometric in the past, I know that there is a good deal of work involved in making such a thing. This project should come in handy to quite a few people that want to make their own isometric games, but don't have the required experience to make an engine from scratch. Currently the batch file is a bit frustrating however, it would be nice if there was a prompt or something that asked which map you wanted to display. Also it seemed that the scrolling was a bit choppy. I don't have fallout, so I wasn't able to test the dat files, and the provided maps were a bit bland and they probally don't show off the full features of the engine. I would like to see fringing in an example map as well (as it is something I had a lot of trouble with in the past). Other things I want to see involve layering, alpha blended sprites, wall removal (not sure how practical that is), and perhaps an example of using Lua with AI. I haven't looked over your design docs yet, but I will when I get some more free time. I hope these comments helped in a slight way, and if you want specific input on something feel free to ask.   ;  Also I can tell you are going to run into problems with that xml map format! It needs to support layers, and I am not sure having an element per tile that just has <tile gid="0"/> is such a great idea. It would be better to use a binary format, or a delimited string such as "0|1|0" becuase the current format wastes a ton of space. The Chess Map is 3 kb just for the tiles when it could/should be under 1kb.   ;Quote:Original post by shadowisadogAlso I can tell you are going to run into problems with that xml map format!I would agree. General rule of thumb is that regular, "stream" data should not have individual elements tagged. For example, in an XML representation of HTML (XHMTL), you don't tag each individual character or word or sentence. You tag paragraphs, or block quotes, or if you need a finer granularity, you tag spans.Now, if each individual tile on the map contained a load of meta data, I'd say a tag per tile would be fine. But if your payload is a single int, you're practicing overkill and you're only enforcing all of the arguments people have *against* XML.For our uses in XML, when we have something like an array of indices (index buffer, for example), we simply use a whitespace-delimited array. The enclosing tags, since we're talking about a 2D array instead of a 1D array, should probably specify a width and height, or at a mininum, a stride (with height implied by the length).Do not succumb to the desire to make the 2D array's textual formatting equivalent to its physical formatting, though, as that'll just irritate editing of the XML (by hand or by API).;  Thanks for the feedback!It is good to know that people are still interested; many of the developers currently have little time hence some slowdown in the last weeks (you might have seen it from the svn dates).As I was the one how created that XML format (and the loader) I would like to a clear something up: don't judge fife by it! It started as a test on howto write a maploader (the map-format specific classes are capsuled away from the engine); the choice of elements was driven by the way FO does it (not much thought went into it), but I tinkered with several storage options (the condensed results are on the talk page of xmlmap in our wiki).In short I agree: ... wastes a lot of space (in fact I now favour storing the gids as pixels in a PNG with the XML only referencing the image; see noise*.xml).In fact I agree that XML is a terrible choice for most storage options (especially as we already have Lua included). It has one thing going for it: people are familiar with HTML and thus are rather open towards XML; that and the ease of slowly extending the DTD and the parser are why I haven't abandonded this format (at least for now).Though I have to disagree with you on some of the points:* delimited string : means I need string parsing logic _inside_ my data-format; I think the idea alone is wrong, no internal format inside a format.The current map-logic (== what is a valid map) cannot completely be covered by the DTD, though the fact that I can 'xmllint --valid --noout map.xml' catches several cases of errors; storing content in a magic format inside CDATA that only the maploader understands is no good.* binary data : would be more efficient both considering space and time; this might come as a surprise but the XML is not just human-readable, the first maps were also ~written~ by humans (so far the only way; beyond reading FO maps of course); like the ~tree & tile borders~ test in the screenshots section.* streams vs. tags : In HTML the human reading the page parses the content (the words), the maploader needs one integer per tile (so far; animated tiles or other features might add data) and I want to read it without caring about endianess.The only other option I see would be , which doesn't look much better.Finally we (at least) plan to support ZIP as a container for our VFS; it seems like a better choice to implement compression at that level as it would solve it for all file formats.   