The future of the AGS engine: STALEMATE!

Started by monkey0506, Sat 23/07/2011 11:10:40

Previous topic - Next topic

bero

Quote from: Snarky on Wed 11/01/2012 13:34:50
Although the SDK is 1.6 GB, the full library binaries are only around 275 MB; I don't know how much space just the libraries we need would take, assuming we would include core, winmain, gui and probably multimedia and opengl; I could also see uses for network, svg and perhaps xml.

On my 64-bit Linux box:
QtCore 2.9 MB
QtGui 11.2 MB
OpenGL 1 MB
QtNetwork 1.3 MB
QtSvg 365 kB
QtXml 276 kB

Of course those are built with all features enabled, so this could be stripped down.

Quote from: Snarky on Wed 11/01/2012 13:34:50
From what I see online, the smallest statically linked application execs, which exclude almost all parts of all libraries, are about 1.6 MB on windows. We'd need more than that, although we could probably disable most of the gui widget stuff (which takes up a lot of space). I'm guessing about 8 MB minimum for a Qt-based AGS engine. With dynamic linking this could be reduced, but users would need the 275 MB dll file to run any game.

They don't need the full SDK - they could just grab a set of DLLs provided by us, which should be around 17 MB (sizes of the libraries I posted above added up).
On Linux, this is a non-issue anyway because Qt is included in almost every Linux distribution anyway.

Furthermore, The Qt LGPL license imposes some clauses once you link the library statically; I think we would be OK as long as AGS remains open-source (which would be a requirement!), but it could be interpreted as requiring game makers to open-source their games as well.

Quote from: Snarky on Wed 11/01/2012 13:34:50
And in terms of platform support, Android is only in alpha, and there's no iOS support at all (which SDL and Allegro both offer).

There is a port of Qt to iOS, and it's going to be merged into official Qt.
http://labs.qt.nokia.com/2011/08/09/update-on-uikit-lighthouse-platform/

Quote from: Snarky on Wed 11/01/2012 13:34:50
Going with Qt is certainly not going to solve all issues with portability and the state of the engine source by itself, and my understanding is that it would require a complete rewrite e.g. to use the Qt data types.

You can mix Qt data types with traditional data types - but casting around obviously loses some features (e.g. the fact that QString is unicode based doesn't help much if some functions just take a plain old char* and expect it to be in ASCII).

Snarky

Quote from: Calin Leafshade on Fri 13/01/2012 23:31:25
As for my reservations about a commercial leader, I think Sslaxx summed up my position well enough.

"Balancing the needs of AGS's commercial users versus the noncommercial users is not going to be easy. Being noncommercial (open source) itself means that AGS is not necessarily beholden to prioritise commercial users' needs."

A commercial user's interests are going to be about the bottom line and short term. Essentially "I have all these programmers available for free, what should they do that increases my bottom line". Thats not to say that that would necessarily be bad for AGS but it's something consider carefully.

A project lead who thought like that wouldn't have programmers working for free very long.

I would suggest that commercial users are as capable of thinking long-term as any other, and that many small businesses in fact do a lot of altruistic (or "altruistic," if you prefer) community support that doesn't directly benefit their bottom line, like sponsoring the local children's sports teams and other activities.

Even if Dave was completely unscrupulous and had no integrity, I'm sure he'd see the self-interest in not alienating a community his company draws on for talent and testers, that generates a fair bit of internet press for his products, and that provides a small but hardcore segment of his market.

Sure, in principle there are potential conflict-of-interest issues with having a project lead who's also the head of the primary commercial user of the product, but given that all the work is on a volunteer basis, the project lead can't force anyone to do anything: leadership depends completely on having the confidence of contributors. And for that, I can see reasons to prefer someone who's professionally committed to AGS (or at least adventure games) to someone for whom it's just a hobby. You can be more confident that they're not just going to get bored with it one day and walk away.

At this point, I for one would have confidence in Dave, like I would have confidence in you and in monkey.

Sslaxx

I think I may be being misrepresented here, because I wasn't clear.

Those are just viewpoints I threw out there. They're not necessarily what I think, but jump-off points for discussion. And when it comes to Dave, he seems a decent guy with integrity. I'd trust him with AGS.
Stuart "Sslaxx" Moore.

Wyz

Ok, I've read all so now I'll say a few things. :P

First of all, the reason why there is a plugin interface is so you can use features that are normally not supported by the engine. You wan't to make it as flexible as possible, and then you will always end up with dynamic libraries or static objects. There is no such thing as a binary that works on all platforms and no lib is going to fix that. There are frameworks to make it more uniform, SDL has one actually which is really worth looking into. Again SDL is released under a license that allows you to do much more, like static linking. I never really looked into the newest incarnation of allegro but I expect it to be similar. If you ask me, I'd say without doubt, one of those two would do. I think I'd pick SDL but that is only because I know it and have worked with it before. Stuff like endianness, loading images, working with audio, using both directX and openGL, multi-threading and locking mechanisms, and much much more. All we would ever need.

Now about the project manager thing, I'll just give my opinion and shoot me if you want to.
My first choice would have been Dave Gilbert because he clearly has used AGS successfully and therefore motivation to get the best from it. But he has a company to run and that would mean he has other responsibilities. So I was thinking by myself: who would Dave pick? And I though about it for a long time but I think I'd elect Gilbot. That just what my guts say, so shoot me. :P

As for the programming project itself, I've seen in the PMs and the replies in this topic there are a lot of programmers flocking here, none of them has enough time to pull it off, but all of them are selecting a part of the pie. I guess that is an important notion to take. We might have to do this in a very sharing way, each of us doing what they're good in. To that tune I'd like to point out my expertise are in software specification and networking. Since networking is not a very useful contribution: I can do abstractions, divide the project in modules and design meaningful structures for them. So yeah, that's my view on it I guess. :)

Please read my post.
Life is like an adventure without the pixel hunts.

Shane 'ProgZmax' Stevens

I would support Dave for project management because I've worked closely with him on projects and know he can get things done and he has a personal stake in improving the engine and making it more portable.  I don't see any conflict of interest that wouldn't exist with every other agser who uses the engine for its intended purpose and wants to see improvements made, so if it's something he'd want to do he would have my endorsement.

LimpingFish

#45
Quote from: Calin Leafshade on Fri 13/01/2012 23:31:25
A commercial user's interests are going to be about the bottom line and short term. Essentially "I have all these programmers available for free, what should they do that increases my bottom line". Thats not to say that that would necessarily be bad for AGS but it's something consider carefully.

Oh, I think that's a slightly cynical way to look at it.

Commercial interests might also result in, for instance, faster implementation of new features, improved stability, and a desire to evolve the engine to take advantage of the more modern computer environment, since these things would also be of huge benefit to such a user.

Somebody with a clear (commercial or otherwise) impetus to keep development moving, and focused, would seem like one of the better choices we could make for AGS.
Steam: LimpingFish
PSN: LFishRoller
XB: TheActualLimpingFish
Spotify: LimpingFish

RickJ

QuoteHaving to build separate plugins for each platform is far from ideal and not really a cross platform solution, IMHO.
I didn't mean to imply binary compatibility.  I was referring to the current state of affairs and implying that ideally plugins would have a common source code (without #ifdef hell) and a common dynamic linking mechanism. 

I think Dave would make a great PM and don't really have any concerns with regard to commercial vs non-commercial issues.  After all Dave was one of us way before he became one of them ;).

Calin Leafshade

To be clear, my reservations over a commercial interest in AGS weren't about skulduggery really (yes, skulduggery, you heard me). Also, I appreciate that a commercial entity would have similar goals to a non-profit one ultimately.

My concern was that the direction would be focussed on short term goals which instantly produce revenue (ports) rather than something with less immediate gains like code documentation or refactoring.

Having said that though, I would be happy to support Dave if he felt that he wanted the job and wouldnt contest his position.

Quote... plugins would have a common source code (without #ifdef hell) ...

The only windows specific code in the plugin interface is the entry point (and some windows specific library stuff like DirectAudio which would come out as a matter of course or could be abstracted out with a wrapper). The entry point would need to be platform specific no matter what we did wouldnt it?






AGD2

Just wanted to chime in and mention that I'd also be open to being involved to some extent. Although, it would probably be easier to share management duties between 1 or 2 reliable people due to the level of commitment required. I've been using AGS for a decade and have seen it evolve over the years (KQ1VGA started development in the DOS editor!) I also played a big role in helping CJ refine the first version of windows editor before it went public and lot of the features that are part of AGS today stem from various suggestions I made after running into brick walls developing the KQ2 and QFG2 remakes (i.e. regions, pamela lip-sync files, and a ton of functions).

I can also say, as a developer who has worked on both free games and commercial games with AGS over a long period, I think I have a fairly good concept of balancing the commercial interests of the engine against the non-commercial interests. It's true that commercial developers will want extra features added from time to time, but these additions aren't always mutually exclusive and non-commercial users will often find them useful as well. I also had the thought that if I (as a commercial developer) wanted specific features prioritized for commercial titles, I'd have the option to pay a programmer to implement those features faster and then roll them into the main source code. These features would, of course, be a donation to the AGS community at large and would be available to any user of the engine, commercial or otherwise, to take advantage of or build further upon.

Two big issues facing commercial AGS developers (portability notwithstanding) are the savegame incompatibility issue between versions (say if views are changed or integers added). And another thing I mentioned to CJ a while back, which he showed interest in, was some kind of in-built patch compiler for AGS that can compare the previous version(s) of your game to the current version to create small patch update files which only include the differences between versions. At the moment, AGS compiles its resources in an arbitrary manner so even commercial utilities don't always produce very small patch filesizes for AGS games.

Anyhow, just throwing this out there for consideration in case any of it would be helpful. I can see a lot of ways to make the engine more useful in the future and due AGDI's games being rather complex, we've had a penchant for finding undiscovered bugs in the engine, too. So if my feedback or contributions can help in the roadmap for AGS, let me know.

SchodMC

Quote from: Calin Leafshade on Fri 13/01/2012 22:42:52
RickJ:
Our SchodMC fellow seems to be capable of maintaining a mac port and has the skills necessary to do so and the impetus to follow through i think.
That's right. ;-) I want to take a closer look to the source code this weekend to figure out, what to do to make it Mac compatible.

One thing I realized will be the sound engine of AGS, which will be important for all platforms. E. g.: libdumb - which is used by AGS as I can see - was updated 2005 for the last time. I wonder if it would be a good choice to use the middleware fmod, which is available on Windows, Linux, Mac, iOS, Android and even XBox, PS3 and Wii. It will be complete free to use for an uncommercial project, but - and that maybe is the "no-go" for AGS - it's not open source. :-(

Or is the current state-of-project not fare enough to think about the sound? ;-)

Greetings
SchodMC

Sslaxx

Quote from: SchodMC on Sat 14/01/2012 12:10:03
Quote from: Calin Leafshade on Fri 13/01/2012 22:42:52
RickJ:
Our SchodMC fellow seems to be capable of maintaining a mac port and has the skills necessary to do so and the impetus to follow through i think.
That's right. ;-) I want to take a closer look to the source code this weekend to figure out, what to do to make it Mac compatible.

One thing I realized will be the sound engine of AGS, which will be important for all platforms. E. g.: libdumb - which is used by AGS as I can see - was updated 2005 for the last time. I wonder if it would be a good choice to use the middleware fmod, which is available on Windows, Linux, Mac, iOS, Android and even XBox, PS3 and Wii. It will be complete free to use for an uncommercial project, but - and that maybe is the "no-go" for AGS - it's not open source. :-(

Or is the current state-of-project not fare enough to think about the sound? ;-)

Greetings
SchodMC
The issue becomes commercial products using AGS. They would have to buy a license for FMOD, as might the AGS development team, and FMOD is single-product-per-license, single-license-per-platform and VERY much not-cheap; I would go so far as to say it is non-viable for AGS. I definitely oppose the use of commercial middleware like this with AGS. If LibDUMB support (or the lack thereof) is an issue on the Mac platform, we should investigate all other avenues first. OpenAL may be a good start.
Stuart "Sslaxx" Moore.

Calin Leafshade

As far as I can tell, OpenAL is really the only viable choice since it has a fairly permissive license and can be compiled on pretty much every system we would be interested in.

SchodMC

#52
Ok, I forgot the commercial games done with AGS. So because of them, FMOD is really no choice. OpenAL on the other side will be worth a try.

BTW, I think libdump won't be a problem for the mac platform. I only see a problem in using a library which development seems to be stopped. It can become a problem in the future. I think there are two options: a) find someone who will continue with the development of libdump, or b) replace the library with another (maybe not now, but it will be helpful to set it as todo on the roadmap).

Greets
SchodMC

//edit: for now I try to compile all necessary libraries under Mac OS X and then try to compile the AGS engine. So I have something to do on weekend. ;-) I will tell you whether it was successful or not...

Sslaxx

Quote from: Calin Leafshade on Sat 14/01/2012 12:38:14
As far as I can tell, OpenAL is really the only viable choice since it has a fairly permissive license and can be compiled on pretty much every system we would be interested in.
Seems to be that way. PortAudio - http://www.portaudio.com/ - appears to deal with just audio file I/O and Audiere - http://audiere.sourceforge.net/ - hasn't been updated in nearly six years (and uses LibDUMB in any case, meaning you'd still have that problem with Mac OS X), not to mention it being LGPL (with the static/dynamic linking issues that brings). libsndfile is also LGPL. SDL_mixer requires SDL, and unless you want to re-write the whole of the runtime and have everyone recompile their plug-ins etc. it really isn't an option.

Whilst I don't see anything on the Allegro.cc website about people have issues compiling Allegro (4 or 5) under Mac OS, that doesn't mean there are none.

Disappointing that options are so poor and so limited.
Stuart "Sslaxx" Moore.

JJS

Imho libdumb is not a problem at all. It is very easy to compile the library for different platforms because dumb itself doesn't have any dependencies (except for allegro for aldumb, but that is a given). The build system it uses is also just a simple makefile and no involved automake or cmake procedure. What I am saying is that I had no trouble compiling it for PSP and Android.

As far as plugins are concerned: I don't see how this could be handled better than it already is. Again, there was no trouble porting it to Android (using mostly the same plugin system as for the Linux port) and even to the PSP.
The three plugins I offer with the ports (AGSBlend by Calin Leafshade and my recreations of ags_snowrain and flashlight) are written so that they work on Android, PSP and Windows with a simple recompile.

edit: Concerning AGS on OSX, doesn't that already work? http://www.adventuregamestudio.co.uk/yabb/index.php?topic=43383.msg578827#msg578827
Ask me about AGS on PSP, Android and iOS! Source, Daily builds

m0ds

Cool comments. Some non-coding thoughts:

QuoteWhat would need to be taken into consideration for the future of AGS as a viable development platform?
* Commercial use - Wadjet Eye Games is the obvious company here; Himalaya Studios (AGDI) is another. Balancing the needs of AGS's commercial users versus the noncommercial users is not going to be easy. Being noncommercial (open source) itself means that AGS is not necessarily beholden to prioritise commercial users' needs.

AGS has gone through a decade of becomming more useable for freeware developers "and if you can use it commercially wahey", but I'd suggest now it had a go at being optimized for commercial projects. With real impotus the website/DB could be upgraded to sell games through it, for individuals, companies and charity drives...and maintaining a server, etc. As well as continue to showcase all the free games being made.

Freebie developers have a lot of options but commercial titles need more support, IMO. I realize CJ (used to) give out a seperate version for commercial games, and would hope that could become the license free edition for commercial users. And that - essentially - leaves no limits for the other version(s).

Sslaxx

Quote from: JJS on Sat 14/01/2012 13:57:43
Imho libdumb is not a problem at all. It is very easy to compile the library for different platforms because dumb itself doesn't have any dependencies (except for allegro for aldumb, but that is a given). The build system it uses is also just a simple makefile and no involved automake or cmake procedure. What I am saying is that I had no trouble compiling it for PSP and Android.

As far as plugins are concerned: I don't see how this could be handled better than it already is. Again, there was no trouble porting it to Android (using mostly the same plugin system as for the Linux port) and even to the PSP.
The three plugins I offer with the ports (AGSBlend by Calin Leafshade and my recreations of ags_snowrain and flashlight) are written so that they work on Android, PSP and Windows with a simple recompile.

edit: Concerning AGS on OSX, doesn't that already work? http://www.adventuregamestudio.co.uk/yabb/index.php?topic=43383.msg578827#msg578827
The issue is more with the fact that it hasn't been updated in so long, sooner or later it's just not going to work with the latest Apple SDK. So it could do with either being updated or replaced.
Stuart "Sslaxx" Moore.

SchodMC

Quote from: Sslaxx on Sat 14/01/2012 14:28:34
Quote from: JJS on Sat 14/01/2012 13:57:43
Imho libdumb is not a problem at all. It is very easy to compile the library for different platforms because dumb itself doesn't have any dependencies (except for allegro for aldumb, but that is a given). The build system it uses is also just a simple makefile and no involved automake or cmake procedure. What I am saying is that I had no trouble compiling it for PSP and Android.

As far as plugins are concerned: I don't see how this could be handled better than it already is. Again, there was no trouble porting it to Android (using mostly the same plugin system as for the Linux port) and even to the PSP.
The three plugins I offer with the ports (AGSBlend by Calin Leafshade and my recreations of ags_snowrain and flashlight) are written so that they work on Android, PSP and Windows with a simple recompile.

edit: Concerning AGS on OSX, doesn't that already work? http://www.adventuregamestudio.co.uk/yabb/index.php?topic=43383.msg578827#msg578827
The issue is more with the fact that it hasn't been updated in so long, sooner or later it's just not going to work with the latest Apple SDK. So it could do with either being updated or replaced.
That's right. And as for me, creating a Mac-Port "from the scratch" (ok, to be honest: derived form the Linux port) will help me to learn how AGS works and step into the code. I don't want to make a quitck-and-dirty hack, so that it "just works". I want to make a clean and useful port so that further development of AGS works without the need to adjust an "OS X hack" for each version. Beside this, I hope it will be practicable to make a port design that fit's well into the OS X environment. What OS X users what is an app with the look & feel OS X apps will have.

The first step will be to get the engine up and running, so that games developed under AGS for Windows can be executed under OS X using the ported AGS engine (well most of the games). The next step will be, to update the OS X GUI Part of the engine, so that the user e. g. have a menu to select which game to run, an option dialog for basic settings, etc. Beside this, a tool to convert Windows binaries to Mac OS binaries will be nice. This will help AGS Game developers to create a OS X Version of their game with just one click. (Ok, for now I hope that this really can be realized and won't be just a dream... ;-) )

I love adventures and Mac OS X. To become a lot of adventures alive under the Mac platform will be a great deal for adventures and Mac users. ;-) But this must be done in an orderly way, IMHO.

Greets
SchodMC

Chicky

What an exciting thread, there isn't much (if any!) that i can contribute. It would be fantastic to have the editor running on osx, i think it would certainly bring in some fresh blood. Dave would be a great choice, Calin would also get my vote.

I can help out with any UI design/graphics. Hopefully we can throw a new website in the mix too! Oh, i have a powerhouse hacintosh, if that helps at all for testing etc?

Dualnames

Worked on Strangeland, Primordia, Hob's Barrow, The Cat Lady, Mage's Initiation, Until I Have You, Downfall, Hunie Pop, and every game in the Wadjet Eye Games catalogue (porting)

SMF spam blocked by CleanTalk