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.
Would you use a premade isometric engine for your game?
Author
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 :-)
Author
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
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?
Author
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 :-/
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
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.
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.
Already supported :-)
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.
The same goes for these two: a scripted solution should work fine for this, no need to touch the C++ side :-)
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.
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?
It shouldn't be that hard to add a city screen by combining some GUI widgets together :-)
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.
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
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
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.
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.
LGPL would most certainly be preferred, but I'll take GPL if I had to.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
