Would you use a premade isometric engine for your game?

Yes, I definitely would!

Except I already wrote my own. :(

I would not use a pre-made isometric engine simply because I value the experience gained from writing my own. Not being 100% familiar with the code behind the engine and possibly not being able to fix problems with it myself would be another reason why I would not use it (so perhaps make it open-source?).

Don't let me discourage you though. There are a lot of people out there who would be very grateful for a free isometric engine to speed up their development process.

VBStrider

I'll probably be making a 2D iso game in the not-so-distant feature, but more as a test for my own 2D game engine. If I were primarily interested in making iso games then I would certainly be interested in third-party engines, however I'm focusing on making an engine based around a particular unique style I'd like.

If I were looking for a third party library I'd be wary of one licenced under the GPL. Having to open source game code can be problematic, especially for multiplayer games, but even from a customer support perspective if there are a multiple of forked code bases. I'm also a bit concerned about being forced to open source code rather than having it as an option. I'd be far more receptive to an LGPL licence, a less restrictive BSD or zlib style licence, or even a cheap closed-source commercial licence.

Quote:

Original post by VBStrider Not being 100% familiar with the code behind the engine and possibly not being able to fix problems with it myself would be another reason why I would not use it (so perhaps make it open-source?).

Hehe, the engine is already open source :-)

The code can be found in our Subversion repository:
svn co https://svn1.cvsdude.com/fife/engine/trunk

Just skimmed the code, looks good.

Do you have a playable demo? Not need to be a full game, just have some interactive NPC- and mob-like things.

Well, here's my $0.02... If I were making a 2D RPG-type game in general, I'd consider using such an engine, if it were flexible enough... if I could decide whether the combat was real-time or turn-based, party-driven or single-player. If I could use the engine to make Diablo, Nethack, or Final Fantasy then I'd probably strongly consider it.

I'm also somewhat biased... I don't have the time or content to make a professional-quality game, so anything I made with this engine would be more on the hobbyist level. My views reflect what I consider necessary for this; someone looking to write Diablo 3 would probably have different opinions.

As for features:
Sound: WAV, MP3 or Ogg Vorbis formats, preferably all three. More exotic stuff is nice but not vital. Options for 3D/surround sound would be nice, but not vital.

Graphics/rendering: Maybe SDL, OpenGL support would be nice. Portability is important, at least for me, so no DirectX.

Fonts: The format doesn't matter in the slightest, as long as I have a decent variety.

GUI: Being skinnable is key. No fancy textures or uber slide-effects, just something that looks nice and is flexible. The ability to create custom widgets is important, as I don't expect you to include a package for something like, say, Diablo's inventory system (I've been playing a lot of Diablo recently :-).

And yes, I'd use a GPL engine, even for a commercial game... though I might ask for at least a bit of copy-protection for my content in that case. Nothing overboard, just something to make it inconvenient to rip my content.

Hope this helps.

Sorry for my late reply. As you'll find out, I have different needs from most people, and answering some of them would probably require a huge effort. I'm mostly dumping everything I can think of here.

Quote:

Original post by mvBarracuda 1. Would you use a premade ISO 2D engine for your game project at all? If you don't consider this as an valid option, regardless of the features the engine would provide, please elaborate on your reasons.

As long as it suits my needs (obviously), no problem.

Quote:

Audio: * What kind of audio codecs should the engine support?

I only need Vorbis and PCM in Ogg and WAV containers, respectively. I can't imagine myself needing anything else. I'd rather it streamed the data instead of loading it all in memory ^[1].

Quote:

* What kind of audio features should the engine support (stereo, "3d sound", etc.)?

Both would be nice, but I could easily live without them. In fact, I'd need them to be entirely optional ^[1].

Quote:

Font rendering: * What kind of font formats should the engine support (ttf, bitmap fonts, other font formats, etc.)

TrueType is a must in my case^[2]. OpenType would be nifty, but that's a lot of work for pretty much no gain other than cosmetic.

Quote:

Graphical user interface: * What kind of features should the GUI support [e.g. dragging widgets, widget transparency, etc.)?

I could do without dragging, but it'd save me a lot of time. I don't need transparency at all.

Quote:

* What kind of basic widgets would be needed for your game?

I'd need not-so-basic ones: a text input one, and some widgets like a label, buttons, etc. Before you think it's easy, see ^[2].

Tools for disabled people would also be great, but it probably belongs outside of the engine, and it's a huge topic.

Quote:

* What kind of 3rd party GUI library would you like to use for your game (QT, WxWidgets, CEGUI, etc.)?

Qt for tools would be excellent. I can't imagine myself using it ingame though (for one thing: it's a very large library). I believe CEGUI requires an underlying 3D API, which would make simple 2D backends unusable. I guess either "no GUI" or something optional would be best for me, as it means I'd be able to eventually supply my own.

Quote:

The list goes on for rendering features (e.g. different render backends like OpenGL, SDL or DirectX), animations, input management, the map format, pathfinding, scripting, movie support, virtual file system handling and other misc. features like an console for ingame debugging / script tests.

• For ^[1], I'd definitely need to be able to "plug" my own renderer in the engine. The same goes for input management. I don't mind not having support for these platforms for non-commercial games, but it'd be a must were I to work on commercial software;


• map formats, animations, etc: if the engine comes with its own formats, I'll use them unless they're really too restrictive. That's especially true if there are tools to create said formats;


• ingame debugging would rock. Heck, I wish I could write my stuff in Common Lisp just for that^[3];


• VFS: I'm not sure about that one. A lot of libraries already provide that feature. I guess it depends on what you're after. Complete platform abstraction is nice, but sometimes it just gets in the way. I'm undecided;


• scripting: that would be neat, but not necessary, and should IMHO be totally optional as not to drag in tons of dependencies;


• animations: much needed;


• dirty rectangle updates would be great;


• serialization would be a nice feature and would ease the implementation of saved games and networking (though I'm not interested in the latter ATM);


• I use free UN*X-like systems almost exclusively (I have other systems for testing purposes), so I'd obviously want the tools to run on such platforms, and the code to build out of the box, preferably using something like the autotools because they're quite standard there;


• because portability is very important to me, I'd need the engine to be endian-safe and 64-bit clean (I work on AMD64 and PPC most of the time);


• I need Unicode^[2], and for that I usually use ICU. It'd be nice if the engine used UTF-16 internally (not UCS-2), even better if it used ICU's UnicodeString;


• i18n and l10n are a must for me^[2], but the aforementioned ICU along with GNU gettext will do just fine. If support is built in the engine, it's just a plus;


• pathfinding: I'd need A*. I already have an (ugly) implementation written in OCaml, but translating it to C++ templates is a chore. If someone does it for me, all the better.

Quote:

Most important: we would like to know if you would use an GPL'ed engine even for a commercial project (that perfectly possible as you would need to open source certain parts of your code but you would charge for the content you've created in this case).

Yep. I'm not thinking about going commercial with anything right now, but I definitely wouldn't mind "GPL'ing" my software. I'm a free software advocate though, so I'm biased.

1. I'm interested in PDAs, smartphones, etc. Assuming I ever attempted to deploy a game on one of them, I'd likely have to provide a custom renderer, a custom input handler, a custom sound output module, etc. Because these platforms have quite limited resources, streaming audio is a must;


2. I try to think of people whose language isn't mine (I'm a French Belgian): I want Unicode handling and for that I need TrueType fonts, because generating bitmap fonts for some languages would be insane. It also means I'd like to have support for bi-directional text and CJK. Doing so portably is huge undertaking though;


3. I loathe... Quite a few Algol-like programming languages I shall not name. [grin] Language bindings for my favourite language would rock, but I realize this isn't going to ever happen.[smile]

I know some of my "requirements" are nearly mutually exclusive (eg PDA and OCaml), but like I said I'm just dumping ideas.

Sorry about the long post.

EDIT: typos and more typos

[Edited by - let_bound on June 8, 2007 4:09:41 PM]

Quote:

Original post by Trapper Zoid If I were looking for a third party library I'd be wary of one licenced under the GPL. Having to open source game code can be problematic, especially for multiplayer games, but even from a customer support perspective if there are a multiple of forked code bases. I'm also a bit concerned about being forced to open source code rather than having it as an option. I'd be far more receptive to an LGPL licence, a less restrictive BSD or zlib style licence, or even a cheap closed-source commercial licence.

Ditto. I wouldn't just be wary, I simply wouldn't use it if it was GPL. I've no problem with LGPL or the others that Trapper mentioned.

Quote:

Qt for tools would be excellent. I can't imagine myself using it ingame though (for one thing: it's a very large library). I believe CEGUI requires an underlying 3D API, which would make simple 2D backends unusable. I guess either "no GUI" or something optional would be best for me, as it means I'd be able to eventually supply my own.

I've actually written a GUI library on top of SDL that requires no 3d hardware. It's got features I don't actually use.

I'd be interested in contributing to this project, but I'm making a general-purpose 2d engine myself.

I most definitely would not.

The main reason being I've already done it, and it was a fun, long journey. It took a lot of time, and it's not entirely complete or modular, but I had fun and learnt a lot.

I wouldn't use a pre-made isometric engine regardless of the features.

Quote:

Original post by count0 Just skimmed the code, looks good. Do you have a playable demo? Not need to be a full game, just have some interactive NPC- and mob-like things.

Ahh well, there is a demo map but it's nothing full featured. It's a simple map with some graphics, animations and background music to illustrate the current status of the project. Simply load up FIFE with the maploader and select content/maps/official_map.xml from the interface.

Quote:

Original post by Icefox [...] And yes, I'd use a GPL engine, even for a commercial game... though I might ask for at least a bit of copy-protection for my content in that case. Nothing overboard, just something to make it inconvenient to rip my content. Hope this helps.

Yep, very useful feedback indeed :-)

I quoted the copy protection passage as we're not really sure yet how we should cover this area. Do you have any useful links or examples for copy / content protection in open source applications? This would be really useful to come up with a custom system to make the engine more attractive to indie developers who don't want to see their games pirated.

Quote:

Original post by tstrimp Ditto. I wouldn't just be wary, I simply wouldn't use it if it was GPL. I've no problem with LGPL or the others that Trapper mentioned.

Hmm now that's really tricky. About 15-20 different people have contributed code to the engine so there would be no easy way to turn it into a LPGL one :-/

We could ask everyone but I know at least one developer who wrote a lot of code who surely won't like this idea. So I guess we'll stick to the GPL license and see if there are any takers nevertheless :-)

This is about FIFE? Why didn't you say so? Everyone loves FIFE.

Quote:

Original post by Deyja This is about FIFE? Why didn't you say so? Everyone loves FIFE.

Ahh well, I thought the two links in the first sentence of the initial post would be enough of advertizing :-p

As long as it fit my needs, I'd definitely use an engine that was already built. Why not? There's loads of great software written on existing engines. I'd be wary of using GPL software, though, even if it's not commercial. I prefer LGPL or something less restrictive. I'm happy to redistribute changes I make to GPL programs but I'd prefer to have the option of closing my game code.

What the engine would need to do, naturally, is provide a system for graphics display and animation, audio and basic I/O.

I'd prefer dimetric (Diablo) as opposed to isometric (Ultima Online).

Portability is good. DirectX and OpenGL are good.

For audio I'd want wav/OGG and possibly MP3. Nothing fancy, just stereo. Anything beyond that is good, but not on my list as necessary. I think most people just want basic sound support.

For fonts, my main concern would just be that it is rendered properly. Bad TTF rendering is awful. If TTF is used it might also be best if the size can be set in points OR pixels.

A basic GUI is all I'd want. Don't care much about opacity and such. Basic buttons, windows, text/image boxes with sliders and input boxes with support for text, radial, checkbox and slider input.

Animation: definitely. Same for debugging.

Animation would require a format as would maps. I think a map format is one of the hardest things to make universal - so that it meets everyone's needs.

3D characters would be cool (ala Little Big Adventure/Relentless and the Sims).

For more complex features: lighting is good to offer. Also, the engine really should be able to make walls/objects "open" or become translucent if they block things. Game design can get around this, but it's better to include that possible solution, I think.

To the people that made engines already: What are you doing with them? What have you already done with them? What was your map format like or what did your maps need?

Regards and good luck

Quote:

Original post by mvBarracuda 1. Would you use a premade ISO 2D engine for your game project at all? If you don't consider this as an valid option, regardless of the features the engine would provide, please elaborate on your reasons.

Yes. I dislike re-inventing the wheel.

Quote:

Original post by mvBarracuda 2. What kind of features should this engine support so that you would consider using it for an game project (commercial or non-commercial).

I am working on a 2D, Tile based (Hex tiles) Turn Based Strategy game (Master of Magic re-make).
The features it would have to support for me to use it would be;
1) Turn Based Gameplay
2) Hex Tiles
3) Unit Stacks (Armies)
4) Unit Experence
5) Unit Modifiers (Magic Spells, Leader Effects)
6) Mini Map
7) Tactical Combat Screen (When 2 armies owned by differnt teams enter a hex they are moved to the Tactical Combat map)
8) Cities (Civ like cities)
9) Unit Statistic Tracking
10) A* Pathfinding

Numbers 1, 2, 6, 7 are the most important for the game engine to support. The rest I could mod in if needed.

Quote:

Original post by mvBarracuda Audio: * What kind of audio codecs should the engine support? * What kind of audio features should the engine support (stereo, "3d sound", etc.)?

No idea. I have not even started to think about this. I don't care as long as they are common enough that I can talk someone else into making some sounds for me or I can use MoMs sounds until then.

Quote:

Original post by mvBarracuda Font rendering: * What kind of font formats should the engine support (ttf, bitmap fonts, other font formats, etc.)

ttf - Anything else is bonus.

Quote:

Original post by mvBarracuda Graphical user interface: * What kind of features should the GUI support [e.g. dragging widgets, widget transparency, etc.)? * What kind of basic widgets would be needed for your game? * What kind of 3rd party GUI library would you like to use for your game (QT, WxWidgets, CEGUI, etc.)?

Draggable GUI elements with transparency settings are cool but not needed.

The standard UI elements are fine (Select Box, Check Box, Text Box, Radio Buttons, etc).

3rd party GUI library support would go unused by me.

Quote:

Original post by mvBarracuda The list goes on for rendering features (e.g. different render backends like OpenGL, SDL or DirectX), animations, input management, the map format, pathfinding, scripting, movie support, virtual file system handling and other misc. features like an console for ingame debugging / script tests.

DirectX.

I could work with most map formats.

A* Pathfinding all the way.

Any scripting lang would work.

Movie support is too far off for me to have any idea.

Quote:

Original post by mvBarracuda Most important: we would like to know if you would use an GPL'ed engine even for a commercial project (that perfectly possible as you would need to open source certain parts of your code but you would charge for the content you've created in this case).

I would have no problem with that but I know that some publishers might have problems with that.

Sammual

P.S. Any chance FIFE would work for me?

At first I want to apologize for the late reply: university does currently take the majority of my time so answers can take a bunch of days :-/

Quote:

Original post by Dazco What was your map format like or what did your maps need?

We're using an XML based map format for FIFE. The format is documented at our wiki in case you're curious:
FIFE map format

Quote:

Original post by Sammual P.S. Any chance FIFE would work for me?

Yes and no.

As long-term solution FIFE should work fine for you because the majority of the features you want to see are planned to FIFE in the long run.

Quote:

Original post by Sammual 1) Turn Based Gameplay

Not sure how we'll implement that. ATM there is no code in place to handle this as we're just evaluating the future scripting API (so we haven't agreed yet how game objects should be handled in detail).

Providing a basic template for a turn-based system should not be that hard for us. However you surely want a system that integrates well into your game concept; so you'll have to modify / extend our example code significantly for your own needs.

Quote:

Original post by Sammual 2) Hex Tiles

Already supported :-)

Quote:

Original post by Sammual 3) Unit Stacks (Armies)

Hmm how would this work? I guess you could form an unit stack by combining single units and they would move together this way? You'll surely have to write a custom system for this but it shouldn't be too hard.

Quote:

Original post by Sammual 4) Unit Experence 5) Unit Modifiers (Magic Spells, Leader Effects)

The same goes for these two: a scripted solution should work fine for this, no need to touch the C++ side :-)

Quote:

Original post by Sammual 6) Mini Map

Not implemented yet and we're not really sure how we should bring this feature into FIFE. As soon as the pathfinding code is fully integrated and tested, we could auto-generate a mini-map that shows paths and blocked tiles / hexes though.

Quote:

Original post by Sammual 7) Tactical Combat Screen (When 2 armies owned by differnt teams enter a hex they are moved to the Tactical Combat map)

How would this tactical combat screen work? Something like the combat screen in "North and South" but the result would be calculated based on the stats of the units?

Quote:

Original post by Sammual 8) Cities (Civ like cities)

It shouldn't be that hard to add a city screen by combining some GUI widgets together :-)

Quote:

Original post by Sammual 9) Unit Statistic Tracking

Every object in FIFE can hold metadata so I'm pretty sure you could handle the statistics with the help of this and some rather simple script.

Quote:

Original post by Sammual 10) A* Pathfinding

Although there is already some pathfinding code in our SVN repository, it's not fully integrated into the engine yet :-/ The guy who worked on is busy with his real life and the other active developers are already working on other features that also got a high priority. So I guess we'll postpone this although we'll definately feature pathfinding support later.

(The current pathfinding code is based on the open source A* Micropather library.)

So as you can see: you could use FIFE for your game project but a lot of your needed features are not integrated yet although none of them would be impossible to realize with FIFE. Therefore I need to admit that FIFE isn't suited as a short-term solution if you want to have a full-featured and stable solution that you can start with right away.

Considering that the design phase for games takes a lot of time, you could design and develope your game parallel to FIFE and you shouldn't depend too much on our progress this way.

If you got some time on your hands and want to do use a huge favour, here is your chance. We're currently collecting use cases for FIFE so we can compile a requirements list for the future scripting API from it. So if you want to help us, feel free to add some use cases for your planned game; this should help to ensure that all of your planned features work with FIFE later as we would have them in mind when it comes to the planned redesign of the scripting API. No need to be afraid: there is a template for new use cases and a bunch of examples.
FIFE use cases

1. Would you use a premade ISO 2D engine for your game project at all? If you don't consider this as an valid option, regardless of the features the engine would provide, please elaborate on your reasons.

Absolutely. In the last couple of years, I have found that my programming time has been acutely cut short; more and more I find myself looking for solutions which allow me to focus on developing the 'game' part of my game, rather than the 'engine' part.

2. What kind of features should this engine support so that you would consider using it for an game project (commercial or non-commercial).

- Seamless-transition large-map support (see classic Ultima) is a must
- Height maps for terrain would be nice
- Seasonal graphics (e.g. some textures swapped out during seasonal changes from winter->spring->summer->winter)
- Day/night transitions and appropriate lighting

Audio:
* What kind of audio codecs should the engine support?

- Something unrestrictive, which allows for simple management of sounds.
- Something which offers environmental effects (e.g. EAX) or at a minimum, reverb/echo/chorus.

* What kind of audio features should the engine support (stereo, "3d sound", etc.)?

- Stereo. In a 2D game, 3D spatial sound just doesn't make sense, and usually isn't pulled off elegantly.

Font rendering:
* What kind of font formats should the engine support (ttf, bitmap fonts, other font formats, etc.)

- It should definitely support TTF
- Bitmap fonts are nice, but you should also provide or provide links to a (GPL/open source) tool used to create the fonts. Using an obscure requirement to calculate font dimensions is a bit off-putting if the tool you used costs more than the developer is willing to spend on a single tool.

Graphical user interface:
* What kind of features should the GUI support [e.g. dragging widgets, widget transparency, etc.)?

- Icon boxes (see below), animated widgets

* What kind of basic widgets would be needed for your game?

- All standard widgets (buttons, sliders, textboxes)
- Multi-line selectable text boxes
- Icon boxes (e.g. similar to Windows Explorer in Icons view mode, with similar functionality)
- Some sort of paperdoll functionality (could be a combination of bitmap-image box with 1x1 icon boxes for placement, or whatever). This can be useful for tech-trees in RTS as well as standard equipment config windows found in RPGs.

* What kind of 3rd party GUI library would you like to use for your game (QT, WxWidgets, CEGUI, etc.)?

- Regarding CEGUI, I have yet to see decent documentation for customizing the default widget-set. I'd recommend against it until they get their documentation together.
- Don't know much about QT, wxWidgets is nice if you can get one of the editors to work for you.

The list goes on for rendering features (e.g. different render backends like OpenGL, SDL or DirectX), animations, input management, the map format, pathfinding, scripting, movie support, virtual file system handling and other misc. features like an console for ingame debugging / script tests.

- I would only be interested in SDL+OpenGL rendering, since DirectX will tie the rendering to a particular platform.
- Standard animation features, perhaps with label-able animation sets
- Encrypted "PAK-file" archive system for media loading
- A* pathfinding would be a major plus
- Scripting via GameMonkey would be a major plus, Lua would be secondary (I personally prefer GM's syntax)
- Input system should allow customization of command-keys
- Map format should either use an open, standardized format (e.g. XML) so that third-party tools can be developed for the community BY the community, or else provide tools for building, heightmap/tilemap conversion, etc.
- Movie support implies the development team has a decent 3D animator. Perhaps more interesting would be a scripting interface to create in-game movies (thus less requirements in the modeling department). Thus, movie support is "nice", but don't go all-out supporting every single format out there (or else, use a multi-purpose library).
- A ~ debug console is a must.

Most important: we would like to know if you would use an GPL'ed engine even for a commercial project (that perfectly possible as you would need to open source certain parts of your code but you would charge for the content you've created in this case).

- Absolutely!

Best regards,
- DH

1. Would you use a premade ISO 2D engine for your game project at all? If you don't consider this as an valid option, regardless of the features the engine would provide, please elaborate on your reasons.

No, I generally prefer to code as much as possible myself (within reason). In the case of something not too complex, the time invested in coding isn't that much compared to the time needed to figure out how to use existing code and the benefits are huge.

Working with your own code is great because everything makes sense, you know where to find the cause of the problems quickly and it's much more satisfying.

Using third party software often makes me feel like a cheater, (unreasonably so, I know - but it does nonetheless). But hey, an A is an A. I'd use it, definitely. I spent all my years in High School making various 2d engines, so I wouldn't mind using someone else's next time around.

LGPL would most certainly be preferred, but I'll take GPL if I had to.