• Advertisement
Sign in to follow this  

Unity Would you use a premade isometric engine for your game?

This topic is 3940 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Our team is currently working on an 2D isometric engine with focus on supporting typical RPG-features. Now we've got some questions for the ISO audience here to get a better impression what kind of features are important to our potential "customers" (the engine is free of charge, so "users" is prolly the better term). 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. 2. What kind of features should this engine support so that you would consider using it for an game project (commercial or non-commercial). Here is a bunch of sub-categories that should help you and us to get better structured and more detailed feedback: Audio: * What kind of audio codecs should the engine support? * What kind of audio features should the engine support (stereo, "3d sound", etc.)? Font rendering: * What kind of font formats should the engine support (ttf, bitmap fonts, other font formats, etc.) 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.)? 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. 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). We would like to thank everybody who takes part in this survey in advance. This kind of feedback will hopefully help us to turn FIFE into a serious solution for ISO games even for indie developers. [Edited by - mvBarracuda on July 9, 2007 4:51:05 AM]

Share this post


Link to post
Share on other sites
Advertisement
Yes, I definitely would!

Except I already wrote my own. :(

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement