JUICE for C++ - Possible library for the AGS editor

[Joseph DiPerla]

Website: http://www.rawmaterialsoftware.com/juce.php

What is it:
JUCE (Jules' Utility Class Extensions) is an all-encompassing C++ class library for developing cross-platform software.

It contains pretty much everything you're likely to need to create most applications, and is particularly well-suited for building highly-customised GUIs, and for handling graphics and sound.

Supported systems:
JUCE can target the following platforms:

    Mac OSX - Applications and VST/AudioUnit/RTAS/NPAPI plugins can be compiled with Xcode for OSX 10.4 or later.
    iOS - Native iPhone and iPad apps can be built with Xcode.
    Windows - Applications and VST/RTAS/NPAPI/ActiveX plugins can be built using MS Visual Studio. The results are all fully compatible with Windows XP, Vista or Win7.
    Linux - Applications and plugins can be built for any kernel 2.6 or later.
    Android - NEW! Android apps can now be built using Ant and Eclipse, with the Android NDK v5 or later. (This is still a work in progress, so some features aren't still to be finished).

For all the platforms above, the code that you write is the same, and you don't need to worry about any platform-specific details. If your C++ is portable, then you should be able to simply re-compile your app to run it on other OSes.


Design and coding style:
In designing JUCE, I've tried to make it:

    Literate - class, method and variable names are clear, self-explanatory and consistent. It's vital in such a large library that when you look at a class, it should be obvious how it works; and when you use a class in your own code, the result should be as readable as possible. The best way to achieve this is by using well-written names.
    Coherent - a library needs to be predictable enough that once you've got a feel for the way things are arranged, you can navigate around it without any surprises. If you need to do a particular task, you should be able to guess what the classes to do it might be called and find them quickly. (Having a single person write the entire library helps with this!)
    Cross-platform - platform-dependent code is all confined to a single area and kept out away from public view. When you include juce.h, you only include pure C++ classes, it won't pull in any platform-dependent headers. Wherever it's possible to use a pure C++ technique instead of native functionality, I've done so.
    High Quality C++ - having been a professional C++ coder for 15 years, and having studied all the available C++ guru literature, I think I'm finally starting to get the hang of it! Every class in the library is intended to be a good example of the best possible coding practices - so if you spot anything dodgy in there, don't hesitate to let me know!



Integrating into a project:
Adding JUCE to your app is very simple - the easiest way involves simply including juce.h in your files and adding a single cpp file to your project. No need to compile any libraries or worry about dependencies. Ideally I'd like to have made JUCE an include-only library like the std c++ library.. that's not actually possible because of the platform-specific nastiness that it has to deal with, but to be able to add a complete multi-platform library to your app in only two steps is a pretty good result!

Of course JUCE can also be built as a static library and linked into your application in the traditional way. Or you can use it in its 'amalgamated' form, where the entire library (all 350,000 lines of it!) has been cunningly compressed into just two (large!) source files. Having only two files to deal with means that you can easily add a local copy of them to a project and check them into your source control system, avoiding any external dependencies.

To further simplify the process of building across multiple platforms, the Introjucer will automatically generate all the compiler-specific project files you need to get the same app running in Xcode, Visual Studio, etc. Just use the Introjucer's IDE to build your project, and it'll take care of the hassle involved in keeping several different IDE projects in sync with each other.



License:
JUCE is released under the GNU Public Licence, which means it can be freely copied and distributed, and costs nothing to use in open-source applications.

If you'd like to release a closed-source application that uses JUCE, commercial licences are available for a fee - click here for more information on pricing and terms.

[Sslaxx]

It's the license that lets it down. Same issue as with FMOD, unfortunately.

[Wyz]

Yes that is exactly my issue with Juice, otherwise it would have been a really nice library.

[Snarky]

We could have bought a commercial license with the Bake Sale money, but NOOO! You had to go and give it away to sick kids! 

(But seriously, if there's any commercial library out there that could really make development a lot easier, I'm sure we could scrape together a few hundred bucks for a license.)

[Sslaxx]

We could have bought a commercial license with the Bake Sale money, but NOOO! You had to go and give it away to sick kids! 

(But seriously, if there's any commercial library out there that could really make development a lot easier, I'm sure we could scrape together a few hundred bucks for a license.)

But that brings licensing issues for games created with AGS.

[Snarky]

Maybe? I think we could probably get a commercial license that would cover games made with the engine. It's not altogether clear that games made even with an AGS subject to GPL would themselves be affected by GPL (apart from a need to include a link to the AGS source in their distribution); the ScummVM guys don't think so, though that's possibly conditional on details of how the compilation and bundling of files is set up.

[Joseph DiPerla]

This is what I see in the license:
JUCE is released under the GNU Public Licence, which means it can be freely copied and distributed, and costs nothing to use in open-source applications.

This is what it means to me:
AGS Editor and AGS engine are two different entities as far as I am concerned. Both are open source. The above states that it costs nothing to use in open source applications. It also states it can be distributed freely.

As far as I am concerned, JUICE would not be used in the games being distributed or sold. Only in the already FREE editor. As far as the editor goes, to me its similar to an app such as Eclipse or Visual Studio. Its mainly used to develop the game. Not run it. Its components are not used in the games itself. So the way I see it, it would still be a viable option for the AGS editor.

If worse came to worse, perhaps we can raise money for the unlimited license.

See, this opens up the editor to be made for Windows/Mac/ Linux as well as some portable devices such as the IPAD and Android tablets for game development on the go. Its a good first step in using code thats highly portable.

[Wyz]

Oh for the editor? Sure, that would be great.

[Calin Leafshade]

The editor is in a pretty good shape and rewriting it should be a pretty low priority.

A better idea IMO would be to seperate the editor and the compiler. If the compiler were pure C++ instead of the mixed mode assembly it currently is then the editor could be run in mono which is native to Mac, linux and windows. Then we just compile the compiler to be native to each os and attach the editor to the game exe similar to the way that gdb does. That way we can leave alot of the editor code alone and preserve the pretty clean codebase.

[Sslaxx]

The editor is also nearly entirely written in C#, and I don't think JUCE has .NET bindings.

And I've been banging on about separating compiler and editor for ages now. Nice to see someone else agrees with me.

[Joseph DiPerla]

Yeah, I kind of implied the same idea. My ideal dream of this whole project would be seperate editor, compiler and runtime. Atleast then someone can just port the compiler and engine to different OS's and then editors could be written by different individuals.

[splat44]

We could have bought a commercial license with the Bake Sale money, but NOOO! You had to go and give it away to sick kids! 

(But seriously, if there's any commercial library out there that could really make development a lot easier, I'm sure we could scrape together a few hundred bucks for a license.)

But that brings licensing issues for games created with AGS.

I see no problem helping sick but why doesn't bake sales donate certain percentage of receipt towards licencing?

Sslaxx, if what I am proposing comes through then will there be licencing issues?

Regards

[RickJ]

if what I am proposing comes through then will there be licencing issues?

Presumably:  Commercial License != Artistic License Comparability.

But seriously, if there's any commercial library out there that could really make development a lot easier, I'm sure we could scrape together a few hundred bucks for a license.)

IMHO, QT is a better choice, no fee, LGPL license which is compatible with Artistic License according to gnu.org

Artistic License 2.0 (#ArtisticLicense2) - This license is a free software license, compatible with the GPL thanks to the relicensing option in section 4(c)(ii).

http://www.gnu.org/licenses/license-list.html#Introduction

[Snarky]

IMHO, QT is a better choice, no fee, LGPL license which is compatible with Artistic License according to gnu.org

Artistic License 2.0 (#ArtisticLicense2) - This license is a free software license, compatible with the GPL thanks to the relicensing option in section 4(c)(ii).

http://www.gnu.org/licenses/license-list.html#Introduction

"GPL-compatible" just means you're allowed to use it in a GPL-licensed product. In other words, you're allowed to change the license to GPL.

The problem is using GPL or LGPL code and still releasing AGS under the Artistic License 2.0. That's not allowed (or in the case of LGPL, only allowed under restricted conditions that may be hard for us to fulfill). We could dual-license the AGS code itself, but since it wouldn't work without Qt, in practice we'd pretty much have to switch to GPL or LGPL. That's why GPL is sometimes called an "infectious" license.

And that in turn might be problematic for commercial games, because unless we made some major changes to how games are compiled, linked and distributed, it could mean that all AGS games would have to be open-source (though there are different interpretations of LGPL on that point). At the very least it would make many commercial companies skittish.

[RickJ]

Here is what Qt says about it:
http://qt.nokia.com/about/licensing/frequently-asked-questions#what-is-the-lgpl
http://qt.nokia.com/about/licensing

The LGPL does permit users to license software programs that merely link with the LGPL licensed library under different license terms provided certain requirements are met. In essence this means that Qt users may create proprietary applications that dynamically link to the LGPL-licensed Qt libraries provided he or she adheres to the requirements of the LGPL.

- Dynamically link to the library
- Qt copyright notice, LGP, GPL text in distribution files
- Offer to provide QT libs from QT or AGS websites

If this gets more serious consideration it wouldn't hurt to send an inquiry asking for confirmation/clarification in AGS specific situation.  

[edit]
@Calin:

A better idea IMO would be to seperate the editor and the compiler. If the compiler were pure C++ instead of the mixed mode assembly it currently is then the editor could be run in mono which is native to Mac, linux and windows. Then we just compile the compiler to be native to each os and attach the editor to the game exe similar to the way that gdb does. That way we can leave alot of the editor code alone and preserve the pretty clean codebase.

I think this is a good idea.  There would need to be a well defined and easy to work with output from the editor.  There would also need to be seamless integration with the native engine to maintain the current fast and edit-compile-test cycle.  Conceivably a compiler could be made that produces ScummVM compatible game binaries.

[Wyz]

First a note no LGPL: It will not allow static linking, so tucking everything nicely into one executable is not allowed with that license (if you want to make a closed source engine build).

Using Juice or Qt for the engine would be nice, because both libraries make use of native window APIs and aide very much in portability. But since the current editor is rather new and still works very well it would be a waste of resources to build a new one, or port the existing one. Eventually it might be a wise thing to do, but it is too soon to tell I guess. Having the editor output different formats like a scummVM compatible format and (oh joy) A HTML5 based format would be really cool. Oh, right, that is rather off topic. 

[Shane 'ProgZmax' Stevens]

Maybe? I think we could probably get a commercial license that would cover games made with the engine

If you can find a development platform that allows you, with a single purchase, to have unlimited control over distribution (this includes giving copies out to everyone who wants one for development) and commercial production I may buy a hat just to eat it, because it would simply make no sense for someone to license a piece of software for purchase while allowing unlimited free distribution and re-use of said software.

They'd get maybe a handful of purchases before it was everywhere for free, so it doesn't seem realistic to find development tools that require a purchased license for a freely distributable engine like AGS.  Even the most generous commercial licenses limit it to a single company (those are the ones that don't limit you to the production of x games!).

The only real way forward if you're looking for tools or libraries is completely free and open for use and distribution, otherwise it will just be a big mess.