Facade-Unigine notes

Overview

Facade is presently based on Ducttape, a FOSS game engine. Some Facade developers lean towards switching from Ducttape to a different game engine for various reasons. Sythe has placed a switch to Unigine, a commercial framework, on the table. This document discusses some of the issues involved.


Arguments for and against Unigine

a. Pro. Technical issues. There are at least two technical issues that are viewed as crucial.

One issue is the presence or absence of a ready-to-use editor. Ducttape has not worked out in this regard and progress on an editor at the Facade level is quite slow presently. As a related note, development of an editor is outside the scope of what the Facade project should focus on. Unigine provides an editor.

  • OldCoder is sympathetic to this point.

Another issue is native Linux support (as opposed to support through Wine). If Facade does switch to a new engine, it may be a closed-source engine. This is a negative from a Linux marketing perspective. If the game also doesn't have a native Linux version, there won't much that's "Linux" about it. It will simply be a Windows game that happens to be compatible with Wine. Marketing in the Linux sector may be difficult.

  • OldCoder acknowledges this issue but doesn't have a strong position.

There's some debate about how well Unigine works with indoor scenes.

  • kloplop321 says Unigine handles large outdoor scenes well but he has reservations about performance and appearance with internal environments. He cites the differences between convex methods (outdoor) and concave methods (indoor). Asserts that Unigine is optimized for the former as opposed to the latter.
  • sythe points out that Unigine has had an indoor system since 2006 and cites this link. However, he expresses interest in what people know about the state of the indoor system today.

b. TBD. Business model issues.

c. Pro. Unigine was researched previously. It was actually the original first choice for the Facade game engine. It was passed over due to cost issues (which are discussed below). The hope now is that cost will turn out not to be a factor; i.e., the goal is for Facade to obtain a free or discounted Unigine license.

d. Pro. The Unigine project is robust than the Ducttape project and more likely to move forward with enhancements on a timely basis.

e. TBD. Unigine may have license issues that preclude this framework as a reasonable choice. There's a claim that Unigine may structure things in a way that gives the publisher undue control over games that use the framework. The company may be able to delay or deny Facade the right to distribute a release if a dispute of some kind arises.

  • Point was raised by kloplop321
  • sythe responds that this shouldn't be an issue. In theory, the worst-case scenario should be that the publisher will withhold marketing support

f. TBD. If a change is to take place, other candidates for engines should be evaluated. Most people agree on this. This isn't precisely an argument against Unigine but there's a consensus that the decision shouldn't be rushed.

  • ChocoboMaster suggests Unreal as a candidate.
  • kloplop321 suggests Unreal and Nebula3 as candidates. He favors Unreal over Nebula 3 over Ducttape over Uniengine. In other words, Unreal is his top choice and Uniengine his least favored. For more about Unreal, see kloplop321 comments section below.
  • Malexos is new to the concept of game engines and isn't able to make an informed suggestion at this time
  • If a commercial framework is used, OldCoder would like to evaluate Nebula3 due to the fact that it's apparently both a commercial framework and highly unencumbered FOSS (MIT/X license). Interesting combination. He's unsure about Unreal due to lack of Linux support. Additionally, he'd recommend a FOSS framework if possible to avoid shifting standards and lock-in.
  • sythe states that a number of candidates were evaluated in the past. He cites a list that is posted later in this document
  • sythe has native-Linux concerns related to Unreal and missing-editor concerns related to Nebula3.

g. TBD. There's apparently some overlap between the Facade and Ducttape groups. And little or no overlap between the Ducttape and Unigine groups. It's possible that the switch might cost Facade one or more developers or community members. Are new people expected to join because of the switch? What is the net change likely to be?

  • kloplop321 feels that no developers would be lost.
  • Malexos feels that Facade developers should be contacted before any switch occurs to determine whether or not they'd wish to continue with the Facade project after the switch and in what capacity.

h. TBD. Unigine is proprietary and expensive though the company may provide a license at no charge in some cases. Details about this issue need to be checked. Note: A typical license can apparently cost about $30,000.

  • sythe implies that Unigine is only likely to be used if a free or discounted license can be obtained.

i. TBD. Unigine is closed-source. This means possible problems with lock-in and shifting standards in the future. Ducttape, on the other hand, can be patched or even forked if necessary. This seems like a strong argument for remaining with Ducttape. Important: This is about practical issues and not whether Open and Closed Source are "good" or "bad".

  • OldCoder feels that lock-in and shifting standards should be avoided to the extent possible.

j. TBD. Is there a technical debt? How much of the current code would need to be changed? Could the current artwork and other media be moved over without difficulties? Are there people who are willing to deal with these issues?

  • ChocoboMaster states that artwork can be moved without significant difficulties.

k. Con. One of the reasons behind the choice of Unigine is support for native Linux builds. Perhaps the native Linux market is not important.

  • djdduty questions the significance of the Linux gaming market
  • kloplop321 cites the availability of Wine as an alternative to Linux builds
  • sythe has researched the Linux gaming market and feels that it is at a turning point

Conclusions

The group was open to a change. The consensus was that things should be researched and discussed first.

These options were considered, among others:

  • No change. Not viable due to lack of resources needed to complete editor.
  • Nebula 3. Not viable for now because of the lack of a native Linux port. Additionally, status of editor isn't clear.
  • Unreal. Not viable for now due to lack of a native Linux port.
  • An unnamed FOSS or commercial framework, other than the above or Unigine. Not viable for now because no alternatives that meet the constraints have been proposed that have consensus.
  • Unigine. Default choice due to lack of alternatives. Next step will be to review cost and licensing issues.

Notes on Nebula3

Nebula3 was previously a commercial project but is now licensed under MIT/X. This means that in theory the engine could be taken closed-source.

The downsides for Nebula3 include:

  • A native Linux port is possible but may require some work.
  • Framework is orphaned. Tradeoff is that Facade could assume full ownership and even close-source the code as noted above.
  • An editor is provided but its status is unclear.

kloplop321 says (paraphrase):

  • Nebula3 doesn't have a native Linux build. However, it has OSX and supports OpenGL, so a port might be easy.
  • Nebula3 does indeed have an editor but it looks like it is Windows-only. It uses the Direct3D9 run-time and I'm having difficulty getting it to work under Wine.
  • I've tried the editor under Windows. It runs but I haven't figured out how to create new objects or even how to select existing entities to modify them.
  • The data structures in Nebula3 are really extensible and there are several utilities.

A few Nebula3 links:

A live Nebula3-related project - recently updated http://focus.gscept.com/nebula/
A Nebula3-related weblog http://flohofwoe.blogspot.com/
RedAgito code https://bitbucket.org/RedAgito/nebula-3-game-engine/src
Version at Google http://code.google.com/p/nebula3/
Application Layer notes click here

Thumbnail:
click here or on thumbnail for full size
nebula3_editor.jpg

Status: There does not appear to be a native Linux port readily available.


Frameworks reviewed previously

These were considered to be possible candidates:

Unigine: Robust project, native Linux support, editor made this one attractive. But it was passed over originally due to potential cost and/or license issues.

Cryengine 3: Passed over due to potential cost and/or license issues.

Esenthel: No comments.

Vision Engine: Looked very promising. Royalty-based, so free for non-commercial use, and also cross-platform.

Source Engine: Completely free, uses great physics engine, Havok. ot Linux-compatible until Postal 3 is released, old engine.

Unity: Very popular and powerful. However, neither cross-platform nor open-source.

Spring Engine: More research needed. Not designed for single-player first-person games. Used more for RTS games.

C4 Engine: No comments.

Hero Engine: Rreal-time collaboration, designed for MMOs, not free.

PixelLight: Open-source, good graphics, uses C++, cross-platform, actively developed, no editor whatsoever, possible performance issues.


More frameworks

These were considered to be less likely possibilities:

Grit Engine: Designed specifically for open-world games such as GTA.

Irrlicht3D: Open-source. (Not a game engine, its a graphics engine that is all)

Panda3D: Uses Python. Definitely an issue; too highlevel.

Unreal: Not considered cutting-edge. Not cross-platform.

TR Engine: Very new, designed for open-world MMOs. Used OGRE3

Neoaxis: C# (not an option).

Maratis: Questionable capabilities. Used Lua.

Axiom3D: C# but open-source. OGRE3D-based. Probably not an option.

Spring Engine: More research needed. Not designed for single-player first-person games, More for RTS games.

IDtech 5: Was neither released nor open-source yet.

IDtech 4: Released, but not yet open-source and not many capabilities.

Marathon: Ancient and crappy GFX.

Cube 2-based engines: Does not support what facade needs.

Gamebryo: Not an option. "PERIOD." No details mentioned.

DimensioneX: Designed for MMOs, not impressive.

Xreal: Development completely halted but cross-platform. Probably not an option.

Torque3D: Questionably cross-platform, not very capable.

Delta3D: Dead engine, last release was over a year before.

CrystalSpace3D: Lacked basic features.

Blender Game Engine: Not an option. No details mentioned.

Allegro: Just a collection of libraries, not even an engine.

Make a new engine: Not an option.


Summary of community views

Note: Just one to three sentences per person:

ChocoboMaster: Favors a move but suggests Unreal as an alternative to both Ducttape and Unigine.

clynamen: TBD

d3str0y: TBD

djdduty: TBD

EternalWind: Favors a move but has no idea which engine would be the best choice.

kloplop321: Favors a move but suggests Unreal as an alternative to both Ducttape and Unigine

Magns: Favours a move because of reduced development time and increased focus on the game it self. Perfers any engine with good audio integration; esp. with convolution reverb with impulse responses included.

Malexos: Would like things to be considered, explained, and discussed with group members before a change is decided upon. Would prefer not to switch engines purely for aesthetics.

OldCoder: Evaluating and could presently go either way

sythe: Favors a move to Unigine.


Comments from interested parties are solicited.

Comments may be edited or moved. If anything attributed to you is wrong, apologies and correct the mistakes.


ChocoboMaster comments

The artwork/models could all be moved to another game engine really easily.

I don't know much about Nebula 3. Concerning Unigine, it doesn't handle inside scenes very well.

I'm not against changing from Ducttape to another engine but I'd prefer to move to Unreal and I'd put Unigine below that.


clynamen comments

I'm ready to change the game engine and I'm also willing to abandon the linux support.
However I'm a little worried about the license issue. A non free game means to face up to responsabilities that I'm not ready to face.


d3str0y comments


djdduty comments

Linux consists largely of developers who are more interested in writing software than games. If you make a game, Linux users may not care much, because they are developers, not gamers. Also, most developers have windows anyways to test their games,

On the non-developer side, most Linux people do not want to buy anything. Linux is about "Live Free or Die".

Gamers will spend money; but I don't believe they will whilst on Linux. Only to support other developers, like you see in the Humble Bundle. But if you look at game sales, developers can gain 30% from porting to Mac and maybe 2% to Linux.

To summarize, I don't think the Linux gaming market is crucial.


EternalWind comments

Since Ducttape is no longer under active development and it is not completed, I think it is a good decision to move on to another engine. Due to the lack of experience in game development, I have no idea which one will be the best to use. However, I think what we should focus on more is the playability instead of graphics only and I don't care much about whether it has native support for Linux or not.

If we are going to use Unigine, I think we need to make sure the license is acceptable for the team. And for unreal, I doubt if we can learn it easily because its API documentations are not available for free users.


Kloplop321 comments

Unigine has proven itself to be a great out-door engine. However, I believe that although it handles vast scenes with a lot of assets, I question how well it performs and looks with internal environments.

External environments are easy when it comes to the visual effects, because you can still look good while using the theory for convex shapes in an open environment.

The issue however is when you are in a concave environment, where it is easy to notice inconsistencies when everything is close together. Your tool set for aesthetics and consistency is significantly reduced with an engine which has been designed and optimized for an outdoor experience.

Additionally, I think that it is flawed to suppose that because the Unigine demo and a particular game have impressive visuals, that by using the engine you can have the same quality. The company behind Unigine has experienced, seasoned staff. The team behind Facade does not have this benefit. The engine does not make the experience; it only assists the artists, writers, and programmers to convey an experience.

I see a potential problem with Unigine related to license issues. They may not want to allow a game to be released if it reflects negatively on their engine; and the way things are structured, they may have the final say.

This bothers me. If you can't livee up to their standards, not only will your team's motivation decrease because you feel like you're up against an artificial barrier. I also feel like there would be a significant debt in time, money, and skills invested with nothing that you can publicly show because of the nondisclosure agreement I foresee. I think deadlines might need to be pushed due to this and ultimately demotivate the team.

I'd push for the use of the Unreal engine, because

  • It's proven agnostic to inside and outside environments.
  • There's nothing to lose financially, IIRC you get the first $30K in revenue, and then you start paying royalties, which only happens after you've effectively proven your product is worthwhile from the buyers perspective. The buyers are the ones who make the decision and not the framework publisher; this is important.
  • Unreal has an effective scripting engine. It even allows asynchronous sleeping.
  • Unreal has a lot of pre-packaged effects available to use. This means you can get working on the game quickly and address polishing and customization later.

Unreal may not be ultimately 'cross platform' but Linux guys at least know that a lot of Unreal engine games work in Wine. We already know it works on Mac.

I favor Unreal not because I have a personal like for it, but because I think it is important for the first game of a team to be completable with the least amount of "fighting with the tools", this is about motivation and practical virtues.

"Fighting with the tools" for me refers to how much work goes into implementing, or working around other's work, instead of iterating at a productive and motivating rate. The commercial frameworks facilitate things in this respect. Note: "Fighting with the tools" includes the lack of tools.

Respective to Unreal, Nebula 3 doesn't come with a lot of prepackaged things you can use to speed up development.

I don't think any developers would be lost, there aren't many anyway. Ducttape and Facade only have cross-over because Facade's team sometimes contributes to Ducttape. It is only one direction, not the other way.

I'd like to emphasize that the reason behind my opinions here is that getting a complete product done while remaining motivated and not being forced is more important than looks, or platform availability, or personal ideals. Then once the product is done, polish the heck out of it behind non-leaky doors and finally release


Magns comments

The licensing issues with Unigine does not sound good, and neither does the price. The demo however, looks great, but as a layman when it comes to game engines, I'm guessing that it is more because of the designers, modelers, and texturers. I would go for a different engine.

I also think choosing an engine with good audio integration is key. I have a feeling we don't have the resources to get a satisfactory result here with our own engine. Especially concerning reverb; where we have the choice of creating a reverb algorithm, which is incredibly hard to get to sound realistic, or convolution reverb, where we have to use recordings of real locations.


Malexos comments

I don't know much about game engines, but the proposed move does concern me. It appears that the main reasons for changing engines is aesthetics, the ability to sell the game, and perhaps added functionality. If I'm wrong, please correct me.

Just because the game will look prettier with the new engine doesn't necessarily mean that we need the change. This would be the team's first game together, and I'd rather not get into the habit of getting all the latest toys and gadgets for a game before it has a solid foundation. I've heard of a few indie game projects failing because the developers wanted to add a crazy amount of features, but didn't really get the foundation in place fifrst. I don't want to be like those developers. I'd like us to do the very best we can without superfluous additions.

I'm also a little concerned that the engine is a case of "kid-with-a-ball". I write music. I want a fancy Digital Audio Workspace program like Logic or Cubase or Pro Tools. I want a nice studio microphone so I can record live instruments…but I'm an amateur composer. I don't need all of that right now. All I need is Finale 2011 and a pirated copy of Ableton Live to do everything I need to at the moment. But when I get better at the art, when I have a better foundation, and if I ever make a career out of composing I'll definitely have sufficient reason to shell out thousands of dollars for the extra stuff.

In the same way, it could be that everything Facade needs can be done with an engine that doesn't cost us $30,000 — but we don't know if that's true or not because the game doesn't have the solid foundation I mentioned yet. We don't even really know what the primary game mechanic's function is going to be. I think when we have a more solid idea about Facade, we'll have an idea of which engine we should be using.

Furthermore, I'd much rather create an awesome game made with a sub-par engine than create an okay game that looks pretty because of the engine. In this case, I vote for substance over style. If it turns out that we can make an awesome game with an upgraded engine, I would be more than happy to switch. I'm just not certain the switch is completely necessary because I'm missing the answers to the questions posed in this page's main article.

TL;DR version: Let's change engines only if it's truly necessary for the development of the game. I wouldn't be in favor of moving to an expensive engine if the game could be just as good with a cheaper engine.


sythe comments

sythe's comments have been integrated into the main text.


Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License