The future of the AGS engine: STALEMATE!

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

Previous topic - Next topic

monkey0506

I've been perusing the engine source and looking to see what I can do to try and contribute here, and I have some questions on the technical side of this, specifically for the C++ programmers who know more about it than I do.

First off then, a bit of background on my own knowledge. The furthest I ever really got with C++ was in the book I had for "beginners" I got up to chapter 6, which included an exercise to write your own custom string class. I ended up getting stuck trying to figure out how to program a sprintf-style function because I couldn't for the life of me figure out a way of implicitly casting my type to a POD-type in order to pass it through "...". If you know, well good for you, but I don't even have the source files any more because that was like 5 years ago. :P

I also once did a Windows C++ tutorial which was in the style of designing an MDI text editor, with which I got as far as trying to figure out how to set a dirty flag for each document (which wasn't covered in the tutorial). I asked some questions on the appropriate events that should have been raised, and did actually much later get an answer, but amazingly enough my incredibly awesome text editor completely failed to see the light of day.

So, I do have experience in using C++, even above and beyond the call of duty given out by the tutorials and included exercises, but in my ambition I never really did much with it. AGS already existed, so what more did I need? :=

Anyway, enough back-story. I just wanted to establish that although I'm not well versed in it, I do have functional knowledge of how C++ works and how to program in it and such. But looking over the engine source, which as CJ himself put it, is "a mess", I have been wondering about some things:

- What, if anything, is the advantage of using char*s vs. the std::string class? Presumably it's a bit faster since there's less overhead and direct memory access and such, but is there actually sufficient overhead with the string class to make it non-viable for a project such as this? By that I mean, in refactoring and cleaning up the code, would one be totally remiss to try and replace the usage of char*s with the more user-friendly strings? If so, why?

- Is there any technical reasoning to the programming style that seems prevalent among C++ programmers? Having been working with the editor code and trying to develop a plugin (when I'm not working directly in AGScript for modules and things), I feel I've become a bit spoiled really. Regardless of how some people may feel about it, the OO-model is fantastic for organizational purposes. Is there any reasoning why refactoring the engine source into something more OO would be a bad thing? I don't necessarily mean that everything has to be bound inside of a class, but at least for the organization of grouping functions together, this would be a major step in making the code more readable. Not to mention the fact that for those who are accustomed to languages like C#, it would make the transition between looking into the editor code and the engine code much easier.

- A lot of static limits could be removed by using one of the classes provided such as std::vector, but some of the file structures are currently dependent on the static sizes for the way they encrypt and/or serialize their data. Is there an easy or "simple enough" way to go about rewriting these functions so as to essentially produce the same result without actually locking ourselves into static sizes? I believe the general consensus is that it would be in our best interests moving forward to start with a clean codebase versus a "compatible" one (in reference and relation to the prior versions of the engine), so non-compatibility with the existing functions isn't so much a problem, but presumably the basic gist of what's already being done would be preferable to just rewriting the thing entirely with something new.

Considering this is more about the technical side of programming in C++ than anything strictly specific to AGS directly, I thought that this would probably be the most appropriate forum. Feel free to disagree and move it around wherever you like if you want though. :=

In any case, that's pretty much all I have for now. I'm just trying to get a feel for how other people feel about this. I've done some work in refactoring some of the existing files into OO classes and trying to give it something of a feel more reminiscent of C#, but I'm not sure if everyone would consider that the best thing to do. So please contribute any feedback that would be appropriate as I'm trying to get a feel for how I should be going about all this. Admittedly, the engine source is kind of a huge undertaking, but if we could all reach an agreement on the technical provisions of coding style and conventions, then we could progress forward with making the necessary changes to clean up the code into a consistent state. ;)

Also something to consider is any implications that might be prevalent across various platforms. I have zero experience in cross-platform coding, so I'm not personally aware of any of the caveats or complications that may need to be handled to try and make porting the engine as simple as possible.

Thanks for any information or thoughts!

Ghost

Quote from: monkE3y_05_06 on Sat 23/07/2011 11:10:40
- Is there any technical reasoning to the programming style that seems prevalent among C++ programmers? Having been working with the editor code and trying to develop a plugin (when I'm not working directly in AGScript for modules and things), I feel I've become a bit spoiled really. Regardless of how some people may feel about it, the OO-model is fantastic for organizational purposes. Is there any reasoning why refactoring the engine source into something more OO would be a bad thing? I don't necessarily mean that everything has to be bound inside of a class, but at least for the organization of grouping functions together, this would be a major step in making the code more readable. Not to mention the fact that for those who are accustomed to languages like C#, it would make the transition between looking into the editor code and the engine code much easier.

Seconding that. Of course it will forever be CJ's life story how the AGS source developed, but I'd guess that it begun mainly procedural, and at some point (when OO became the most viable option) the program was already very huge, and thus never got "fully rewritten for those pesky OO rules". Why break something apart that works?
And as a mere user of AGS I really don't care much about the underlying code, as long as the product does what I want. But I agree (from limited personal experience) that OO is great for organising, re-using code and making things more readable (opening the source the first time was a bit like facing the wall of text in Netherhood). Would take a very commited team to re-factor AGS, though.

Wyz

Quote from: monkey
- What, if anything, is the advantage of using char*s vs. the std::string class? Presumably it's a bit faster since there's less overhead and direct memory access and such, but is there actually sufficient overhead with the string class to make it non-viable for a project such as this? By that I mean, in refactoring and cleaning up the code, would one be totally remiss to try and replace the usage of char*s with the more user-friendly strings? If so, why?
Well first off, the engine started out in C (correct me if I'm wrong) and good ol' C does not have fancy stuff like objects and templates. The string class has quite some overhead but not that much it would drastically increase memory consumption (still if you want to minimize things you should use the cstring for any string that is unlikely to ever change). But the real reason would be: It's already there, it has always been there and if you want to change it that will be a lot of work.

Quote from: monkey
- Is there any technical reasoning to the programming style that seems prevalent among C++ programmers? Having been working with the editor code and trying to develop a plugin (when I'm not working directly in AGScript for modules and things), I feel I've become a bit spoiled really. Regardless of how some people may feel about it, the OO-model is fantastic for organizational purposes. Is there any reasoning why refactoring the engine source into something more OO would be a bad thing? I don't necessarily mean that everything has to be bound inside of a class, but at least for the organization of grouping functions together, this would be a major step in making the code more readable. Not to mention the fact that for those who are accustomed to languages like C#, it would make the transition between looking into the editor code and the engine code much easier.
There is a big difference between modular programming and OO-programming. If you change everything to objects the impact will be quite extensive, that's a no-no. However C++ has introduced a lovely feature called Namespaces. This groups variables and functions together in a name space so you can refer to them using a certain name. If you combine that with modular programming (where everything is divided into modules with each a own code and header file not unlike AGS modules) you have a winning team. This would still be a lot of work but people can work on modules independent from each other as long as the headers are specified uniform. A technique you can use for that is Design by Contract.

Quote from: monkey
- A lot of static limits could be removed by using one of the classes provided such as std::vector, but some of the file structures are currently dependent on the static sizes for the way they encrypt and/or serialize their data. Is there an easy or "simple enough" way to go about rewriting these functions so as to essentially produce the same result without actually locking ourselves into static sizes? I believe the general consensus is that it would be in our best interests moving forward to start with a clean codebase versus a "compatible" one (in reference and relation to the prior versions of the engine), so non-compatibility with the existing functions isn't so much a problem, but presumably the basic gist of what's already being done would be preferable to just rewriting the thing entirely with something new.
Yes you nailed this point, this is where OO would thrive. Adding STL containers would be a good idea, and maybe some custom built datastructures. You can add the serialization also in this fashion, that would greatly simplify it.

Quote from: monkey
In any case, that's pretty much all I have for now. I'm just trying to get a feel for how other people feel about this. I've done some work in refactoring some of the existing files into OO classes and trying to give it something of a feel more reminiscent of C#, but I'm not sure if everyone would consider that the best thing to do. So please contribute any feedback that would be appropriate as I'm trying to get a feel for how I should be going about all this. Admittedly, the engine source is kind of a huge undertaking, but if we could all reach an agreement on the technical provisions of coding style and conventions, then we could progress forward with making the necessary changes to clean up the code into a consistent state. ;)
If you really want to learn C or C++ stay the fuck away from C#, It's the Avatar of the programming languages.
Well, I've said this before but nobody yet responded to it so here goes again:
We need someone to take on the project of refactoring the source. There would actually be three projects, but we're talking about the last one:
  • Maintaining support for the 2.x branch and maybe porting it to scummVM
  • Maintaining support for the 3.x branch
  • Refactoring the source code to eventually to roll out a 4.x branch.

    I'm interested in helping in the latter one, I would like to take on the project myself but I don't have enough time for that. Besides I'd be more comfortable if an AGS veteran did it like yourself.

    Quote from: monkey
    Also something to consider is any implications that might be prevalent across various platforms. I have zero experience in cross-platform coding, so I'm not personally aware of any of the caveats or complications that may need to be handled to try and make porting the engine as simple as possible.
    Platform compatibility boils down to this:
  • Using libraries that are platform independent
  • Use some level of abstraction for things like integer sizes and endianess.
Life is like an adventure without the pixel hunts.

monkey0506

#3
Quote from: Wyz+ on Sat 23/07/2011 11:51:49It's already there, it has always been there and if you want to change it that will be a lot of work.

Considering the vastly disjointed state, and the tremendously large size of the code, I was going under the impression that the simplest way of cleaning it up would be to basically just start with a fresh script and then reimplement the existing functions in a more organized fashion. That might be a lot more work than other methods, but if the point is to create some sense of unity, it seemed the best route to me. Feel free to explain why I'm being stupid. :P So anyway, with this route, I could just switch it out on the fly as things were being reimplemented.

Quote from: Wyz+ on Sat 23/07/2011 11:51:49If you change everything to objects the impact will be quite extensive, that's a no-no.

I'm not sure what you mean here. Is there significant difference in overhead or something that makes objects more memory intensive? I don't understand why moving code into classes would be "a no-no" as you put it. I'm aware of how namespaces work, and indeed I'm currently utilizing namespaces, classes, and structs in some of the code that I've reimplemented, but I don't see why putting things into classes now would be so problematic. As long as the calls and references were properly updated, the only downside I could see is if the overhead involved were really just drastically horrible.

Quote from: Wyz+ on Sat 23/07/2011 11:51:49Yes you nailed this point, this is where OO would thrive. Adding STL containers would be a good idea, and maybe some custom built datastructures. You can add the serialization also in this fashion, that would greatly simplify it.

Yes, the Standard Template Libraries. That's what I was thinking of but couldn't remember the name of. :P However, when you say, "you can add the serialization...in this fashion," I'm not sure exactly what you mean. Could you clarify/expand on that a bit?

Quote from: Wyz+ on Sat 23/07/2011 11:51:49If you really want to learn C or C++ stay the fuck away from C#, It's the Avatar of the programming languages.

Do you mean James Cameron's or the Airbender kid? Honestly I'm more of a fan of the latter. C# looks very pretty. It's very well organized, which makes it nice to program in. That's all I was getting at, is that I'm trying to improve the total lack of organization into something that would more closely reflect, say, the organization of the editor's source.

Quote from: Wyz+ on Sat 23/07/2011 11:51:49Well, I've said this before but nobody yet responded to it so here goes again:
We need someone to take on the project of refactoring the source. There would actually be three projects, but we're talking about the last one:
  • Maintaining support for the 2.x branch and maybe porting it to scummVM
  • Maintaining support for the 3.x branch
  • Refactoring the source code to eventually to roll out a 4.x branch.

    I'm interested in helping in the latter one, I would like to take on the project myself but I don't have enough time for that. Besides I'd be more comfortable if an AGS veteran did it like yourself.
We don't even have public access to the 2.x source at all yet, and the only real 2.x branch support I'm aware of within the 3.x branch of the code is the backwards compatible functions (engine side, editor side also has the project import-updater for 2.72 projects). I'm not sure if that's what you meant, but since it's already in the 3.x branch I don't see how that would differ from maintaining the 3.x branch...?

Refactoring the entire engine is going to be a long and arduous task, no matter how you go about doing it. My main concern for this thread was simply coming to terms with what I need to know about C++ to make sure I'm not "doing it wrong". It would be rather silly for me to rewrite half the engine only to have someone come along and tell me, "No, that's not gonna work because.....and......." Once we can establish and agree on some basic programming conventions then we can get into the gritty details of refactoring the engine code itself. Again, as I said, my purpose here in this thread is just to figure out what I should and shouldn't be doing (and why).

Thanks for the responses so far, it's been informative.

RickJ

Quote
- What, if anything, is the advantage of using char*s vs. the std::string class? Presumably it's a bit faster since there's less overhead and direct memory access and such, but is there actually sufficient overhead with the string class to make it non-viable for a project such as this? By that I mean, in refactoring and cleaning up the code, would one be totally remiss to try and replace the usage of char*s with the more user-friendly strings? If so, why?
This is actually more of a question of ANSI C vs C++.   In the context of something like the AGS runtime conventional wisdom is that C has a number of advantages over C++.

- ANSI C is considered more portable and is less resource intensive.  C++ implementations tend to vary from compiler to compiler much more so than C.

- ANSI C does not automatically, dynamically allocate/reallocate memory as C++ does.  The latter is fraught with potential problems when executed on unknown or resource limited target platforms.   

- Consequently runtime errors are less likely with ANSI C than with C++

- ANSI C typically has a smaller resource footprint than C++

Quote
Is there any technical reasoning to the programming style that seems prevalent among C++ programmers? Having been working with the editor code and trying to develop a plugin (when I'm not working directly in AGScript for modules and things), I feel I've become a bit spoiled really. Regardless of how some people may feel about it, the OO-model is fantastic for organizational purposes. Is there any reasoning why refactoring the engine source into something more OO would be a bad thing? I don't necessarily mean that everything has to be bound inside of a class, but at least for the organization of grouping functions together, this would be a major step in making the code more readable. Not to mention the fact that for those who are accustomed to languages like C#, it would make the transition between looking into the editor code and the engine code much easier.
I agree with you that OO is a superior organizing principal and that it is not necessary to make use of compiler features to take advantage.  I have been doing this for decades in non-OO languages.   I think it would lead to a better quality codebase as well.

Quote
A lot of static limits could be removed by using one of the classes provided such as std::vector, but some of the file structures are currently dependent on the static sizes for the way they encrypt and/or serialize their data. Is there an easy or "simple enough" way to go about rewriting these functions so as to essentially produce the same result without actually locking ourselves into static sizes? I believe the general consensus is that it would be in our best interests moving forward to start with a clean codebase versus a "compatible" one (in reference and relation to the prior versions of the engine), so non-compatibility with the existing functions isn't so much a problem, but presumably the basic gist of what's already being done would be preferable to just rewriting the thing entirely with something new.
I disagree C++ classes are needed to achieve this.  All that is necessary is for the the AGS editor to pass on the number of each item used.  ANSI C could be used to allocate the required resources at startup.

Quote
Quote from: monkey
Also something to consider is any implications that might be prevalent across various platforms. I have zero experience in cross-platform coding, so I'm not personally aware of any of the caveats or complications that may need to be handled to try and make porting the engine as simple as possible.
Platform compatibility boils down to this:

    * Using libraries that are platform independent
    * Use some level of abstraction for things like integer sizes and endianess.
I pretty much agree with Wyz+ on this although I would suggest more extensive use of abstraction.   

With regard to cross-platform libraries you may find QT interesting. 

http://qt.nokia.com/
http://doc.qt.nokia.com/4.7/gettingstartedqt.html

It features support for cross platform graphics, plugins, network, webbrowser, etc ....  It's also C++ ;)

monkey0506

Quote from: RickJ on Sun 24/07/2011 01:31:46This is actually more of a question of ANSI C vs C++.   In the context of something like the AGS runtime conventional wisdom is that C has a number of advantages over C++.

- ANSI C is considered more portable and is less resource intensive.  C++ implementations tend to vary from compiler to compiler much more so than C.

- ANSI C does not automatically, dynamically allocate/reallocate memory as C++ does.  The latter is fraught with potential problems when executed on unknown or resource limited target platforms.   

- Consequently runtime errors are less likely with ANSI C than with C++

- ANSI C typically has a smaller resource footprint than C++

What makes C-style char* allocation "more portable" than the std::string class? My understanding of the way that the std::string class is written is that it is essentially just a (semi-)managed interface that encapsulates the same thing. Seeing as it removes the need for direct pointer manipulation, it's also significantly less error-prone (despite your claim that char*s are less likely to cause errors, I would say that a memory leak would be significantly more likely than an out-of-memory error on most target platforms, and char*s would be more prone to the former).

You say that "ANSI C" doesn't dynamically allocate/reallocate memory, but I don't see how that could be avoided in any case where the std::string class couldn't avoid it. strings can be passed by reference to avoid creating unnecessary copies, and in the case of any type of manipulation, even char*s would have to be reallocated. I don't see where there would be any difference necessitated between the two in that regard.

If there's any information on the differences between the two and portability I'd be interested in reading it, but I've actually found more information negating your claims than anything supporting them.

Quote from: RickJ on Sun 24/07/2011 01:31:46I agree with you that OO is a superior organizing principal and that it is not necessary to make use of compiler features to take advantage.  I have been doing this for decades in non-OO languages.   I think it would lead to a better quality codebase as well.

I've actually been working to implement some classes for better organization and OOP-compliancy, such as for enums, properties, and indexers. Specifically enums should really have their own scope (the values being in a sub-scope of the one at which the enum itself exists) to fit with the OO-model. Properties and indexers aren't strictly essential, but they're significantly nicer to work with than directly calling getter and setter methods. Anything that didn't need function-based access could just be implemented as a normal field of course, but for the rest I've got these new classes implemented (after some Googling and extensive trial-and-error ;)).

Quote from: RickJ on Sun 24/07/2011 01:31:46I disagree C++ classes are needed to achieve this.  All that is necessary is for the the AGS editor to pass on the number of each item used.  ANSI C could be used to allocate the required resources at startup.

I never meant to imply that the STL classes would be necessary, only that they would make things neater in the long-run. C-style memory allocation is more prone to error and memory leaks, whereas if we used the STL classes it wouldn't so much be an issue. Not to mention the fact that even if we wrote some generic methods we'd still be writing a few hundred lines of code that could be simplified by just using an STL class. Unless there's a totally drastic amount of overhead then I simply don't see the aversion to the STL classes at all.

Anyway, I've been doing a lot of reading on various topics and I feel like for the most part what I've been doing will be fine. I'm still working to understand a lot of the engine code so as to try and make sure that I'm implementing the same functionality, but so far it seems to be going pretty well.

Radiant

Quote from: +monkE3y_05_06+ on Sat 23/07/2011 11:10:40
- What, if anything, is the advantage of using char*s vs. the std::string class?
Performance. I don't mean memory, I mean speed.

Bear in mind that AGS was written for DOS and much slower processors than we hav enow, where performance was much more important. A nice benefit thereof is that AGS games run fine on low-end systems even now (whereas there are several retro games on the market that require a 2 GHz processor for no apparent reason).

monkey0506

I was reading into this to see what more I could learn about this situation. I am particularly interested in some of the changes that have been made with C++11, and compiler support of those changes.

As far as I understand it, the proposed changes wouldn't affect the compiled code, and so shouldn't bear any relevance to portability (aside from compatible compilers), just to the design-time of the code (correct me if I'm wrong about that).

Particularly the type-safe enums and furthered Unicode support (UTF-8 literals, and the addition of the char16_t and char32_t types (which also have their own literal types)) seem that they would be very beneficial.

From there I was looking at what compilers support C++11, and I was rather surprised by how little MSVC++2010 has been updated to support the new C++ standard. Other than the fact that the existing code has been compiled with MSVC++ 2008, is there any reason why switching to another compiler would be a bad idea? Particularly GCC seems to have good coverage of the C++11 features.

Of course there's likely to be issues in changing compiler, but with the level of refactoring we're looking at, especially if we're looking at a fresh codebase versus maintaining backwards compatibility, it could probably be dealt with...

Oh, and for anyone interesting in educating me, from what I've read about endianness, am I correct in my understanding that it would only be relevant to bitwise functions?


Thanks.

Sslaxx

Quote from: monkey_05_06 on Sun 08/01/2012 04:17:07
Oh, and for anyone interesting in educating me, from what I've read about endianness, am I correct in my understanding that it would only be relevant to bitwise functions?
No. Endianness is more pervasive than that. It affects file I/O as well, for just one more gotcha.
Stuart "Sslaxx" Moore.

Wyz

I've been using MinGW for years and I have to say it some has advantages. MSVS has a good compiler, it has a few quirks a few short comings but uh well. I guess the biggest advantage using MinGW for me has been that it will compile the same on linux and if I pick the right libs I spend little time on porting. 8)
I think supporting both compilers (which is not all that hard when you use macros) is the best solution.
Switching from ascii to UTF-8 would be very nice, but damn, that will be a hellish task :D UTF-8 can be encoded in ascii, but UTF-8 can not easily be converted back to ascii, I found that out the hard way once. :P
The way most engines deal with endianness is by means of a wrapper for all types and io. It is generally the same mostly but some changes to fit the purposes of the application better. Have a look at libs like SDL, those generally have a nice way of handling it. AGS in it's current state also does this to some degree, I haven't really looked into it though so I can't really tell to what extent. If you decide to also add wide char support I suggest also adding it to the wrapper. You won't need templates for this, macros should be just fine.
As for C++11, yes it has some nice features, but compiler portability is also nice. I guess incorporating C++11 specific things in a wrapper only should fix that. That way you can replace parts with libs when certain compilers do not support it yet.
Life is like an adventure without the pixel hunts.

monkey0506

I've downloaded Code::Blocks and it seems to be telling me about quite a lot that MSVC++ was letting me get away with, but perhaps shouldn't have. Particularly the code I'm working with involved some usages of variable argument lists, and upon reading into that further I've come to the conclusion that variadic functions cannot safely be considered portable, as they depend on implementation-specific determinations of how parameters are sent through (are they all pushed onto the stack, do they use registers, a combination of both, etc.). For that reason I've started looking into C++11's initializer lists instead of using true variadic functions.

It added a bit of complexity to my code, but with a custom class I was able to create the conversions I need to pass various data into a initializer list, and it actually seems a much safer solution as essentially the initializer_list type is just a specialized array class. I'd actually like it if you could just pass a CSV list in place of an array/pointer parameter, but this is a pretty nice improvement. Since it is a specialized (const) array, the size is automatically determined on creation, and the individual elements are guaranteed to be stored in sequential order, regardless of where exactly they're allocated (at least as far as my understanding).

Regarding supporting multiple compilers, the only "officially" supported compiler for the existing branch of AGS is MSVC++ 2008. Just because it might compile elsewhere doesn't mean it's supported. :P I get what you're saying though, and we should try and keep the code as generic as possible in that regard I feel (limited to preferably no use of compiler-specific extensions and what-have-you). It will make it easier to maintain I'm sure if we're not all limited to the same compiler and can use our own preference.

As for Unicode, it's my understanding, and again, please do correct me if this is wrong, that the standard Unicode implementations map the standard printable ASCII characters the same, right? Such that if I do:

Code: ags
char32_t um = U'M';
char m = (char)um;


I should get the correct character back, right? And forgive me if I used the wrong indicator, I forget which one indicates UTF-32 and it's 1:30 in the morning, thank you. In any case, that is my understanding as far as individual character codings. If we did change to UTF-8, -16, or even -32, I can't imagine that we'd have too much need to convert those strings back to ASCII anyway. If we did (say, for a particular library), then what's another few hundred or thousand lines of code, eh? :=

Endianness is clearly something I have no experience in dealing with, so could you give an example of what you mean by a "wrapper"? Do you just mean conditional coding with macros, or a specific function to swap the endianness of a value at run-time?

Oh, by the way, I had asked at the beginning of this thread regarding std::string, which is apparently stricken with its own problems... Why isn't there a serious, modern C++ string class? It seems that you either have to sacrifice usability, portability, or Unicode support. There doesn't seem to be a single class that addresses the needs of the modern C++ programmer. There's a million and fifteen different string class implementations, but they all seem lacking. Or have I just overlooked that one elusive golden child of a class? As for efficiency, I've seen Radiant's post about direct char* access being faster than using a string class, but I can't fathom a situation in which a properly programmed class couldn't deal with that within a reasonable margin of deviance. As I said earlier in this thread, even char* strings would have to be copied, reallocated, etc. in order for them to change their length...and every other operation should be virtually identical short of any overhead implicit in using a class.

RickJ

Perhaps the QT libraries should be considered?
http://qt.nokia.com/

Quote
Qt is a cross-platform application and UI framework. Using Qt, you can write web-enabled applications once and deploy them across desktop, mobile and embedded operating systems without rewriting the source code.

Qt is available for the following platforms:

    * Windows Desktop
    * Windows CE and Windows Mobile
    * Linux/X11
    * Embedded Linux
    * Mac OS X
    * Symbian
    * Maemo/MeeGo

Android is also now supported
http://labs.qt.nokia.com/2011/02/28/necessitas/

Here is an overview of it's API.  It's modular so it's possible to only use what is needed.
http://developer.qt.nokia.com/doc/qt-4.7/modules.html#id-5ff96530-83d8-4e05-a98a-4ca5636bec55

There is also a cross platform plug-in system
http://developer.qt.nokia.com/doc/qt-4.8/plugins-howto.html

A lot of games have been written using QT
http://developer.qt.nokia.com/search?search=games

Bottom line: QT has already addressed portability issues so that it is possible to code once and compile compile that one source for any of the supported platforms.   If we are going to re-factor the runtime in an OO/C++ fashion then QT ought to be considered because it offers so much.  Just my 2 cents.


Shane 'ProgZmax' Stevens

#12
Wow, solid find there RickJ.  I support this approach!

Edit: Holy shit, the full sdk is 1.6 GB!?  And the download links seem to be down...

Calin Leafshade

I don't think QT is really appropriate for a game engine. It's primarily a widget toolkit and a gui framework.


Wyz

I agree with that. If you want to build let's say an editor then Qt is great. Especially now since they made LGPL an possibility, yay!

But ok, portability is always a matter of abstraction and how far you want to go with that. You want to have at least some wrapping so you don't end up with thousands of #ifdef #else #endif blocks. But too much is just as bad (especially as some libs tend to with C++ templates) and will only make your application bloated and hard to debug. So where is the sweetspot for that? Well that really depends on the application and the people that have to maintain its code-base.
Let me illustrate what I mean with wrapping. Let's say we want to read an integer from a file; we will have issues with endianness we need deal with. You don't want preprocessor blocks all throughout your code every time you read an integer so you make a global function and deal with endianness there. There are three practises from there on:
  • use preprocessor blocks in the source of this global function
  • use macros to replace the function name with an existing function or a system specific function
  • supply different source files for each target system

    I'd say, use whatever floats your boat. :P

    Quote from: monkey_05_06 on Mon 09/01/2012 07:42:06
    Code: ags
    char32_t um = U'M';
    char m = (char)um;


    I should get the correct character back, right?

    For UTF-16/32 yes, but I was talking about UTF-8; check Wikipedia for the differences between the two. :P
    Just a quick reason why you might want to use UTF-8 instead of UTF-16: UTF-16 takes twice as much space as ASCII, UTF-8 generally not much more as ASCII if you don't write in foreign scripts. But if space isn't really an issue I guess it doesn't matter that much.

    To get back to std::string, well sure you can use it if you take the overhead for granted. String operations might as well become slower, in some occations, and faster in other. I don't want to bore people with a talk about data structures so I'll leave it with that. Do know you can use UTF-16 and UTF-32 with std::string actually! Simply use std::string<char16_t> and std::string<char32_t> :)
Life is like an adventure without the pixel hunts.

RickJ

Although QT is most well known for it's GUI framework it is so much more.  It consists of a modular platform independent API and a platform specific backend for each supported platform.   I was told many years ago, by one of the developers, that having separate backends allowed them to achieve the appearance, behavior, and performance they desired and that it eliminated most of the ugliness (i.e. endian issues, #ifdefs, etc) and made for a much cleaner solution.   The result is that exactly the same application source (without #ifdefs, etc) can be compiled to run on any supported platform. 

Trolltech (now Nokia) has been at this for close to 20 years in a commercially successful context and have an impeccable reputation for the quality of their work. IMHO, it would be foolish to reject the fruits of their labor without at least taking a look. 

There are over 100 Qt games here. and another 30 here.  These don't include games created by Gluon, a Qt base game engine/editor similar in function to AGS.  There is even a book on Amazon about it, "Open Source Game Development: Qt Games For KDE, PDAs, And Windows",  and an active  Qt Development/Game Development forum on Nokia's website.   And of course some youtube videos here and here.

The notion that Qt is not appropriate for game  and game engine development is just plain silly.

Now there may be good reasons to not use Qt but have yet to be articulated. ;)

Snarky

Quote from: RickJ on Wed 11/01/2012 09:39:08
Although QT is most well known for it's GUI framework it is so much more.  It consists of a modular platform independent API and a platform specific backend for each supported platform.   I was told many years ago, by one of the developers, that having separate backends allowed them to achieve the appearance, behavior, and performance they desired and that it eliminated most of the ugliness (i.e. endian issues, #ifdefs, etc) and made for a much cleaner solution.   The result is that exactly the same application source (without #ifdefs, etc) can be compiled to run on any supported platform. 

Trolltech (now Nokia) has been at this for close to 20 years in a commercially successful context and have an impeccable reputation for the quality of their work. IMHO, it would be foolish to reject the fruits of their labor without at least taking a look. 

There are over 100 Qt games here. and another 30 here.  These don't include games created by Gluon, a Qt base game engine/editor similar in function to AGS.  There is even a book on Amazon about it, "Open Source Game Development: Qt Games For KDE, PDAs, And Windows",  and an active  Qt Development/Game Development forum on Nokia's website.   And of course some youtube videos here and here.

The notion that Qt is not appropriate for game  and game engine development is just plain silly.

Now there may be good reasons to not use Qt but have yet to be articulated. ;)


Qt is great (they're based close to my home town!), and certainly has a lot of of features that would be useful for AGS. In fact, one of the potential benefits might be replacing several separate libraries with one single library to handle more or less everything. And the level of cross-platform abstraction is tempting, definitely. But the fact is that it's primarily a widget toolkit, and that therefore many (most?) of the core features aren't relevant to AGS.

If the parts we do need are superior to any of the alternatives, it's not necessarily a huge problem that it also offers other stuff we don't need. The drawbacks would mainly be an unnecessarily complex API, and the library size. 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.

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. 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.

It is not clear to me that Qt is superior to SDL or Allegro as a graphics library, or to existing alternatives for other functionality. 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). 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.

monkey0506

I looked briefly around the website for Qt, and based on what I've seen, in addition to what Snarky has said, I'm skeptical about the appropriateness of Qt for AGS. I'm not contesting its usefulness for making games or for a game engine, but is this what AGS needs? I'm not convinced.

If we need to use preprocessor code blocks for conditional coding, I would propose that we should wrap them within a specific self-contained class/function/whatever, which would ultimately achieve the exact same effect that Rick mentioned ("without #ifdefs, etc" running amok through the codebase). I'm reasonably certain that the same can be applied to endianness issues. In short, I regard the suggestion that we use Qt for the purposes of avoiding conditional preprocessor coding and/or endianness issues, as bunk. That may certainly be a benefit, but that doesn't bear any relevance as to the issue at hand (whether Qt (as a whole) is appropriate for the AGS codebase). Just because Mozilla Firefox is portable doesn't mean we should base AGS on Mozilla. ;)

They've done a lot of legwork, that we could perhaps benefit from reviewing, but I feel that there's no reason why we couldn't use other libraries that fit what we need (without having to force the users to install a 275 MB DLL to run the game! :o).

I'm also not thoroughly convinced that the overhead of using a class would make such a drastic difference on modern systems. Radiant pointed out that older systems would have reflected a significant performance hit from this overhead, but is that still a realistic issue? I doubt it. AGS has already dropped support for DOS and for Windows 98. Windows XP should be the minimum Windows target version, and I'm all for supporting that platform, but I find it doubtful that many people using XP would suffer terribly from using classes.

Regarding the std::basic_string template, I'm quite aware that it could accept char16_t and char32_t as data types, but I'm concerned about things that I've read regarding different compilers having even slightly varying implementations of the class. From my own understanding, it would likely be a non-issue, but there's a possibility of it causing explosive catastrophe. For this reason I felt that it would be safer to find a very specific implementation that could be included in the source, just to ensure that at the very least we would have the guarantee that the class would have the exact same definition regardless of compiler/platform/etc.

In any case, there's some good and informative discussion going here. I like it! :=

As for portability, how about a target platform list:

Windows: XP and higher
Linux: ???
Mac: OS ? and higher
Android: ?.?? and higher
iOS: ??? (also, I'm sorry, but would this include iPad devices?)
PSP: ???

I think at least the first 5 should be core to the design of AGS 4. What do you guys think?

Shane 'ProgZmax' Stevens

Anyone have some WORKING mirrors for the sdk?  I'd like to get a closer look at it but the links keep giving me 404 errors ;(.

Snarky

ProgZ, the (Mac) SDK download works for me with the default link. 1.3 GB downloaded in about 1 minute.

Looking at the list of platforms (which I agree with, though I'd also appreciate an MS XNA backend to run games on the Xbox, and ideally a way to run them on the Wii, DS and/or 3DS -- though AFAICT that typically only works on rooted consoles), I wonder if it's at all plausible to design it so that game creators don't have to compile separate versions for each platform, but the engines would all be able to run the same bytecode/resource files (much like ScummVM, in fact). I definitely think games should be distributed with the engine--otherwise the setup barrier becomes too great for casual or non-tech-savvy players--but I worry that many authors won't bother compiling five different versions of their game.

Wyz

Quote from: ProgZmax on Wed 11/01/2012 17:04:06
Anyone have some WORKING mirrors for the sdk?  I'd like to get a closer look at it but the links keep giving me 404 errors ;(.

That is weird, they work for me; I use this link.

Quote from: monkey_05_06
(...) but I'm concerned about things that I've read regarding different compilers having even slightly varying implementations of the class.

Well that is an separate issue from using them in std::string. Even if char16/32_t are defined different for compilers (which I doubt very much) it is not an issue until you dump it into a file that gets read by a differently compiled application. If you want to be absolutely sure you can always wrap the string class:
Code: ags
class String : public std::string<char16_t> { ... }


I have to agree with Snarky's take on using Qt. Let's just use SDL or (and?) Allegro that have also a very stable background, also wrap things like endianness and are even more portable, and can be linked statically without making it strictly open source.

Speaking about portability: I'm optimistic about it, lets go all in: ;)
   Win32, *nix and ARM based platforms  8)


Quote from: Snarky on Wed 11/01/2012 17:59:17
Looking at the list of platforms (which I agree with, though I'd also appreciate an MS XNA backend to run games on the Xbox, and ideally a way to run them on the Wii, DS and/or 3DS -- though AFAICT that typically only works on rooted consoles), I wonder if it's at all plausible to design it so that game creators don't have to compile separate versions for each platform, but the engines would all be able to run the same bytecode/resource files (much like ScummVM, in fact). I definitely think games should be distributed with the engine--otherwise the setup barrier becomes too great for casual or non-tech-savvy players--but I worry that many authors won't bother compiling five different versions of their game.

Since AGS games can be packed into a .ags file I'd say: supply binaries for every platforms and have the .ags files either run by them or have them packed into the binaries. I hope that won't be a hassle, what do you think?
Life is like an adventure without the pixel hunts.

Calin Leafshade

#21
Quote from: Wyz on Wed 11/01/2012 18:20:46
Since AGS games can be packed into a .ags file I'd say: supply binaries for every platforms and have the .ags files either run by them or have them packed into the binaries. I hope that won't be a hassle, what do you think?

Agreed, splitting the interpreter and the data file is a good idea.

I think since CJ has said in his talk that he is entirely done with AGS (thank you CJ, we salute you for all your hard work over the years) we can take this to the next level.

We should also establish who *actually* has the expertise we're talking about here. It's all very well us pontificating on various frameworks and libraries but who exactly has used said frameworks and knows what is involved in implementing them?

I also suggest that we formalise something ASAP and give some people some actual authority here. CJ was going to be the project manager but seems not to want that anymore so we need to elect one. The project manager doesnt necessarily need all the technical knowledge but they need to be responsible and be able to defer to the technical lead on the actual implementation.

So, i suggest we firstly get a project manager. This could possible be done by committee if we couldnt establish a single figure.

Then the project manager (or committee) would nominate a technical lead. I would without a doubt nominate Wyz for that position who is clearly the most experienced developer here.

Then we establish a roadmap and ensure that our roadmap is both achievable and fits in with the feel of AGS. AGS is so successful because it has a very simple and effective workflow. Our *paramount* objective is to keep that workflow, or at least the spirit of the workflow, intact.

Before we do those three things, the rest is irrelevant.

EDIT: I will also add that although I'm not a technical powerhouse with regards to C++, I am willing to put in the work re:bug busting, editor development, management, et al.

monkey0506

#22
Quote from: Calin Leafshade on Wed 11/01/2012 19:32:25
Quote from: Wyz on Wed 11/01/2012 18:20:46
Since AGS games can be packed into a .ags file I'd say: supply binaries for every platforms and have the .ags files either run by them or have them packed into the binaries. I hope that won't be a hassle, what do you think?

Agreed, splitting the interpreter and the data file is a good idea.

While I can see how that could, on one hand and for some cases, be beneficial, I think we should make an option to compile a standalone executable. It creates a technical barrier otherwise, regardless of how many times you force the user to click a button saying, "I already have the AGS runtime, just give me the game." People will flood us with questions, "HOW 2 RUNNING GAEM!?E"

We could even make the runtime such that it could have a ScummVM-esque library feel to it, compatible with games compiled either way (data only or standalone executable). From there, why not go ahead and future-proof AGS 4.0 with compatibility settings? Let's face it, we're not going to require people to install a separate version of AGS every time they want to play older games (even though the general consensus is, as of right now, to drop 3.x and prior compatibility for the 4.x branch). We are going to have backwards compatibility in future branches. So why not add the ability to have in the game options "Run with compatibility for AGS X.Y"? That way anything that breaks backwards compatibility of a particular feature could be encapsulated so that the end-user could dynamically change the actual runtime version without having to install a slew of AGS versions? Oh, and this route would also promote portability I think, because even if the developer chose for the standalone executable route, this could ensure that the appropriate runtime would be used based on what system the game was running on.

That may be a tall order, but why the heck not? Creation decays where innovation dies.

Wyz

Well in that case you'd get a option to 'build as win32 game' and a 'build as android game' etc option in the editor, still pretty viable yes. If we're going that route lets also add cross platform support for plug-ins. Have a plugin developer supply a dynamic library or static object for each platform he can and in that case the 'build as X game' would automatically supply the rights files for plug-ins as well. We would warn the game developer when the plugin is not supported for that platform and also expose this information to scripts so a module might take over. I'm really starting to like the sound of this. :D

As Calin I've also seen CJ's talk and well there it really struck me. CJ did not just program AGS he also was the spindle in the whole commutation process where the users gave feedback and CJ would accommodate that. We actually need someone to take on that position and be a vector for all sorts of things like the AGS code base, the website, manuals, bugs and comments, feature requests, community activities, and more. I don't believe committees is a good idea since this position needs a face. Yet this person does not actually need to be a programmer. We need a likeable person that is reliable and has good social skills, preferable a few years of AGS under his belt so the community knows this person, that is willing to spend a lot of time on AGS. Though, assuming candidates are around they might not read this topic so I'll say this is beyond the scope of this topic.

Selecting a lead programmer would be a good idea once 'the spindle' is installed. I'd love to do that but I lack the time to do a decent job. Well do know you can almost always bother me with code related questions, I might not respond immediately but I will.

As for the direction itself, we're having an interesting discussion here so let's continue :D
Life is like an adventure without the pixel hunts.

SchodMC

Hi folks,

Calin Leafshade send me to this thread after I asked how I can help to make a mac-port of AGS. Well, first some words about me:

a) At first: my english is not the best (I think, you already realized). This is because I'm a German guy. But I hope it will be good enough.  :-\

b) About my SW-Dev experience: I started programming ~18 years ago, using Basic and DOS. Since then switch the programming language a couple of times: Pascal, ASM, Delphi, C/C++, Objective-C (Mac) and some little projects under C#. I had developed Software for Windows and Linux (as a professional developer 5 years for Windows (with some hobby OpenGL/DirectX projects) and 3 years for Linux). Three years ago I switched to Mac and started to learn developing for Mac OS X. So I have round about one year Mac OS experience (only hobby projects. Currently one big semi-professional GUI Project using Cocoa and sqlite3). So I have a lot of knowledge for C/C++ an meanwhile good knowledge for Objective-C and Cocoa. OpenGL luckily is Cross-Platform (but - maybe - irrelevant for AGS).

c) my Problem: I have not that much spare-time. But I'm interested in that project. So if my help will be welcome, I would like to concentrate on the AGS runtime engine (see below).

d) what I want: well, as told I want to help porting the AGS-Engine (for now, not the editor) to Mac OS X (Intel, 32 and maybe 64 bit). Because the core of the engine should be portable, the interface between Mac OS X and the engine would be the "funny" part. ;-)

So, if you say "you're welcome to help us" I will be pleased. So just tell me what I can do to help porting the engine to Mac OS X, so that anyone of the Mac users can play all the wonderful AGS Games using a native engine app.

Greetings
SchodMC

Calin Leafshade

#25
Right ok then, let's be proactive.

Here is a list of the people that I think would be familiar enough with the workflow of AGS, and/or who dedicate enough time to the community to be our Project Manager:

Khris
Tzachs
Wyz
Steve McCrea
Myself
Progz
Darth Mandarb
Radiant
Icebot
RickJ
monkey_05_06
Snarky

Apologies if I forgot someone obvious. Now I propose we contact those people and see if any of them were actually interested in taking on the task. Then we take a vote.

After which, the project lead can start arranging other key positions and then we can, as a group with the PM acting as a kind of chair, discuss and finalise a roadmap. How does that sound?


Alan v.Drake

C'mon guys, get started so devs like me can stroll by once in a while and do their part.
"Get the ball rolling" as they say.


- Alan

Shane 'ProgZmax' Stevens

I do a bad enough job managing my own projects, and the last thing I'd want to do is agree to do something like this and not follow through.

Whoever does it will have whatever support I can offer if they need it, though.

m0ds

If you're seriously taking what was said in that video to the next level, other considerations are going to be important for "the future of AGS" too. But it would certainly be great if you could get one or several of those listed people interested! Have you started discussing things with these people in PM or anything? Is that just your dream-team? I only ask cos I look at a few of those names and can tell straight away some are just too plain busy for, or have come across disinterested in the past in such a task. But that's also why I say it would certainly be great  :=

Calin Leafshade

#29
Feel free to put forward any of those other considerations and someone will consider them! :D

The more information we have and questions we ask the better prepared we will be.


Oh you ninja edited me.

No I havent spoke to any of them in PM and I know that alot of them are insta-no. but i added them to the list so they didnt feel ignored :p

I shall see if i can start to herd you bunch of fucking cats :p (PM sent)

Snarky

Quote from: Wyz on Thu 12/01/2012 03:49:36
We need a likeable person that is reliable and has good social skills

Well, I'm out, then. (x3)  :P
Much as I like telling people what they should do, I think I'd be incredibly ill-suited for a task like this. I would be very happy to help out in some capacity, though. Maybe writing documentation?

A few others who might be good candidates (mainly for having successfully organized and/or produced things as well as participated in the community in a positive way) are SSH, Andail, Ben304, Grundislav and Baron. I also think Dave Gilbert should be consulted, since Wadjet Eye Games is almost all AGS-based (and thus has a vested interest in developments to the engine), and since he employs about half of all AGSers anyway.

Really, I think anyone on that list (as well as many others I'm sure we haven't thought of) who wants to do it is welcome to.

RickJ

Quote
... If we're going that route lets also add cross platform support for plug-ins. ...
Qt has a cross-platform plugin system.  What others are out there?

Sslaxx

So long as plug-ins use the relevant API (and taking into mind ABI compatibility), in theory it should be possible to build all versions of the AGS runtime with support for them (using whatever mechanisms are appropriate for dynamically loading DLLs/.so files).
Stuart "Sslaxx" Moore.

Calin Leafshade

Yea, a cross platform plugin system is not really a point in favour of QT.

Indeed, JJS has already implemented certain plugins for his PSP port (although i dont know if they are just hard coded).

I have quite a lot of experience with the plugin API and I really dont think it would be hard to make it cross platform.

RickJ

Having to build separate plugins for each platform is far from ideal and not really a cross platform solution, IMHO.   Qt is one of a number of ways to do this; some are just more work than others..   

Calin Leafshade

RickJ:
How exactly can you have cross platform plugins as you describe? How can you execute x86 code on an ARM processor for instance? Surely the plugins have to be compiled for the architecture and ABI involved unless I am missing something? The only way i can imagine a situation as you describe is some kind of VM which is *far* from ideal.

Ok on the 'team' front:

It seems some people *are* interested in taking the position of project manager and things may be looking up.

I PMed Iceboty V7000a, RickJ, Darth Mandarb, Kweepa, Sslaxx, Radiant, monkey_05_06, Snarky, Khris, Wyz, tzachs, JJS, bero

Bero is interested in maintaining the linux port and has successfully created a cross platform (CMake based) build chain for us to work from which is a nice bonus. He seems to know his stuff. Bero also already has a functional Git repos.

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.

Monkey_05_06 has expressed tentative interest in leading the project providing the community was ok with that and had no other candidates in mind.
Dave Gilbert also expressed a very tentative interest in leading the project. I have some reservations about a commercial entity leading a community project but I thought I would put it out there.
I will also make myself available for this position if i am seconded by another member of the community. (All of the candidates would probably need to be seconded by someone before they could face a vote if one arises)

I'm willing to take a fairly active role in the editor development since C# is where i cut my teeth so to speak. I'm confident that Tzachs would be willing to back me up with that and possibly lead the editor coding efforts.

Sslaxx and JJS (and kweepa to a lesser extent) have offered their C++ skills to support the engine.

The only position with no obvious, willing candidates is arguably the most important, Technical Lead. It's possible that Sslaxx could fill those shoes if he were willing. Wyz would also be an ideal choice.

Thoughts on these arrangements would be appreciated

Snarky and Darth Mandarb have declined the *generous offer* put to them and as such were thrown into the pit of abandoned GiP threads to burn for eternity. All that was heard of their fate was "Please upload two screenshotttttssssssssss"

Sslaxx

#36
Been thinking about this, so I thought I'd share. Not ordered, not necessarily what I think, just points that came to mind and see what anyone else thinks of them.

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.
* Noncommercial use - this is the majority in terms of AGS use.

How important are the following?
* Backwards compatibility - compatibility with earlier versions of AGS should be considered important, but only up to a point. There are different viewpoints on this. For example, support for 2.7x legacy elements (primarily its commands) might be dropped altogether with 3.3. Or retained until a 4.0. Backwards compatibility for earlier 3.x versions should be retained in the 3.x range, at least. [Co-ordinate resolution with regards to walkable areas etc is a legacy compatibility element?]
* Open file formats - AGS already supports OGG and PNG, but it's more the internal file formats (CRM, VOX) that are the issue. CRM could be stored in XML format. [Walkable areas and the like are stored as bitmaps? So could continue to be stored as encoded data within any XML format used. Or perhaps switch to a SVG-like format?] Try to move any other internal file formats to XML maybe.
* Cross-platform runtime - native support under Mac OS X and Linux are already possible to a degree, but this needs to be solidified (concerning video playback and plug-ins, mostly).
* Cross-platform editor

What sort of things would any project manager need to consider?
* AGS licensing terms (Artistic License version 2) - this is a GPL-compatible license.

What other projects could AGS learn from?
* OpenSLUDGE - this uses a lower-level approach in comparison to AGS. Some of its ideas (such as storing animation data as code), might be worth looking at at least.
* Inform 7 - see how this project is managed primarily; also see if its approach of the editor as a separate program from the compiler could be of use for AGS (if it could facilitate independent editor projects for other platforms, it is at least a possibility). See if its approach regarding bug tracking and feature requesting would work for AGS.
Outreaching to these projects and others (e.g. ScummVM) would be of use. It has been suggested before that ScummVM could have support for older AGS versions included ala AGI or SCI games. Not sure if this is actually feasible, but the possibility should at least be investigated.

Priorities?
* A Project Manager being assigned for AGS as a whole - someone needs to be at the least, a go-between for the (possibly) disparate development targets within AGS and tie it all together. A figurehead is not of use here. As has been pointed out, deep technical experience is not required; that said, at least some technical knowledge of AGS (and at least basic knowledge of e.g. who would use it) would be a plus. A long-term plan for AGS is certainly essential, but the short term must not be forgotten either, as it will serve as the foundation for any long term plans going forward. Any project manager would need to be able to be trusted by all the relevant parties.
* Either using an existing source repository as the master source repo going forwards, or the creation of one - at the moment, there really does not seem to be a central source code repository for AGS. The main website has an SVN server, but access seems problematic and as a result people have set up their own, which introduces the problems of code forking and of not being shared properly.
* Assigning tasks to people dependent upon their strengths and interests (ideally)
* Bug tracker
* Promotion of the development project, recruitment of developers - separate to the promotion of AGS as a development environment in itself should be the promotion of AGS as being in development and therefore in need of developers. Recruitment should be controlled mainly by the needs of the project. Focus should be given primarily on areas of expertise lacking within the existing AGS coding team, but certainly not to exclusion.

AGS STRENGTHS:
* Flexibility - AGS can do more than just graphic adventures. Increasing it's flexibility in terms of what it can do is a good idea. Whether this should be done within AGS or by facilitating plug-ins (moreso than already) is another matter.
* Community - AGS has a good community built around it, and whatever is done to AGS should bear it in mind.

AGS WEAKNESSES:
* Sprite storage - the folder idea is not a bad idea, but it is somewhat let down by the usage of numbers to represent the sprites. This means it can be hard to remember what sprite numbers are used for what. It would be very tedious to have to name every individual sprite (or even groups of sprites) too. One possible solution could be to use the original sprite filename (with sprites imported as part of an animated GIF containing the frame number). Room backdrops could also be stored in this way - it would remove the distinction between sprites and backdrops (although I don't know if this would actually be useful). Sprites wouldn't be stored in the way they are now, but as discrete images in a SpriteCache folder (ala the AudioCache folder for audio files). Some code may do things like run code if an object/character is within a range of numbers (animation states); similar could be achieved by being able to "tag" a sprite or sprites with a value (or, perhaps, allowing "arrays" of sprites).
* Room numbers - in a similar way to sprite numbers, it can be difficult to remember what room is for what while coding. There is also the issue that rooms above 300 do not save state (although how much importance that has is debatable, and the number of games this affects is certainly almost vanishingly small). Having rooms referred to with identifiers would go a long way to resolving that.
* Lack of HD mode support - this has already meant one project has moved away from AGS (The Journey Down). With HD increasingly prevalent in the gaming world, it is odd that AGS has no native HD support. This also goes for widescreen modes. There appears to have been a prevalently conservative mindset regarding widescreen or HD mode support with AGS, though there are practical concerns too (The Journey Down had considered, but ultimately abandoned, incorporating HD and/or widescreen support into AGS).
* DirectDraw/Direct3D support - supporting both of these can be problematic. Trying to change this to something else (under Windows) could equally be as difficult.

Calin, I agree with what you've said there. I'm not sure what your reservations about Dave are, though.

I'd also be interested in helping out with the Linux port, too. As for Technical Lead? If Wyz is unwilling to do so, I would do that. I want AGS to thrive, and I'm willing to what I can to help achieve that.
Stuart "Sslaxx" Moore.

Snarky

#37
Quote from: Calin Leafshade on Fri 13/01/2012 22:42:52
Monkey_05_06 has expressed tentative interest in leading the project providing the community was ok with that and had no other candidates in mind.
Dave Gilbert also expressed a very tentative interest in leading the project. I have some reservations about a commercial entity leading a community project but I thought I would put it out there.
I will also make myself available for this position if i am seconded by another member of the community. (All of the candidates would probably need to be seconded by someone before they could face a vote if one arises)

That's great! I'll second you. Not that I wouldn't be equally happy to support the other candidates (I can't second all three of you at the same time, can I?), and I hope there's a way for all to play a guiding role in the project. If there's actually going to be a contested vote or some community decision made, I think you should each present your pitch for the future of AGS (as an application, as a development project and as a community), so we can get a sense for what we're getting ourselves into.

Plenty of open source projects are led by commercial companies, and Dave was an AGS old-timer long before he became a capitalist oppressor, so I wouldn't worry too much about that on principle.

Quote from: Calin Leafshade on Fri 13/01/2012 22:42:52
Snarky and Darth Mandarb have declined the *generous offer* put to them and as such were thrown into the pit of abandoned GiP threads to burn for eternity. All that was heard of their fate was "Please upload two screenshotttttssssssssss"

That actually reminds me: we do need some new mods around here, don't we? I volunteer for that, for whichever board(s) where one is needed... like this one.

Edit: Sslaxx, let's maybe bring the technical discussion back to the thread in the technical forum?

Calin Leafshade

I would be very happy to let Sslaxx take the lead programmer position. He seems to know his stuff.

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.

QuoteI think you should each present your pitch for the future of AGS (as an application, as a development project and as a community), so we can get a sense for what we're getting ourselves into.

That seems reasonable if it comes down to that.

QuoteThat actually reminds me: we do need some new mods around here, don't we? I volunteer for that, for whichever board(s) where one is needed... like this one.

Everything relating to adventuregamestudio.co.uk (forum, website) is still in CJs hands. Last time I discussed that with him he said he would prefer to keep the server under his sole control, which is fair enough. Thats really for the forum mods to work out though.

bero

Quote from: Calin Leafshade on Fri 13/01/2012 22:42:52
RickJ:
How exactly can you have cross platform plugins as you describe? How can you execute x86 code on an ARM processor for instance? Surely the plugins have to be compiled for the architecture and ABI involved unless I am missing something? The only way i can imagine a situation as you describe is some kind of VM which is *far* from ideal.

Doing it in a binary compatible way is really hard to impossible without a VM - but we should at least try to have full source level compatibility (and a strong hint for game developers that they should release the code for their plugins) so people can at least run all games if they can figure out how to compile something.

Quote from: Calin Leafshade on Fri 13/01/2012 22:42:52
Bero is interested in maintaining the linux port and has successfully created a cross platform (CMake based) build chain for us to work from which is a nice bonus. He seems to know his stuff. Bero also already has a functional Git repos.

To clarify a bit here, I don't have to take the PM job (but I would do it if nobody else volunteers or if people think I'm best suited - in fact I'd be happy if someone who also knows his way around the editor stepped up), and will happily give full access to the git repos and other infrastructure I have in place (mailing lists or whatever may be needed) to someone else who takes it.

I'd also be ok with sharing the responsibilities (maybe one person taking care of the editor and another taking care of the engine?).

Quote from: Calin Leafshade on Fri 13/01/2012 22:42:52
I will also make myself available for this position if i am seconded by another member of the community.

I second you.

Quote from: Calin Leafshade on Fri 13/01/2012 22:42:52
Sslaxx and JJS (and kweepa to a lesser extent) have offered their C++ skills to support the engine.

You can add me to that list.
My primary interest is in the Linux/*BSD ports, but I can also do some cross-platform bits.

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)

Radiant

While I have no objection to making AGS more optimized for commercial products, it strikes me as a conflict of interest to have somebody who creates commercial games be the manager of AGS. Certainly they should have a say in it, but I do not think they should be in charge.

So I would prefer Calin for this position. This is nothing personal against Dave, I just feel that since majority of the community do this as a hobby rather than for a living, the "management" should remain with somebody who does it as a hobby, just like what CJ did.

Shane 'ProgZmax' Stevens

#61
Before he created commercial games he created freeware games and continues to champion AGS.  I find it somewhat upsetting that 'local boy makes good' would somehow disqualify rather than make him a good candidate for the job?  Dave has real management skills and this is what we're looking for in a project manager, so I don't think we should be so quick to discount him because he happens to sell his games.  By that token I too should be disqualified because I have participated in the development of games he has sold and could be accused of having ulterior motives.  So could the dozens of people involved with or working on commercial titles of their own.

That said, this is all academic until and unless he replies with an interest.  I've notified him about the thread and given him my reasons why I think he'd do a good job on keeping the development focused so let's wait and see if he's even seriously interested.

monkey0506

I mentioned something to him about this on Facebook, and he didn't seem to know what I was talking about.

Strange, I thought he had already been contacted about this proposal. :o

:=

Dave Gilbert

#63
Hi everyone!  Progz just directed me to this thread and wow.  I'm really honored that you'd consider us for this.  I have to admit, I'm not entirely sure what the position would entail, but here's where we currently stand on the "state of AGS" issue.

As most of you know, we make AGS games full time and also publish AGS games by other developers.  The core company (such as it is) is made up of me and my wife Janet.  If we had actual job titles, I'd be the creative director/designer, and Janet would be the chief technical officer.  This isn't a side job or hobby for us.  It's our livelihood.  Currently we've got seven AGS games for sale and are in the midst of developing three more.  So we have a definite stake in the future of the engine and all the games made with it.  

We probably have a different perspective on things than most folks here.  We approach things from a customer perspective (i.e., making things better/more fun for the player) than a developer perspective (i.e., making the games easier to make).  While we definitely would like to improve the engine/editor, usability for the players would be our main priority. There are a number of common technical complaints we get almost every day from our customers and affiliates, and we can only shrug and say "Sorry, it's an AGS thing."  

Janet has long expressed an interest in cracking open the source code and making changes herself after her current project is finished (which should be around May).  These changes would obviously be shared with the community.  If we could make that official, so much the better!  

So, I guess you can count us interested, but like I said, we need to know more of what you'd expect from us.  I'd also like to get Janet's input, as she has more experience with this kinda thing than I do.  She's not home right now, but I'll show her this thread as soon as she gets in.

I hate to leave you with a "strong maybe", but consider us intrigued!

-Dave

tzachs

Quote
I'm willing to take a fairly active role in the editor development since C# is where i cut my teeth so to speak. I'm confident that Tzachs would be willing to back me up with that and possibly lead the editor coding efforts.
Yes, I will definitely back Calin up with active development of the editor. The word "leading" is a scary word, and so I will not say a definite "yes" to that. I will help with the decision process, provide guidance if needed, and do whatever I can within the time and resources that I have.

As for project manager, if we have someone here with actual experience with managing an open source project (and dedication to improving AGS), then that's the guy we want.
If not, then any of the names mentioned here sounds good to me.
That includes Dave. I don't see any real issues with commercial game developers involved in the development of AGS. IMO, what's good for the commercial games is good for the free games.
And besides, this will not be a dictatorship. There will be a lot of people involved which will have a say, so there's really nothing to worry about (not to mention that with the nature of open source, you can't really force anyone to do anything. You can ask, and you can refuse to accept code changes if it's not going with the accpeted vision, but that's pretty much it).

monkey0506

tzachs has summed it up pretty nicely. We're discussing a "leader"/"manager" just to have someone to handle coordination primarily, and if it ever really came down to it then of course they could help make determinations on a particular feature/function/etc. We don't need someone barking down our throats telling us what to do, but if there's a major decision that we can't settle on our own, then we need someone who can step in.

If I had to vote for someone other than myself, no offense to Dave, but I would actually vote for Calin. Dave has a very busy schedule at times, and WEG is very much his priority as it's his lifestyle. Of course we all have our livelihood to look out for, and this is position would be unpaid, a hobbyist role, for any of us. Calin does seem to have good management skills, and a reasonably open schedule. He has a pretty good understanding of the ins and outs of AGS.

Of course, if I could I'd totally vote for myself. :=

Sslaxx

Some of us appear to be putting words in other peoples' mouths here.
Stuart "Sslaxx" Moore.

Wyz

Quote from: Sslaxx on Sun 15/01/2012 00:34:10
Some of us appear to be putting words in other peoples' mouths here.

Oooh noes! Someone noticed!  :=
Life is like an adventure without the pixel hunts.

monkey0506

Okay, that's it. As interim project manager of AGS 4, I demand that no one is allowed to directly comment on anything that anyone else said. And yes, that means that no one is allowed to comment on this comment. :D

Snarky

Quote from: Dave Gilbert on Sat 14/01/2012 21:45:43
We probably have a different perspective on things than most folks here.  We approach things from a customer perspective (i.e., making things better/more fun for the player) than a developer perspective (i.e., making the games easier to make).  While we definitely would like to improve the engine/editor, usability for the players would be our main priority. There are a number of common technical complaints we get almost every day from our customers and affiliates, and we can only shrug and say "Sorry, it's an AGS thing."

I actually think that's a really valuable perspective. Ultimately, the vast majority of AGS "users" are the players, not the game creators, and certainly not the engine developers. Most of us here are probably barely aware of the technical problems you refer to, but they should definitely be on the agenda, IMO. (And I'm not really worried that this would be at the expense of improvements to the codebase, the editor or the engine, since those are the main priorities for most of the contributors.)

QuoteSo, I guess you can count us interested, but like I said, we need to know more of what you'd expect from us.  I'd also like to get Janet's input, as she has more experience with this kinda thing than I do.  She's not home right now, but I'll show her this thread as soon as she gets in.

I hate to leave you with a "strong maybe", but consider us intrigued!

Yes, that's a good question. People have argued that the project lead doesn't necessarily need to be the main developer or technical driver, so what does the role consist of?

My understanding is that the main responsibilities involve managing releases, facilitating communication and discussion while cutting through disagreements about the overall project plan, and generally wrangling contributors (including making sure that major roles are filled/tasks assigned, and picking up slack where necessary). In some situations the project lead may also act as spokesperson and publicist for AGS. I would think a large part of it is just staying on top of things, making sure progress is made and people are happy. It also depends on what the technical leads (of the engine, editor and ports) see as their role, e.g. decisions about new features or changes to existing ones.

Since multiple people have expressed interest in the position, I would also suggest that most influence in an open-source project comes not from a formal title, but from just picking up tasks and doing them. If you want to play an important role in future AGS development, that's completely up to you. It's all well and good to sit and decide "it should be like this", but someone has to go and do it, and they ultimately decide what they do; if it works and isn't completely stupid, others will most likely go with it, or at least use it as a basis for improvement.

Do the rest of you agree with this description, or did you have something else in mind for the project lead?

JanetC

#70
Hi, this is Janet Gilbert, Dave Gilbert's wife. I don't post here (yet) but I lurk!

I'm currently coding an AGS game for Dave, but when that is finished (in Summer), we have plans to do ports for AGS to Mac and iOS, with Android and Linux as future possibilities. Aside from that, we are interested in keeping AGS compatible with future versions of Windows as they come out. These ports are very important to us; we can't count how many times people have asked for iOS versions of our games! The ports would be "output only" - we wouldn't port the editor.

I've worked in the game industry as a professional programmer for about 12 years now. My main area of expertise is mobile/cellphone games. C++ is my language of preference, but C is fine too.

I haven't much knowledge of the source of AGS, so I don't know how much work would be involved in this but I'm confident it can be done.

We definitely need to coordinate these changes with whoever ends up managing the project, as they would likely be sizeable and extensive, although I will try not to run too roughshod over the code!  I'd like to be in touch with anyone else planning to port AGS.

monkey0506

Not revoking anything that I said (which I will not be commenting on :D), but I think that a good point has been brought up. The whole reason I started this thread is because I may not have the same level of experience coding as Wyz or tzachs, JJS or bero, Janet...or dozens of others around here...in C++. I've honestly just never had too much need to learn it. As a hobbyist, AGS fit my needs.

Now that AGS itself is in a position where utilizing C++ could help improve the very core of what it is, I'm all about that! So regardless of whether it ever gets implemented, I'm going to keep doing what I am doing, and learning from the experience I gain. Who knows, maybe some day I'll end up coding my own game engine from scratch just to know what it feels like (Snarky, I will always remember you for a comment I once made to that effect! ;D).

This community is part of who I am. After (more than) 8 years, that's sorta just what happens. I feel that I could fulfill the role in question, if needed. If not, I'll continue doing anything I can to help benefit this community however I can. Presumably that would mean honing my talents as a programmer, and I think branching out into a better understanding of C++ is a great way for me to do that. 8)

RickJ

The PM's main role, IMHO, is to keep everyone organized, motivated, and aiming for the same goals.  This requires someone who has diplomatic, managerial and leadership skill and experience.     


Calin Leafshade

Right, Well it would seem that everyone who is going to comment has done so and we are just likely to tread old ground here so let's make some decisions.

From speaking to Dave it would seem that he and Janet are not likely to be available until the summer. Now I propose that we cant really afford to wait that long and lose our momentum so I think we should elect a caretaker manager of sorts. It's unlikely that any major changes to AGS' workflow and stuff will happen between now and the summer so the caretakers job would be to oversee the initial tasks and begin work. That is to say:

Bug tracker
Code documentation
Compatibility issues (64bit, new libraries if needed)
Infrastructure

Most of those things dont really require any (non-technical) decision making, just some coordination.

Once summer has err summed we can then reevaluate our position and maybe elect a new dear leader to start improving the core feature set of AGS.

How does that sound to everyone?

Dualnames

#74
Edit: Straying off too much from the conversation
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)

Calin Leafshade

Quote from: Dualnames on Sun 15/01/2012 08:34:38
This whole topic so far, at least one page ago, felt like highschool cockfights.

Actually I thought the discussion thus far was reasoned and civil  ???. Until you showed up and went all drama queen.

Quote from: Dualnames on Sun 15/01/2012 08:34:38
And well, Calin, calin's a douchebag, but still, objectively I think I made a point.

Well as long as we're being objective..

On a serious note, I'm happy for monkey to take the leading role. He is more experienced in both the community (I've only been here since 2009 and only released 2 serious games) and in the number of contributions to the community (Really? 28 modules?). I offered my own services as more of a backup.


Snarky

Duals, that post is ... unnecessary. Obviously picking who we want to lead AGS is a touchy question, so let's not make it into a confrontational contest, eh?

Modules and plugins are one way to establish a track record (or pay one's dues), but they're not the only one. If this was primarily about coding, being an individual contributor, that would be one thing, but it seems like we agree that, as RickJ says "The PM's main role, IMHO, is to keep everyone organized, motivated, and aiming for the same goals.  This requires someone who has diplomatic, managerial and leadership skill and experience." Dave has a track record of that that has nothing to do with how many modules he has or hasn't released.

AGD2 expressed interest a while ago, and he listed some compelling accomplishments. So I thought I'd give my thoughts on why he isn't mentioned among the main candidates, so that it hopefully won't seem like a snub. Simply speaking: AGD2, you've contributed to AGS in valuable ways, but you haven't really been a part of the AGS community (at least as found on these forums). You've been around since the beginning, but you've only made 113 posts. People around here don't really know you, so it's a tall order to turn over the project to you. Since you offer to help improve the engine through suggestions, bug reports, and even implementing and donating new features, that's definitely something that would be valued. Thanks!

Anyway, I agree with Calin that we shouldn't wait months for Dave/Janet to become available; but should give someone who's ready to pick it up right away a chance and see how it goes. If it's down to Calin and monkey, maybe they can work out if they want to hold a vote or just decide between themselves? Maybe a project lead/assistant project lead situation? (When I've held various organizing chair positions for academic conferences, I always found it very helpful to have a co-chair to talk things over with, pass email drafts to, and generally divide responsibilities with. Also, two people can keep each other on schedule. It worked for me; might not work for everybody.)

Dualnames

#77
Edit: Straying off too much from the conversation
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)

Sslaxx

Let's not get things any more inflamed around here than they already are, please.

It might be a good idea to take the discussions about project managers, technical leads etc. to another thread.
Stuart "Sslaxx" Moore.

Snarky

Sslaxx, I think the discussion of the project organization makes sense here (though I'd rename the thread), while talk about the engine source should be in the technical forum.

Quote from: Dualnames on Sun 15/01/2012 13:12:07
I mean if for example if we change a carpenter with another person, shouldn't that person be chosen by the carpentry skills he possesses? Instead I believe we are choosing the carpenter by how much he knows the clients, how much the clients like him, and if he's a shoes saleman. In the long run though carpentry skills will prove far from useful.

Right, but we're not looking for a carpenter. We're looking for a project lead. And so by your own logic, we should be focusing on project leadership skills. Which is not the same thing as cranking out modules by yourself.

Wyz

Making modules for AGS is quite the different job then making AGS. It's not simply coding, you need to know how to design computer programs. Know how code will run on different platforms, make sure your memory usage and cpu time usage is optimal. AGS also has a Virtual Machine. Making virtual machines and also maintaining them is not a task even for novice programmers. I don't know if the AGS VM needs work (well actually I think it does since a lot of people including monkey and me would love to see things like dynamic structs and structs passed a function arguments) but there are lots of other things that needs to be design really well even before a single file of code is written. But that's all useless right now, because we're looking for a project manager (and even a spindle in the AGS community as I described in that other post noone read). In that case we need a person -- let me just quote myself --  that is likeable, reliable and has good social skills. I would like to see stats for that Duals. :D Noo really I do. Because I think that is really really important. We can just keep sucking up to each other but who are we kidding? The community needs to decide.
Life is like an adventure without the pixel hunts.

Dualnames

#81
Edit: Straying off too much from the conversation
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)

Calin Leafshade

Quote from: Wyz on Sun 15/01/2012 13:29:12
We can just keep sucking up to each other but who are we kidding? The community needs to decide.

Agreed, shut up dualnames.

I propose the following:

We vote on the 3 candidates available (monkey, myself and AGD2)

Now, none of us are particularly experienced in the task so I propose that whoever wins appoints a 'deputy' from the other two to heavily assist.

Once a week or so has elapsed we count the votes and then whoever wins takes over the discussion and starts to put some infrastructure in place.

From there, that person (and their deputy) will be expected to chair the discussion between the programmers (and testers i guess, lets get some of those) and decide where our priorities lie.

How does this sound? Yea or nay only please unless you have a worthwhile objection to make to we dont get sidetracked again.


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)

Wyz

Voting? really?
No, that is a foolish thing to do, just reread my post and don't use it out of its context again.
Life is like an adventure without the pixel hunts.

m0ds

Too early to vote really, this discussion on "who" and "why" only started a day or two ago. Let people get their feelings on the subject out. Is there any reason why a group of say, six or seven people can't work on the engine under the leadership of one other?

Dave Gilbert

Duals, I dunno if you are being sarcastic or what, but let's keep this on track please?

Anyway, in chatting it over with Janet (and a few people in the community) we agree that we wouldn't be the right ones to "lead" AGS.  However, we would like to be involved with whoever is.  Before we start on our next round of projects, we'd like to fix all the niggling issues we have with the engine.  So assuming nobody has fixed them before we're ready to go (which will probably be the summer), we'd be able to jump in and do it ourselves. 

Calin Leafshade

Quote from: Wyz on Sun 15/01/2012 13:50:01
Voting? really?
No, that is a foolish thing to do, just reread my post and don't use it out of its context again.

I dont really think I took your post out of context but whatever. "foolish" was a nice touch though, thanks.

Quote from: m0ds on Sun 15/01/2012 13:50:17
Too early to vote really, this discussion on "who" and "why" only started a day or two ago. Let people get their feelings on the subject out. Is there any reason why a group of say, six or seven people can't work on the engine under the leadership of one other?

Whatever the community as a whole decides would be best in my humble opinion. I suppose we'll see what comes out of a natural, non-voting discussion.

Sslaxx

Quote from: m0ds on Sun 15/01/2012 13:50:17
Too early to vote really, this discussion on "who" and "why" only started a day or two ago. Let people get their feelings on the subject out. Is there any reason why a group of say, six or seven people can't work on the engine under the leadership of one other?
No, but the issue of who the "one other" (aka project manager) is going to be is very obviously highly contentious. That's what we need to decide now, yes? And we've already had a list of people who could be suitable.

I don't think it's fair to exclude Dave/Janet because they aren't available now. But equally letting AGS drift leaderless and directionless any more than it has been already is just not going to help either. But equally we're still hashing through those details - but we shouldn't spend too long on doing that either. And people jumping in and doing it themselves would just fracture the community moreso than it already is.

So:
How long should we talk about who is suitable to take leadership of AGS? I'd rather we didn't spend the next few months or so bitching amongst ourselves over it. But equally it's all still fairly up in the air right now. I guess it'd take about a month, maybe six weeks, at least before we can safely say we have a firm list. But if we are (<insert your favourite deity/ies here> forbid) still going this over by the time Dave/Janet finish their project, then we would need to come up with a concrete list.
How do we decide on choosing someone out of any final list? I have misgivings about just the "AGS illuminati" voting amongst themselves. I'd prefer it to be a vote by the wider AGS community, myself, although I'm aware that may not be practical.
How do we then decide on who does what? Whilst that may well be up to whoever becomes AGS manager, they should take into account who is doing what at that time, and (maybe more importantly?) what the strengths (and weaknesses) are of those people who are available.
Stuart "Sslaxx" Moore.

Calin Leafshade

To be honest, If we are still deciding on a relatively minor point (I mean really, it doesnt matter that much, its mostly an administrative position) in 6 weeks then I think we have little hope of doing anything.

qptain Nemo

I'd like to point out that from what he's said here and on irc I see Wyz here as the only reasonable, skilled and honest enough man to be suitable for the position of the leader that requires making strong responsible decisions based on sense, genuine concern and determination and not heavily skewed sentimental notions. I don't see him as a man, who won't ever screw up anything, I see him as somebody who I can trust with a critical look at things and being able to act upon mistakes without thinking too much about pointless shame and pride. Seeing as he would love to help but isn't very insterested to claim the honourable position, he makes a perfect leader in my eyes. A humble one too, one that - I hope - won't push things through for the sake of his own ego and that would stop where necessary and would go against voices of many when that would be the right thing to do. Which in my opinion makes him a perfect first choice - I don't think he'd object to step down if anything goes too wrong. I'm not saying that's how it will be, I think that's how it can be, and it feels really worth checking. And checking something with a resonable person feels like a very right thing to do.
Wishful thinking? Only one way to find out.

Sslaxx

Quote from: Calin Leafshade on Sun 15/01/2012 14:10:32
To be honest, If we are still deciding on a relatively minor point (I mean really, it doesnt matter that much, its mostly an administrative position) in 6 weeks then I think we have little hope of doing anything.
Calin, project manager is not a minor point. We aren't talking a figurehead here, we're talking the person who will be focal point and drive of AGS and its future direction. Whoever takes on this role will become the public face of AGS and its development team. It will be their vision of AGS's long-term future that will determine its future successes or failures.
Stuart "Sslaxx" Moore.

Calin Leafshade

Well then I'll check back in 6 weeks :p

I'm pretty sure I've said everything I want to say on the subject. I think the position might be a tad too political in nature for me. I can be a little hot headed at times to my detriment and so I will step back now that monkey_05_06 has offered himself as a serious contender.

I hope this can all be resolved within the next few montsh so we can start working on stuff.

Peder 🚀

Takes a peek inside this thread...

Wyz, please. Lead AGS and give it the love it so badly need!
Lead it to become a multiplatform engine with an amazing networking solution!

Leaves thread never to return..

monkey0506

#94
I feel somewhat responsible for Dual. I discussed some things with him on Facebook, which ultimately was nothing more than me just venting a mixture of feelings. The very fact that my name has even been mentioned is, frankly, enough to give a guy a big head. That put together with some of his personal feelings about this and that...

It was a personal conversation, most of which was meaningless. In the end, I said to him, as I said here: regardless of what comes of all this, AGS is part of my life, and it's going to continue being such. I'm going to continue "cranking out modules" in the blind hope that maybe, just maybe, someone will find them useful. In 8 years I've worked on two actual game projects, both of which ended up being placed in the "Joke games" category because of extreme shortness of play, lack of genuinely useful content, and the storylines themselves.

Those two games are not the reason my name was placed in this list. My name was placed in this list (from my own personal understanding, belief, and perspective) because in that 8 years I have given to this community. In addition to writing modules, I've answered hundreds, dare I even say possibly thousands, of technical questions from basic beginner things of how to use the module, to writing a post with a custom code snippet that by the end of its writing turned out to be 50+ lines of code, written on the fly, and don't you know it, never tested at all! :=

So, to me, the reason my name is on that list is because I've given something to this community. Does that make me a perfect fit for the job? No, of course not. Does my knowledge of programming, which is, despite its strengths, severely lacking in the practical aspects involved in making the engine everything we need it to be, does that make me in any way a better candidate than Wyz or tzachs or Calin? I certainly wouldn't think so.

This community is part of me just as much as I'm part of it. I don't want to see this turn into a grand argument, particularly not over me. For now, I think we can maintain civility, but if my nomination becomes a point of contention...then it's not worth it. I write these modules, I answer these posts, I started this thread, I come here every day that I can (several times a day at that), often spending time here that I quite realistically should be spending doing other things. I do all that for one reason: because I love this place. But maybe I'm not the best available person to be its leader into the future. And I'm okay with that.

Edit: By the way, for anyone who's interested, this is my 1337th post in Gen-Gen. :D

Sslaxx

#95
You cannot escape politics anywhere. AGS is no exception, Calin, why ever did you think it could be? We have people supporting Dave/Janet, people supporting Wyz, Monkey_05_06, sometimes contrary to what these people have said themselves in regard to this role.

We could really do with categorical "Yes, I am interested" and "No, I am not interested" statements. That would, if nothing else, provide something to point at and then to work from.

YES, INTERESTED:

NO, NOT INTERESTED:
Calin Leafshade
Stuart "Sslaxx" Moore.

Calin Leafshade

My plan was to run a harmonious system whereby I just chaired the opinions of the programmers, testers and community, hopefully coming to a consensus on a course of action rather than saying what I personally think AGS should do. I wanted to act as I have [tried to] in this thread as a hub just to direct conversation and ensure action is taken. But it seems that the project manager should be more of a figurehead and an an absolute authority which doesn't interest me since I don't have the time nor the force of will to take that kind of responsibility on my shoulders. I am, after all, still a newbie in comparison to some of you guys.

So no, I'm not interested in leading the project.

Igor Hardy

I'm wondering if it's not too much pressure and responsibility to put just on one person. I'm worrying that the elected lead might get tired of his position pretty quick and switch to procrastination mode.

As there are 3 strong candidates, couldn't they agree to establish some kind of triumvirate that will divide the tasks at hand depending on skill and free time they have?

monkey0506

Calin, you can't step down if I was about to! There'll be no one left to lead AGS. It will be chaos! INSANITY! ANARCHY!! AHHH!!! BUILD ALL THE AGS BRANCHES WITH CUSTOM EXTENSIONS! FORK THE ENGINE LIKE A POT ROAST!!! AAHHHHRRRRRRGGG!

:D

Actually, I do feel that I have the time and capability to fill the role, at least for now, if it were asked of me. I'd love to help out however, and in whatever capacity I am able and needed.

One point that I'd be interested in addressing is the refactoring of the code. We need something clean, and consistent. And a lot of the static limitations of the engine are only static because they're programmed with static values. I think that making the code a bit more abstract with some generics would do wonders. That, IMO, should be the greatest priority right now.

Also, the idea of appointing secretaries assistants makes perfect sense. We do have lives outside of this, and ultimately that's what happened to CJ. Took him over a decade to fully burn out, but we're coming into this under totally different terms than he did...and the work we have before us is intimidating to say the least. Still, this community has a great spirit, and we'll figure it out...together.

Wyz

Edit: I'm making a new topic
Life is like an adventure without the pixel hunts.

Sslaxx

Quote from: Calin Leafshade on Sun 15/01/2012 14:52:07
My plan was to run a harmonious system whereby I just chaired the opinions of the programmers, testers and community, hopefully coming to a consensus on a course of action rather than saying what I personally think AGS should do. I wanted to act as I have [tried to] in this thread as a hub just to direct conversation and ensure action is taken. But it seems that the project manager should be more of a figurehead and an an absolute authority which doesn't interest me since I don't have the time nor the force of will to take that kind of responsibility on my shoulders. I am, after all, still a newbie in comparison to some of you guys.

So no, I'm not interested in leading the project.
Just because someone needs to take the lead doesn't mean they should ignore other peoples' opinions either, even if it is ultimately their decisions as to what to do.  If we were to have a single person in charge, I'd hope that they'd take into account all sides, and take it on to inform their choices.

Quote from: Ascovel on Sun 15/01/2012 15:00:42
I'm wondering if it's not too much pressure and responsibility to put just on one person. I'm worrying that the elected lead might get tired of his position pretty quick.

As there are 3 strong candidates, couldn't they agree to establish some kind of triumvirate that will divide the tasks at hand depending on skill and free time they have?
That'd really be up to them. And if the community at large would support the idea (which I hope they would), and whether or not they could work together.

If the AGS would work best with just one person in charge, great. If more than one, great. My interest is in seeing it grow. I'd rather we didn't bicker about that, at least.
Stuart "Sslaxx" Moore.

m0ds


Snarky

I agree that we shouldn't rush to a decision before people who aren't living their lives on the forum this weekend have had a chance to pitch in, but I think six weeks is too long for the discussion to go on for. I guess I think we should try to work something out by next weekend?

I'm uncomfortable with "the only person who's suitable for this position is..."-type arguments (or "this person is not qualified to be project lead because..."), because it suggests that if the decision goes another way, you won't support whoever gets the job. I think many people could become successful project leads (including all the people who have been mentioned), and I think that there's no person who's a sure thing, who is guaranteed to work out.

There's absolutely no doubt that monkey, Dave, Calin, AGD2, Wyz, Gilbot and others have all contributed to AGS and the community in really valuable ways, and the worst possible outcome would be if the choice of project lead turns acrimonious and means we won't have the benefit of all of their contributions in the future. Or if the supporters of other candidates don't give their whole-hearted support to the winner, so that he has no chance of succeeding.

I was hoping we could come to agreement through discussion and without having to take a vote, but it's clearly tricky to do without people getting worked up and feelings getting hurt.

So my vote right now is to cool it down, settle on a list of candidates (who should each outline what they have in mind for the job), for us to shut up and hear from other forum members, and see where we stand in a few days.

PS: monkey, I didn't mean "cranking out modules" in a disparaging way, just to point out that it's different from project management. The reason I think you're a good candidate for the job is not the coding itself, or even the support you've offered in the technical forums, but that it demonstrates your commitment to AGS and to the community. And Calin, I think whoever ends up as PM would ultimately define what the role would be, so I don't think you need to withdraw just because some others conceive of it differently.


Sslaxx

Quote from: Wyz on Sun 15/01/2012 15:06:12
Ok, fine, let's make thing concrete. There are two functions to fill in:

Community leader
You will be the new face of AGS. You need to be a common figure in the realm of AGS for this, but you don't need to have any technical knowledge, nor do you need to know how to program. You do need to be fair to everyone, reliable and generally a likeable guy. You will partake into making the wishes of the community concrete. You will delegate this wishes possibly to the technical lead (see below). You will be the go-to guy. Be there to talk to the press, but also resolve issues in the community. You'll need to be around on the forums, make announcements, have a motivational speech at the AGS awards, and generally more events. You can not have a hidden agenda, or "do your own thing" obviously. This position is all about the community.

Technical lead
You will be the vector in AGS development. You need to have a affinity for computers and know how they work in a broad scheme. You'll need to know how to program but more important, know how to keep code bases tidy. You need to know about all the platforms out there and not be restricted to just the one. You need to be able to recognise a good design and a bad one even before it is in production. Also you will be in charge of keeping all code consistent, deciding what is best to be left to plugins or what should be put in the engine itself. Also mind naming and coding conventions. The direction the project should go you will hear from the community and more likely from the community leader. This position is about maintaining an active code base.

Lets all do two things:
1. Are you available for this position: Yes/No, to what extend
2. Are there any persons you like to nominate

This is by no means a vote, it is simply making an inventory.

Community leader
1. Are you available for this position: Yes, though I really, really doubt I have the (especially people) skills for this one. So only as the "extreme last resort". If, by a universe-destroying level of improbability I did get this, it would be only for exactly long enough to find someone - anyone - who could do a better job.
2. Are there any persons you like to nominate: Well, anyone would be better than I really, but especially Calin Leafshade, Wyz, Monkey_05_06, Dave and Janet Gilbert.

Technical lead
1. Are you available for this position: Yes, I'd be up for this one. I admit my knowledge on Mac OS X is minimal, and not helped by not owning a Mac, but I'd certainly be keen to pick this one up. My primary coding interests lie within Linux, but Win32/Win64 wouldn't be impossible either. Done some tinkering with Allegro (3.x, 4.x) and SDL, certainly keen to take those forward.
2. Are there any persons you like to nominate: Monkey_05_06, GarageGothic, AJA, tzachs, JJS.

And Chicky? Oh, you.
Stuart "Sslaxx" Moore.

Chicky


Sslaxx

Quote from: Chicky on Sun 15/01/2012 15:29:26
Quote from: Sslaxx on Sun 15/01/2012 15:22:46
And Chicky? Oh, you.

Really Sslaxx? Was that supposed to be an insult?
Er, no? Sorry if it come across as such, was just meant to be humorous, but with how heated this thread has become...
Stuart "Sslaxx" Moore.

Calin Leafshade

Quote from: Chicky on Sun 15/01/2012 15:29:26
Really Sslaxx? Was that supposed to be an insult?

Oh Chicky, stop being a knob. Or I will fight you :D with pies!

Edit: damnit Wyz stop moving shit around.

Chicky

Hah, the amount of snarky comments that get passed around these forums and i'm the knob!

Whatever, this is obviously not the topic for Chicky's poor attempts at comic relief.

Ponch

As a man who's used variations on the same cow for eight years, I appreciate a man who sticks by his avatar through thick and thin. You're a good man, Chicky.  8)

SSH

Wow, you guys are really doing a good job of discussing things here. I'm a little sad, as this is exactly the thing I would have been up for a few years ago. And now I have management experience in a real software company I would have been qualified, too, but as I need to move country once again and need to organize that over the next few months and then settle in to my new job and a new country, I doubt that I'll have more time than the rare moments I have now to look at AGS.

However, here's my input:

If you want to make high quality games, you have to design testability in from the beginning to the game and to the engine/IDE. Dave G can probably give a wishlist of things that would make testing easier. Even more so there are probably web resources giving advice on this for games (my professional experience if more geared to other areas)
12

monkey0506

On the terming of "Community leader", etc.

There's been some discussion as to whether we need someone to fill this role. The name of the role itself might not be the best, but it's one that's been getting tossed around and used. The very much valid point was raised that the community itself is not falling apart and failing due to CJ's absence. Certainly it's great when he's here, but we are capable of thriving even when he doesn't have the time to visit!

So I just wanted to describe what exactly we do need:

- Someone to take control of the project, not the community (this role was at one time called "Project Manager" which does seem a better fit, and I will use moving forward).

Since AGS has been open-sourced, no one has taken a serious lead in pushing AGS forward. Perhaps no one wanted to step on any toes, or maybe they just didn't have the time. But no one has stepped up to the plate, one way or another.

- This position is not a strictly technical one!

The ability to clean up the codebase does not imply the understanding or vision of where the AGS program has come from, where it's at now, and where it can go moving forward. They're not strictly exclusive, but don't think of them as being the same either. The role of Project Manager should be about prioritizing what features the engine needs, what bugs need to be addressed now vs the ones that can reasonably wait for the next version, essentially understanding the consumer impact.

- We need someone who understands how AGS has been, and is being used.

Making decisions like, "We need an iOS port," is something that can and should be done as the community warrants it. We are moving into a very mobile world, and the portability of the engine could very easily make or break its viability. You don't need to be able to program the port to realize that. These type of decisions which may be "hard" from a technical standpoint are the decisions that need to be made, again, based on consumer impact more so than just whether it's going to be fun or easy or quick to implement into the source code.

- The Project Manager should be able to coordinate between the two!

As I said, this shouldn't be considered a "techies only" position, but the PM should have enough of a technical background to be able to understand if the Technical Leader is trying to convey technical implications of this or that. They should be able to take that into account and consideration in making decisions, and effectively convey that information to the consumer so that they are not just left wanting. Sometimes the answer to the consumer side may simply be, "This is not a feature that we currently are able to support," but the point is that we need someone to be able to communicate it. The Technical Lead may not always be the best person for that particular role.

The idea that "we just need someone to coordinate the programming efforts, thats all" is very lacking in understanding what we need. The Project Manager is a necessary role. Look how far AGS has moved forward since it was open-sourced without one. This should not just be seen as some "go between" position, but someone who is able of making the decisions that need to be made to help AGS, as a program, move forward. They should take the needs of the community and the technical capability at hand into account, and be able to define what route will be taken.

Anyway, that's my thoughts on the role. ;)

Oh, and regarding "term of office", I don't see that it's necessary. The Project Manager shouldn't be viewed as some key holder, who if he disappears from the face of the earth would leave us locked out and helpless. There should not be anything that has exclusive access to the PM (except perhaps his personal forum account ;)). If the community decides that someone else would be able to take the program in a better direction, the PM should be able to be replaced at any time, based on the needs of the community. Unless the selected PM was just not fulfilling the role, or was attempting to direct the program "astray" after some fashion, there should be no reason for the PM to have to be "regularly" replaced/reelected, and anyone who does take the role should be forced to sign a metaphorical waiver that states that they are willing to step down at any time that the community comes to a reasonable level of agreement (I'd say more than 5-10 members suggesting it without overwhelming opposition to their case).

Baron

Quote from: Ascovel on Sun 15/01/2012 15:00:42
As there are 3 strong candidates, couldn't they agree to establish some kind of triumvirate that will divide the tasks at hand depending on skill and free time they have?

I vote triumvirate as well.  They can work it out amongst themselves who is the "lead" lead, but in my estimation I think it's a very good idea to have continuity in case some member of the leadership decides they don't want to do it anymore.

Dualnames

Regardless of the decision to be taken, I'd like to apologize a bit for high-jacking the topic for stupid reasons, and adding more to the heat. It was all in the heat of the moment, and perhaps it shouldn't have been posted at all then. Right, I'll go back to a bit lurking there. I'm sure whatever comes ahead, it'd be a very nice decision.
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)

m0ds

Back to the engine discussion - what do folks feel would be more important from here on then, updates to AGS 3.x.x.x so that it can do x, y and z, or AGS 4, something new that incorporates all of 3, all the requested improvements, portability and true commercial game viability? Both are one and the same in effect but my point is which of these two directions would the technical lead, or team, really be considering? Bit odd question I suppose :P

Calin Leafshade

I used to think that a brand new AGS 4 would be a good idea but now i feel a more incremental approach would be best.

My priorities:

1 - Stabalise the code base, split up that monolithic file into modules, replace troublesome libraries with more open, portable ones (OpenGL for Dx, OpenAL for Dumb, etc)
2 - Once the code is in a better shape (or more likely *during* step 1) we can work to port the current engine to various platforms to test our rejigged code base for its ease of portability.
3- once steps 1 and 2 are completed or well under way we can thing about engine features, implementing them in a way that conforms with our coding standards set out in step 1.

Thats a very general overview and those steps can be split into multiple sub-steps but thats the general idea.


Wyz

Regardless the outcome of the discussions and what ever function I end up with in the development of AGS if any, I like to start working on a separate branch of AGS that will initially will break compatibility with the existing branch completely, but thus allowing to experiment with implementations a lot, and without restrictions. To avoid any anger towards such project I will name it Fake AGS or FAGS. The existence of FAGS might anger some people but I don't really care about it. I will use FAGS to try to add a lot of creativity and portability to the engine and initially it will depart with the original packaging since that will no longer be compatible. During development I have no idea where FAGS will bring me, I might not like it and abandon it, but it might bring along something useful that can contribute to the future. And better yet, I'm only half joking.  :=
Life is like an adventure without the pixel hunts.

Shane 'ProgZmax' Stevens

Calin, I don't see any problem with an AGS 4 if there's a valid reason for it; for example, CJ moved on to AGS 3 after making a lot of  varied but important improvements across the board to 2.72, enough that it made more sense to give it a new designation than to go to like 2.8 or something.  AGS 3.5/4 would be for a project manager who wanted to consolidate a lot of little fixes and improvements until the results were very significant, but I would say from personal experience that most people would rather see regular incremental releases to 'prove' that there's progress being made even if said features and fixes are unimportant to them.  

I wouldn't mind seeing a delayed release that encapsulates a lot of solid improvements to the engine, particularly engine performance and portability (such things tend to take awhile, anyway).  These are the two big drawbacks that I see hurting AGS right now, and to a slightly lesser extent wider resolution support and real-time windowed/fullscreen switching.

Calin Leafshade

Well you can still *call* it AGS 4. But I was really talking about the method in which it was achieved.

During development CJ stuck very rigidly to an idea of not breaking backwards compatibility. This allows people to upgrade more easily. I'm sure you are only too familiar with the fact that AGS games can be in development for *years*. Having no thoughts for backwards compatibility would be a mistake in my opinion (which is what i meant by "brand new AGS 4")

Shane 'ProgZmax' Stevens

So you're suggesting that with AGS 4 to break with compatibility altogether so the old legacy code can be removed and the new release retooled for more modern devices?  I think that's a fair idea, and one that would make development a bit easier for people without having to look over their shoulder at what they might be breaking in previous games.

My only suggestion there would be to 'maybe' release an interim version that's still backwards compatible but has some of the improvements current developers have been requesting for ages, features that will hint at what's to come in 4.0 that they'll be able to use with their existing games instead of rebuilding from scratch.  One could even host a poll with the top 10 or so fixes/features being specifically worked into 3.5 as a sort of farewell to the legacy-friendly AGS.

Calin Leafshade

Yes, that was my thinking.

AGS 4 would be free to break compatibility but we *can't* abandon the 3.x branch and just go with AGS 4 because that would disenfranchise essentially everyone with an active project.

What we should do is work on cleaning up the existing code and port that. *Then* we can use that fully stable, ported, open library friendly version in AGS 4 in which we (carefully, remember modules and stuff) break backwards compatibility in order to improve things.

We shouldnt be too rash when it comes to breaking compatiblity. In fact I cant think of a single good reason to do so off the top of my head. What exactly is the problem with the current system that cant easily be converted?

Radiant

Quote from: Ascovel on Sun 15/01/2012 15:00:42
As there are 3 strong candidates,
I think a triumvirate would be a good idea in principle, but which three candidates are we talking about exactly?

Quote from: m0ds on Tue 17/01/2012 13:30:45
Back to the engine discussion - what do folks feel would be more important from here on then,
In my opinion, portability (to Mac/Linux/Phones/whatever) should be a priority.


Just to throw a wild idea out there: it has been suggested in the past that AGS joins forces with SCUMMVM, which is a big open source engine which supports, among others, Sierra (AGI and SCI) and LucasArts games. They have a pretty big community with technical skills and support, and may be interested in helping us out. Would that be useful?

tzachs

It doesn't have to be either maintaing backwards compatibility completely or breaking it completely.
How it usually works, is when you advance to a new version you may break compatibility only with the oldest supported version of the bunch.
So for instance, with AGS 4.0, we may break compatibility with AGS 2.7, while still supporting AGS 3.0.
When we create AGS 5.0, we'll stop supporting AGS 3.0 while supporting 4.0, and so on.

It's like playing a game of Snake. When the head advances, so does the tail. If you decide to eat something and make you body bigger (i.e support more versions), the snake will get harder to control, and eventually it will crash.

Wyz

The Snake Tzach is referring to is Microsoft Windows, there is still 16bit compatibility stuff in there and that is really well let's say weird. The deal with breaking compatibility is that is does not nescesarry have to be permanent. One of two things might happen:
  • The newer branch will get a 'compatibility mode' that emulates the old engine
  • We stuff the old branch into scummVM
Life is like an adventure without the pixel hunts.

monkey0506

Right. I think there's a lot of misgivings about "breaking backwards compatibility". It's not like we'd be breaking things for the sake of breaking them. The point behind saying we're going to break it is so that we can refactor the code without having to worry about every single in and out and up and down of the way the current engine works having to be defined exactly the same. Largely the compiler should be able to remain backwards compatible with a new engine, just compiling the existing code and resources in a way that the new engine can understand.

Once we have a clean and consistent codebase, then certainly we could look at fixing what we broke, but as statically as AGS is coded, changing even a single line of the engine could break something, somewhere. That's why we say we're breaking backwards compatibility. Certainly we don't want to change or remove specific existing features of the program, but things have to change if we're going to make any headway. The source has been available far too long with far too little done about it.

One thing that may be likely to break is the ability to run older compiled games using the new engine. Or it may not, depending on if we can read the data that's appended to the older engine in a way that the new engine can make use of it. It may be something that we break now and fix later.

Keep in mind that even CJ broke backwards compatibility when it was appropriate to move the engine forward. And as widely used as it may still be, AGS 2.72 is not officially supported any more (CJ himself said so several times). He did put a lot of effort into making sure that he maintained it wherever possible, but there are times when it's easier to break it now, cutting the proverbial umbilical cord, and then fix it later. CJ understood that.

AGS 4 should not, IMO, guarantee backwards compatibility of the engine with any other AGS version, at least not in the initial releases. Again, this is something to consider. CJ had a well established method of implementing new features and fixes (including ones that broke things!) and then releasing minor builds for testing. The AGS 2.8 alphas were essential to the creation of what we have today as the AGS 3.x branch.

We should focus first and foremost on cleaning up the code. We need something clean and consistent, regardless if it breaks everything. We can work back from that point to fix what needs fixing, and through alpha and beta releases, get a concept of what it may be time to let go of.

JJS

The most important thing should be refactoring the current source.

- moving code out of headers (acroom.h!)
- splitting ac.cpp into several files
- renaming variables in a consistent manner
- possibly removing global variables
- enforcing one consisted coding and naming style
- identifying obvious "dirty hacks" and implementing them the right way

This is not so easy because the code is so intertwined and because of the generous use of global variables a lot of functions are not stateless.

edit: Well, basically what monkey_05_06 said.
Ask me about AGS on PSP, Android and iOS! Source, Daily builds

Snarky

Code refactoring is something that should definitely be tackled going forward, but on the other I don't think it should stand in the way of short-term releases. I would propose a release plan as follows:

3.3: Q2 2012 - Very close to the current version, with high-priority bugfixes and features (mainly HD resolution support and some editor tweaks), with ports to Mac and Linux. Should generally be backwards compatible with 3.0, and to some extent with 2.7
3.4: Q4 2012? - Code refactored and libraries replaced as appropriate. Performance and API improvements (including Unicode support, please). Fully integrated ports to Mac, Linux, Android and iOS. Backwards compatibility with 3.0 maintained where possible
3.4.++: 2013 - Continued support of 3.x branch
4.0: 2013? - Futuristic, pie-in-the-sky version of AGS. May break compatibility with 3.x in major ways. Basically, anything that would require a complete rewrite, like merging with ScummVM, or rewriting the editor to be platform-independent

This doesn't mean that people couldn't start working on AGS 4.0 today (though it might be best to get the code refactoring done first), just that the goal for the near term, in my opinion, should be getting a version of AGS that fixes the most important bugs and missing features that people have wanted for years, but haven't been able to do anything about until now. Many of these have already been implemented in various unofficial/experimental branches, they just need to be merged together, tested, bugfixed (if necessary) and given an official release. I posted many of them somewhere else, but I'll repeat them here:

* Mac and Linux ports (and Android and iOS if possible, PSP if available)
* Fix DirectDraw/Direct3D issues so AGS runs reliably on Windows
* Support for widescreen and HD resolutions
* Fix music stuttering on room change bug
* Savegames breaking on basically any game update (if possible to fix without major rewrite)
* Other possible high-priority requirements for commercial games, based on input from Wadjet Eye (Dave/Janet), Himalaya (AGD2) and Skygoblin (theo)

Would the rest you agree with something like this?

Wyz

Life is like an adventure without the pixel hunts.

Shane 'ProgZmax' Stevens

QuoteSo for instance, with AGS 4.0, we may break compatibility with AGS 2.7, while still supporting AGS 3.0.
When we create AGS 5.0, we'll stop supporting AGS 3.0 while supporting 4.0, and so on.

Yes.  This leaves a clear way for users to 'upgrade' even if it requires having a few versions of ags to do so.

As far as issues to tackle, let's have a look at Snarky's list again:

* Mac and Linux ports (and Android and iOS if possible, PSP if available)
* Fix DirectDraw/Direct3D issues so AGS runs reliably on Windows
* Support for widescreen and HD resolutions
* Fix music stuttering on room change bug
* Savegames breaking on basically any game update (if possible to fix without major rewrite)
* Other possible high-priority requirements for commercial games, based on input from Wadjet Eye (Dave/Janet), Himalaya (AGD2) and Skygoblin (theo)


To that I would definitely add the ability to toggle between fullscreen and windowed mode on the fly and to be able to resize the window (stretch to fullscreen). 

(Note:  I'm not saying that the above is an agreed upon list, I'm just offering a what if scenario below)

As far as priority, I think it should be a priority to work out the disparities between ddraw and Direct3d first, then tackle usability improvements like savegames and windowed mode (as well as the music issue), perhaps even work in the widescreen and HD stuff BEFORE attacking the ports.  The reason being that the compilers will need modification each time we make an update, so stability and usability should get priority consideration.  Otherwise, consider the compiler as the initial focus; each time one of these fixes or features are worked in, compiler update.  It just makes more sense to me to get a significant amount of work accomplished so the compiler end doesn't need incremental modification.  A case can certainly be made for a separate group dedicated to producing a compiler for other platforms that is up to the level of the current official AGS release.


Since Dave has withdrawn his interest in management, I can't really think of anyone who I've worked with and could vouch for that hasn't already refused, so I'll just wait and see what happens.  Not saying my endorsement is a big deal, I just don't like to put my name behind someone I can't personally vouch for. 

Snarky

As someone already said, there are different degrees of compatibility:

4. The new engine will run games compiled in the old version
3. You can load old games into the editor and recompile them for the new engine without any edits
2. You can load old games into the editor, and it will automatically update them into the new format
1. You can load old games into the editor, but you might have to change some parts manually to make it compile
0. You can't load old games into the editor (incompatible)

And of course, in each of these cases the compatibility may be unintentionally buggy to a greater or lesser extent.

What level of backwards compatibility are we talking about here? Personally I would say that the next version (3.3 in my proposal) should aim for level-4 compatibility with 3.x and level-1 compatibility (which I think is what 3.2 has now?) with 2.7, while 3.4 should aim for level-2 compatibility with 3.x and level-1 compatibility with 2.7, and 4.0 should aim for level-1 compatibility with 3.x only.

Stee

Quote from: Dave Gilbert on Sat 14/01/2012 21:45:43
We probably have a different perspective on things than most folks here.  We approach things from a customer perspective (i.e., making things better/more fun for the player) than a developer perspective (i.e., making the games easier to make).  While we definitely would like to improve the engine/editor, usability for the players would be our main priority. There are a number of common technical complaints we get almost every day from our customers and affiliates, and we can only shrug and say "Sorry, it's an AGS thing." 

-Dave


My vote if you want to call it that, goes to Dave. He's the only guy in here that's been suggested that I can actually see continued development on AGS happening under. There a lots of qualified people in here that I'm sure could do the job, but with no disrespect to any of you, I think you underestimate the task at hand, and I doubt many of you will be able to put the required time into the project.

Dave's job is essentially AGS. Bar one game in his collection, all his titles are made in AGS (I believe). He makes his living from it, and if theres anyone who is going to be more determined to get stuff done, its going to be someone who has that type of interest in it. Someone who requires it to put food on the table. Dave also has a lot of resources at hand and the backing of a lot of AGS vets.

The stuff Dave wants to work on is probably not the stuff we want to get done as "priority" (pretend those quotes are my fingers quoting), but I would rather see things get done than see the project rot into abandonment which is the likely alternative. The guy has a track record of getting stuff done, and that's the guy I want working on AGS more than anything.


Dave, I hope you reconsider.


PS: Can we get a seperate forum for all this AGS Engine Dev stuff?




<Babar> do me, do me, do me! :D
<ProgZMax> I got an idea - I reached in my pocket and pulled out my Galen. <timofonic2> Maybe I'm a bit gay, enough for do multitask and being romantical

Dave Gilbert

Hi everyone!  Since my last post on this thread, a number of you have emailed me or MSN'd me or PMed me asking me to reconsider.  So obviously you see something in me that I don't, or maybe I am just misunderstanding what the position entails.  While it's true that my livelihood is directly linked to AGS, I have zero technical knowledge about it at all.  I can program IN the engine, but I know absolutely zilch about what makes it tick.

That said, I do have lots of experience managing teams of people.  If I were to take a position like this, it would be more like an overseer than anything else.  Here's how I kinda see it working.

First off, there'd be a team of volunteers who work on the engine.  Maybe, say, ten people (to pick a random number).  Individually, they choose what bugs/features to work on and start working on them.  Obviously we'd need some kind of tracking system so we know who is working on what to prevent people from working on the same thing.

Once a volunteer finishes their job, the changes will be merged into a separate branch of the engine and tested by the team.  Once a number of changes have been made, we will release a beta build of that branch that the rest of the community can test.  Once it has been tested enough, we will make it the new "official" version of the engine.  This seems to be the way that CJ handled things (he'd add features to the engine until he felt it was significant, then release a beta candidate, which was tested ad nasuem until it was deemed release worthy), and it seems like the best way to move forward.

So my job, if anything, would be to keep an eye on the list of in-the-works changes/updates and make sure that they are being worked on.  If I have any kind of skill, it's staying on top of people until they finish something. :)  THAT I can definitely handle.  If that's the kind of person you need, and the kind of system you'd be happy with, than yes.  I'd be up for it. 

Stee

That was the kind of gist I was getting at Dave. I think that is ultimately the role of project manager. technical lead is the coding side of things.
<Babar> do me, do me, do me! :D
<ProgZMax> I got an idea - I reached in my pocket and pulled out my Galen. <timofonic2> Maybe I'm a bit gay, enough for do multitask and being romantical

RickJ

Dave, I think the only thing you may have left out is moderating discussions about future directions which I think is within the skill set you describe.    Also being a bit reluctant makes you highly qualified in my book.   ;D

You have my vote     

Snarky

Quote from: Dave Gilbert on Thu 19/01/2012 19:14:14
Hi everyone!  Since my last post on this thread, a number of you have emailed me or MSN'd me or PMed me asking me to reconsider.  So obviously you see something in me that I don't, or maybe I am just misunderstanding what the position entails.  While it's true that my livelihood is directly linked to AGS, I have zero technical knowledge about it at all.  I can program IN the engine, but I know absolutely zilch about what makes it tick.

That said, I do have lots of experience managing teams of people.  If I were to take a position like this, it would be more like an overseer than anything else.

...

So my job, if anything, would be to keep an eye on the list of in-the-works changes/updates and make sure that they are being worked on.  If I have any kind of skill, it's staying on top of people until they finish something. :)  THAT I can definitely handle.  If that's the kind of person you need, and the kind of system you'd be happy with, than yes.  I'd be up for it. 

As I said earlier...

Quote from: Snarky on Sun 15/01/2012 02:02:26
People have argued that the project lead doesn't necessarily need to be the main developer or technical driver, so what does the role consist of?

My understanding is that the main responsibilities involve managing releases, facilitating communication and discussion while cutting through disagreements about the overall project plan, and generally wrangling contributors (including making sure that major roles are filled/tasks assigned, and picking up slack where necessary). In some situations the project lead may also act as spokesperson and publicist for AGS. I would think a large part of it is just staying on top of things, making sure progress is made and people are happy. It also depends on what the technical leads (of the engine, editor and ports) see as their role, e.g. decisions about new features or changes to existing ones.

No one seemed to really disagree with this (although Wyz defined the role a bit differently in the nomination thread), and it seems pretty much in line with what you outline.

Would you be able to take up the task straight away, and organize a new release by, say, summer? (Assuming enough technically competent people volunteered to contribute.) Before you said that you and Janet might not have time for the next few months. That's really my only concern; apart from that I think you are the safest bet, for some of the same reasons Stee mentions.

Quote from: Stee on Wed 18/01/2012 22:03:28
PS: Can we get a seperate forum for all this AGS Engine Dev stuff?

I think only CJ can create forums, and he hasn't been online for two months.  :(

Intense Degree

Disclaimer: My poor programming knowledge (compared to many here) and lack of activity in the community generally really count me out of having any voice in this debate. My "2 cents" below should therefore be treated accordingly.

I think the idea of an overseer or project lead who is not too involved with the actual programming is a good idea and would make for a healthy set up going forward.

Dave is a very credible lead for this project on every front, as a household name both here and in the world of adventure games generally, and with the experience of managing projects "in the real world". The tasks of programming etc. can then be split equally between others without any problems of someone trying to force it "their way" in terms of how the code works and the general structure.

As I say, I have no vote in this, but the model of someone overseeing and managing whilst others are given parts of the technical side to deal with seems like a good way forward to me.

Dave Gilbert

Snarky: Yep, I can pretty much start right away, if only to get the ball rolling.  Assuming everyone wants me, of course.  ;D 

We'll definitely need a subforum for engine stuff.  CJ is the only one with global mod status of this forum?  Does anyone know how to contact him?

m0ds

He said he would pop by on Monday, but hasn't yet...

Shane 'ProgZmax' Stevens

In the absence of direct assistance from CJ, one could just host the ags development forum elsewhere with a blog for updates and so on.  The tech forum here has never sufficiently handled the development process (in my view) though it has always been a good place for plugins and bug reports.  You could connect the forum to the sourceforge site for ags (or wherever) as well.


This is probably something Peder would be willing to do, though I'm not trying to speak for him.  This would at least move this beyond the discussion phase.

Dave Gilbert

So, it's been a week.  Should we just jump right in?  Since nobody here has the ability to create a subforum, I can set up a subforum on the WEG site for now.  We had some great momentum going and I would hate to lose it.

-Dave

Wyz

Well actually, there has been a seperate discussion in this topic:
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=45149.40
Sorry for the inconvenience but could you please read it (the last two pages or so) as well?
Here we discussed the fact we rather have a group of people 'in charge' rather then just the one. There is no need to rush this, in fact it must be taken care of in a precise way or else we just get side tracked in loads of discussion as seen before. I rather ask Peder to set up a forum somewhere then having a subforum on WEG if we must, but as m0ds pointed out, he's waiting for CJ to respond and I think that would be a nice thing to do since it is his baby. :P
Life is like an adventure without the pixel hunts.

Peder 🚀

I'd gladly set up a forum somewhere and even buy a dedicated domain name for it, but I find it rather pointless to make such a forum anywhere besides here. And why do we even need a forum to start things off? What is with all this rush? Are the roles that have been spoken of even filled in yet?

m0ds

CJ was only notified of this last week so it's worth waiting a little bit longer in hope it can be an AGS sub-forum or two.

Dave Gilbert

Quote from: Wyz on Sun 29/01/2012 13:14:04
Well actually, there has been a seperate discussion in this topic:
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=45149.40
Sorry for the inconvenience but could you please read it (the last two pages or so) as well?
Here we discussed the fact we rather have a group of people 'in charge' rather then just the one. There is no need to rush this, in fact it must be taken care of in a precise way or else we just get side tracked in loads of discussion as seen before. I rather ask Peder to set up a forum somewhere then having a subforum on WEG if we must, but as m0ds pointed out, he's waiting for CJ to respond and I think that would be a nice thing to do since it is his baby. :P

Hm.  I didn't know that other thread even existed!  I went and read it.  And maybe I'm a bit late to the party, but I'm not quite sure I understand.  My understanding was that nobody was going to be in charge per se, but someone was needed to keep an eye on things and make sure progress was continually being made.  Is that no longer needed?  And will someone be in charge of merging any changes into the official branch?  Or is that handled by everybody?  Right now there are a bunch of AGS branches with different features and upgrades.  It would be nice to have a new "official" version that merges all these changes into one.  

Anyway, I guess this is something we can discuss once we have a subforum and some volunteers!  Like I said, I'm not really the guy to handle anything technical, but if you need help on the management end then just ask!

And Peder: A few posts ago someone asked if I could "start right away" which made me think there was some level of urgency.  If that's not the case, then I have no problem waiting.

m0ds

I just had a quick message from CJ saying he fully intends to come and sort all these things out as soon as he gets a free night. Obviously, there could be a couple of hours work setting things up from his end.

Dave Gilbert


timofonic

Quote from: m0ds on Tue 31/01/2012 02:09:27
I just had a quick message from CJ saying he fully intends to come and sort all these things out as soon as he gets a free night. Obviously, there could be a couple of hours work setting things up from his end.

Any news about releasing the older AGS versions? A full release of the Visual SourceSafe repo could be amazing to have. This is something quite demanded by the ScummVM Team, so please say him to contact them about this.

monkey0506

Tim, you're quite literally the only person in my 8 1/2 years here that I've ever seen reference the AGS source code existing within a Visual SourceSafe repository.

In fact, just to be sure I wasn't making an arsehat out of myself, I used the forum search for "SourceSafe" and then again for "Source Safe". Pumaman (CJ) has made a couple of comments to the effect that the AGS 3.0+ editor has the capability of integrating with VSS systems that may be installed, provided that they utilize the MSSCCI interface. The editor has nothing to do with the run-time engine, just to be clear.

So, given the fact that CJ has, until very, very recently, been the sole contributor to the AGS codebase, why would you assume that he would have the code in a source control repository to begin with? I'm not saying he doesn't, wouldn't, shouldn't, couldn't, etc., but I don't understand your reason for assuming that he did, and then why you're being so specific as to state "Visual SourceSafe repo".

CJ is not ignorant, but he is a busy man. He's fully capable of releasing the AGS 2.72- source when he's good and ready. If he never reaches that point, then it's his proprietary software, and it's not your place to tell him what to do with it. I think that just as the technical forums have a warning against asking when the next version of AGS will be released, we should have a general rule against asking when CJ is going to open up the source of older AGS versions. He'll do it if and when he wants to, and nothing and no one is going to change that.

Alan v.Drake


Besides the jokes, we're only missing those ancient 2.x sources (of which I don't care much since I don't see myself willing to play any of those old ags game on ScummVM) and the more important AGS.Native, which is the only piece left for the current version to be completely open sourced.

I have some properties I'd wish to add to regions, characters and objects, and correct me if I'm wrong, but I need the Native because that's where the code that actually saves such stuff is.  :-\


- Alan

monkey0506

There's an interface publicly exposed that relates what calls AGS.Native is used for...so hypothetically there's nothing to stop you from writing your own compiler. It would just have to understand the raw AGS scripts and resources and then convert them into a format which the engine can understand...

Not saying it's a small feat, but perfectly possible. :=

timofonic

Quote from: monkey_05_06 on Tue 31/01/2012 20:13:27
Tim, you're quite literally the only person in my 8 1/2 years here that I've ever seen reference the AGS source code existing within a Visual SourceSafe repository.

In fact, just to be sure I wasn't making an arsehat out of myself, I used the forum search for "SourceSafe" and then again for "Source Safe". Pumaman (CJ) has made a couple of comments to the effect that the AGS 3.0+ editor has the capability of integrating with VSS systems that may be installed, provided that they utilize the MSSCCI interface. The editor has nothing to do with the run-time engine, just to be clear.

So, given the fact that CJ has, until very, very recently, been the sole contributor to the AGS codebase, why would you assume that he would have the code in a source control repository to begin with? I'm not saying he doesn't, wouldn't, shouldn't, couldn't, etc., but I don't understand your reason for assuming that he did, and then why you're being so specific as to state "Visual SourceSafe repo".

CJ is not ignorant, but he is a busy man. He's fully capable of releasing the AGS 2.72- source when he's good and ready. If he never reaches that point, then it's his proprietary software, and it's not your place to tell him what to do with it. I think that just as the technical forums have a warning against asking when the next version of AGS will be released, we should have a general rule against asking when CJ is going to open up the source of older AGS versions. He'll do it if and when he wants to, and nothing and no one is going to change that.

He said about using VSS for AGS development, I talked with him over a PM. So please don't attack me like this way, at least for this ;)

He said about to release it in a PM too, so maybe he forgot it due to being too busy. People over ScummVM Team is quite interested on older AGS releases, they want to support classic AGS games and that's part of their needs for the task.

He can do whatever may like, but I have great faith in his words said to me and others :)

I don't want to annoy him, but the situation is quite frustrating to a lot of people wanting to do something to preserve his works to the world. There's momentum to be used, instead people get bored waiting for it.

The same happen to reorganizing the AGS project, even different roles like site maintainer and webmaster.

An "AGS Foundation" would be quite nice to make the project bigger in the future, but maybe that's a quite big task...

Monkey, you request too much rules. Do you want to be the forum dictator or something? :)

Calin Leafshade


monkey0506

Quote from: monkey_05_06 on Tue 31/01/2012 20:13:27So, given the fact that CJ has, until very, very recently, been the sole contributor to the AGS codebase, why would you assume that he would have the code in a source control repository to begin with? I'm not saying he doesn't, wouldn't, shouldn't, couldn't, etc., but I don't understand your reason for assuming that he did, and then why you're being so specific as to state "Visual SourceSafe repo".

Quote from: timofonic on Wed 01/02/2012 09:46:23He said about using VSS for AGS development, I talked with him over a PM. So please don't attack me like this way, at least for this ;)

I'm sorry, but what? Nobody's attacking you, stop being an idiot please. All I did was ask why you were making these assumptions. If CJ told you that over a PM then that's fine. That's all you had to say. Again, it hasn't been discussed in the public forum.

Quote from: timofonic on Wed 01/02/2012 09:46:23He said about to release it in a PM too, so maybe he forgot it due to being too busy.

Right. After more than a decade working on developing a program, one that spawned this community which regularly has annual and even sub-annual real-life meetings of its international members, I'm sure he forgot about AGS. Sorry, but you're making my brain hurt.

Quote from: timofonic on Wed 01/02/2012 09:46:23People over ScummVM Team is quite interested on older AGS releases, they want to support classic AGS games and that's part of their needs for the task.

He can do whatever may like, but I have great faith in his words said to me and others :)

Great! You should believe in CJ. He's a good guy. And ScummVM is certainly more than welcome to use the code of existing or prior engine versions in accordance with their respective licenses. Currently there are no 2.x branches of the engine which are open source, but CJ will resolve that, again, if and when he has time.

Quote from: timofonic on Wed 01/02/2012 09:46:23I don't want to annoy him, but the situation is quite frustrating to a lot of people wanting to do something to preserve his works to the world. There's momentum to be used, instead people get bored waiting for it.

You're contradicting yourself. You say you don't want to be a nuisance but in the same breath turn and say that CJ is being frustrating by not bowing down immediately before your commands. Honestly, this is all starting to leave a bad taste in my mouth, but for now I'll hold onto the belief that you're just the worst spokesperson that ScummVM could have hoped for (no technical knowledge, poor communication skills, total lack of appreciation for the rights of the author and copyright holder and his ability to make intelligent decisions, etc.).

Quote from: timofonic on Wed 01/02/2012 09:46:23The same happen to reorganizing the AGS project, even different roles like site maintainer and webmaster.

An "AGS Foundation" would be quite nice to make the project bigger in the future, but maybe that's a quite big task...

I don't understand why "site maintainer" and "webmaster" should necessitate separate positions. Should the webmaster be competent enough to maintain the site? Certainly delegating things to other people to help out would be fine, but this is yet another example that despite your inherent love for the modeling of the ScummVM team and project organization, you understand absolutely nothing about it.

Quote from: timofonic on Wed 01/02/2012 09:46:23Monkey, you request too much rules. Do you want to be the forum dictator or something? :)

Of course I want to be forum dictator. I'm a total power-hungry prick. How else could I have mustered the strength or courage to ask you to just accept what CJ has already told you and stop spamming the forums with these posts demanding that CJ follow through right now? I mean, how dare I ask you to show a bit of courtesy, respect, or appreciation to the man who has made this very community a possibility by his tireless hard work, determination, and undying dedication?

Quote from: Calin Leafshade on Wed 01/02/2012 10:21:08yea monkey,

stop requesting rules.

Calin, stop requesting it be made a rule that I can't request that rules be made! ::)

P.S. To anyone who isn't incapable of coherent, intelligible thought, it was at least relatively clear that said "suggestion" for said "rule" was rhetorical, was it not? Clearly we don't need such a thing written in stone to have infringers cast out and forever shunned...just more of a general mindset that CJ is aware of the request, and he will deal with it himself...that posting about it in the forums cannot and will not expedite or in any way affect or effect the process...and so what then is the point of posting it?

Wyz

Ok, glad we have that resolved now!

Let me make a comment about the whole releasing of code:
I'd like all code to be released but that is up to CJ really, there is no point in having discussions about it really. CJ will do it when and if he has time for it, as monkey already pointed out.
There is a momentum now but if we rush things we might lose it two weeks in because we haven't thought things trough properly and we'll have to back track. Let me assure you, even though things look quite they are very much in motion, interested people are talking and CJ has been informed. So chill, we'll get there.

Btw, moving the 2.x branch to scummVM would be a really good idea in my opinion as soon as it gets released in due time.
Life is like an adventure without the pixel hunts.

timofonic

Quote from: monkey_05_06 on Wed 01/02/2012 16:14:22
Quote from: monkey_05_06 on Tue 31/01/2012 20:13:27So, given the fact that CJ has, until very, very recently, been the sole contributor to the AGS codebase, why would you assume that he would have the code in a source control repository to begin with? I'm not saying he doesn't, wouldn't, shouldn't, couldn't, etc., but I don't understand your reason for assuming that he did, and then why you're being so specific as to state "Visual SourceSafe repo".

Quote from: timofonic on Wed 01/02/2012 09:46:23He said about using VSS for AGS development, I talked with him over a PM. So please don't attack me like this way, at least for this ;)

I'm sorry, but what? Nobody's attacking you, stop being an idiot please. All I did was ask why you were making these assumptions. If CJ told you that over a PM then that's fine. That's all you had to say. Again, it hasn't been discussed in the public forum.

Quote from: timofonic on Wed 01/02/2012 09:46:23He said about to release it in a PM too, so maybe he forgot it due to being too busy.

Right. After more than a decade working on developing a program, one that spawned this community which regularly has annual and even sub-annual real-life meetings of its international members, I'm sure he forgot about AGS. Sorry, but you're making my brain hurt.

I'm sorry to read that, I hope your brain gets better soon.

Quote from: monkey_05_06 on Wed 01/02/2012 16:14:22
Quote from: timofonic on Wed 01/02/2012 09:46:23People over ScummVM Team is quite interested on older AGS releases, they want to support classic AGS games and that's part of their needs for the task.

He can do whatever may like, but I have great faith in his words said to me and others :)

Great! You should believe in CJ. He's a good guy. And ScummVM is certainly more than welcome to use the code of existing or prior engine versions in accordance with their respective licenses. Currently there are no 2.x branches of the engine which are open source, but CJ will resolve that, again, if and when he has time.

It's OK then. We both agree on this.


Quote from: monkey_05_06 on Wed 01/02/2012 16:14:22
Quote from: timofonic on Wed 01/02/2012 09:46:23I don't want to annoy him, but the situation is quite frustrating to a lot of people wanting to do something to preserve his works to the world. There's momentum to be used, instead people get bored waiting for it.

You're contradicting yourself. You say you don't want to be a nuisance but in the same breath turn and say that CJ is being frustrating by not bowing down immediately before your commands. Honestly, this is all starting to leave a bad taste in my mouth, but for now I'll hold onto the belief that you're just the worst spokesperson that ScummVM could have hoped for (no technical knowledge, poor communication skills, total lack of appreciation for the rights of the author and copyright holder and his ability to make intelligent decisions, etc.).

He's not frustrating, but the current situation to both the AGS community and other involved parties. I understand his situation partially, but unfortunately I don't  know him personally.

I'm not a spokesperson, just an user. Anyway, I'm sorry if I looked like one. So I prefer those responsabilities bieng done by the official people for that task, you'll enjoy my absence in ScummVM-related topics from now :)

Thanks for your personal rant about me, it's very appreciative ;)

Quote from: monkey_05_06 on Wed 01/02/2012 16:14:22
Quote from: timofonic on Wed 01/02/2012 09:46:23The same happen to reorganizing the AGS project, even different roles like site maintainer and webmaster.

An "AGS Foundation" would be quite nice to make the project bigger in the future, but maybe that's a quite big task...

I don't understand why "site maintainer" and "webmaster" should necessitate separate positions. Should the webmaster be competent enough to maintain the site? Certainly delegating things to other people to help out would be fine, but this is yet another example that despite your inherent love for the modeling of the ScummVM team and project organization, you understand absolutely nothing about it.

That depends on the technical side of the site. I would say it's possible in most cases.

Anyway, the example was erratical so nevermind...

Quote from: monkey_05_06 on Wed 01/02/2012 16:14:22
Quote from: timofonic on Wed 01/02/2012 09:46:23Monkey, you request too much rules. Do you want to be the forum dictator or something? :)
Of course I want to be forum dictator. I'm a total power-hungry prick. How else could I have mustered the strength or courage to ask you to just accept what CJ has already told you and stop spamming the forums with these posts demanding that CJ follow through right now? I mean, how dare I ask you to show a bit of courtesy, respect, or appreciation to the man who has made this very community a possibility by his tireless hard work, determination, and undying dedication?

I didn't try to lack of courtesy, respect or appreciation to CJ. It wasn't my intention. The language barrier seems a problem here too.

Quote from: monkey_05_06 on Wed 01/02/2012 16:14:22
Quote from: Calin Leafshade on Wed 01/02/2012 10:21:08yea monkey,

stop requesting rules.

Calin, stop requesting it be made a rule that I can't request that rules be made! ::)

P.S. To anyone who isn't incapable of coherent, intelligible thought, it was at least relatively clear that said "suggestion" for said "rule" was rhetorical, was it not? Clearly we don't need such a thing written in stone to have infringers cast out and forever shunned...just more of a general mindset that CJ is aware of the request, and he will deal with it himself...that posting about it in the forums cannot and will not expedite or in any way affect or effect the process...and so what then is the point of posting it?

Whatever...

pcj

I think we all need to follow the advice in monkey's sig and not feed the trolls....getting a bit OT in this thread too.
Space Quest: Vohaul Strikes Back is now available to download!

RickJ

I don't think Tim is a troll.  He is making a noble attempt to try to bring to disparate communities together despite their cultural (as in cyber not ethnic) differences.  It's a near impossible and thankless task.

Tim thanks for the effort.

m0ds

Yes, and thanks for the email timfonic. Once we know what CJ wants and truly what the AGS team can deliver, there is no point denying the possibility of ScummVM stuff. I can't speak for the man but will definitely pass your wishes on, and any new team formed should really think about them. There are lots of questions worthy of answering at the mo but some form of foundation would be good at least to begin with, IMO. So we know what our goals are for AGS for the future in a clear form.

monkey0506

I'm sorry if I've been a bit short with Tim, or anyone else, but I think Mark has summed it up nicely. We're aware of the situation at hand, and good points have been raised, but if we're just restating the same things then we're chasing ourselves around in circles without getting anywhere.

At this point, we are waiting on CJ for various things, but it doesn't mean that we're incapable of taking any action. We do have the source code of the engine. At the very least, beginning to refactor the code now could only help things further down the road.

timofonic

Thanks for the support, I appreciate it a lot!

Despite my opinions can be controversial, I try to do my best for both communities. I'm a very fan of the adventure game genre and I believe AGS is one of the best things happened to it.

So even if some people don't agree or commit mistakes opinating about me, I came back here.

Monkey, don't worry. I don't get it as something personal. I accept your apologies ;)

TheDude

Please, nooOOOoooOoo to Qt. I had an entire mouse once that wouldn't work with Qt because it's mouse click events.

It was fun navigating every Qt program such as VLC player with the keyboard...or not.

bicilotti

Who has got the 'keys' to adventuregamestudio.co.uk, apart from CJ? I might want to ask him a favour.

Snake

Quote from: bicilotti on Sun 19/02/2012 20:45:29
Who has got the 'keys' to adventuregamestudio.co.uk, apart from CJ? I might want to ask him a favour.
And why it keeps telling me I have a new message when I don't :(
Grim: "You're making me want to quit smoking... stop it!;)"
miguel: "I second Grim, stop this nonsense! I love my cigarettes!"

Ryan Timothy B

Yes, someone really needs to update this forum to the new scripts. I vote Calin because I know how much he likes to be voted into doing things.

Snarky

Maybe we should start talking about how long we can wait around for CJ to drop by, and when we need to start trying to find alternative ways to move forward.

bicilotti

Quote from: Snarky on Mon 20/02/2012 01:18:02
Maybe we should start talking about how long we can wait around for CJ to drop by, and when we need to start trying to find alternative ways to move forward.

Personally I just need someone to set up the nomination page for the ags awards.

Construed

I felt sorry for myself because I had no shoes.
Then I met the man with no feet.

Tabata

Quote from: Snake on Mon 20/02/2012 00:01:13
Quote from: bicilotti on Sun 19/02/2012 20:45:29
Who has got the 'keys' to adventuregamestudio.co.uk, apart from CJ? I might want to ask him a favour.
And why it keeps telling me I have a new message when I don't :(

... sounds to me like this   ;)

m0ds

Bici your best bet is AGA, scotch if you can find him or hajo in irc, or try andail or gilbot. If none of them have it, it is only CJ (and im pretty sure it's only CJ). I sent him another msg over the weekend, no response. I agree with Snarky, how long should we wait? Maybe it will become relevant to chip into a new forum and web host that a bunch of people can manage - if worse comes to worse.

Calin Leafshade

As much as it pains me to say it, we should consider moving the forums to another host. I'm not really sure how to really push forward.

adventuregamestudio.co.uk is the home of AGS but if the owner of adventuregamestudio.co.uk doesn't have time to admin the site and the owner of adventuregamestudio.co.uk is hesitant to shift ownership of the site to someone else then what is the solution?

Seems like the only resolution to that conflict is a community fracture. Which I think everyone would oppose.

miguel

My humble opinion on this specific matter (forum) is that the community needs a new server and forum. We are more than 7,000 here and one of this days we'll have our lovely bigbluecup exploding into pieces!

Server money will be easy to gather, I'm sure that lots of people will step forward if needed. Also, there are capable guys and girls here to manage a new forum.
I may be mistaken but I don't think CJ would be mad if the community felt that they need a better place to "live". I think he just doesn't have the time for AGS right now.

I vote for making the transition to a new server and forum. It's really frustrating not being able to come to the forums because of a server issue.

Maybe the new forum could not allow people from downloading AGS until CJ agrees with it? I don't know, I think it could work. 
Working on a RON game!!!!!

bicilotti

Thankee m0ds, I will do what you said (and if I were to find scotch, well, that would be a nice bonus).

Quote from: Calin Leafshade on Mon 20/02/2012 10:21:59
adventuregamestudio.co.uk is the home of AGS but if the owner of adventuregamestudio.co.uk doesn't have time to admin the site and the owner of adventuregamestudio.co.uk is hesitant to shift ownership of the site to someone else then what is the solution?

I think he once said he was a bit worried about giving access to other people for a number of reasons ( one that I recall: protect the privacy of bigbluecup's member, as giving access to the site would mean give access to all members' PMs, albeit only potentially ).

While we discuss which direction should the AGS project take, I will contact the folks mentioned by m0ds to see if someone has full access to the machine.
Until then I feel it could be premature talking of switching servers/boards/etc.

dasjoe dixit: scotch has it, but he went missing, AGA might have it. I will pm AGA.

Ryan Timothy B

Quote[..]as giving access to the site would mean give access to all members' PMs, albeit only potentially
If this person is to have full access over the SQL databases, which would only seem logical, PM snooping would be unbelievably easy. So a trusted member is definitely a must.
...So maybe I should unvote Calin.. (joking) ;)

On a side note, AdventureGameStudio.net  is available. .com seems to be held hostage by a company trying to sell the domain - I think. I'd do a whois domain inquiry but I'm on my cell.

Calin Leafshade

I would assume that PMs and stuff are all obfuscated in the raw database.

bicilotti

Quote from: Calin Leafshade on Mon 20/02/2012 13:30:30
I would assume that PMs and stuff are all obfuscated in the raw database.

I tought the same, but...

Quote from: Pumaman on Mon 24/10/2011 21:30:27
I should also appoint a deputy to finish the new website (or open-source it). But the problem with this is that it requires a copy of the DB to be able to work on it, and I would need to spend time taking a DB backup and cleaning it up (eg. removing private data like PM's) before making it public.


cat

That would explain why it takes so much time to open the PM screen.

m0ds

Yeah, the PM feature hasn't been fun since November :( Well, good luck Bici!

Ryan Timothy B

Quote from: Calin Leafshade on Mon 20/02/2012 13:30:30
I would assume that PMs and stuff are all obfuscated in the raw database.
Nope, the tables are easily accessible, if you had Admin access, and there is no "obfuscation of the raw database". ;)

The table is just like so with these columns:
ID_PM     int(10)
ID_MEMBER_FROM    mediumint(8 )   //damn smiley faces
deletedBySender     tinyint(3)
fromName     tinytext
msgtime     int(10)
subject     tinytext
body     text

The body is the Text of the PM, then there's the subject which is a Tinytext. So you could easily just read through every PM one after another directly from the SQL table - if you were lazy. The efficient way would be to just modify the inbox script to have all PM's visible from the "snoopy moderator's" account. ;)

Not that PM's contain anything overly important, but it's still good to have them locked down.

Edit: Then there's the table which contains the information if the PM has been read or not:
ID_PM    int(10)
ID_MEMBER     mediumint(8 )   // that damn smiley face again
labels     varchar(60)
bcc     tinyint(3)
is_read     tinyint(3)
deleted     tinyint(3)
(Not that you can really gather anything useful from that table)

And what I meant about "no obfuscation" is that once you gather the table passwords from the php scripts, it could be viewed without any issues as long as you upload a script to gather the information for you. Or if the server has a viewable database script, then it's even easier.

Edit: What I'm basically saying is Don't PM Anyone Anything Important. Save that for more secure channels. Just saying...

Wyz

I still have hope CJ will get back to us. I hope when he does he will give full access to the server to someone he trusts who has time to help us out.
Life is like an adventure without the pixel hunts.

m0ds

Quote from: Wyz on Mon 20/02/2012 14:56:03
I still have hope CJ will get back to us. I hope when he does he will give full access to the server to someone he trusts who has time to help us out.

Same. My comments about a second site were really geared towards the awards - cos they don't usually happen in March :/ It can become difficult to keep momentum up when there are long periods of not a lot, and that can lead to good input, ideas & people getting lost in time. That's my main concern. This year has a lot of productive potential, but it does need momentum before it can properly have stability. So yes, crossed fingers are important. Hopefully CJ will appear from behind a burning bush  :=


Alan v.Drake


Snarky

Quote from: Ryan Timothy on Mon 20/02/2012 12:44:22
On a side note, AdventureGameStudio.net  is available. .com seems to be held hostage by a company trying to sell the domain - I think. I'd do a whois domain inquiry but I'm on my cell.

I went ahead and registered adventuregamestudio.org and adventuregamestudio.net. Once we've worked out the server situation, one way or another, we'll have those domains to use. (I think they're preferable to adventuregamestudio.co.uk or adventuregamestudio.co.uk, personally.)

Ryan Timothy B


m0ds

CJ replied saying he will come and sort it (the awards noms) soon.

Try not to think of his "soon" as my FoY "soon" ::)

edit: YAY! CJ  :o

Privateer Puddin'



Pumaman

Ok I think I've sorted the noms page, and sent it to bicilotti.

Sorry for my absence around here ... I've just been really busy lately.

The other thing I really want to do is finish off the new website ... it's so nearly there, 95% complete and just needs the Search page and Post Comment form to be done. I hope I'll have the time to do that "soon", but is there anything else people are needing from me?

Ponch

Quote from: Pumaman on Tue 28/02/2012 23:22:39
is there anything else people are needing from me?

Can I have a hug? Or possibly a pony?  :-*

Calin Leafshade

The source of AGS.Native (in any state, we'll fix it up) would be great. A lot of people are really anxious to get a look at the compiler.

timofonic

Quote from: Pumaman on Tue 28/02/2012 23:22:39
is there anything else people are needing from me?

Yes, older AGS sources (better if since 1.x days, even better if releasing the VSS repository). Pretty pleaseee...pleaseeee, with sugar on top :)

ScummVM Team want it for easier support of legacy AGS versions, there's a WIP engine from the "fuzzie" team member.

fuzzie

Quote from: timofonic on Sun 04/03/2012 19:23:52
Quote from: Pumaman on Tue 28/02/2012 23:22:39
is there anything else people are needing from me?
ScummVM Team want it for easier support of legacy AGS versions

I would definitely put AGS.Native at the top of the list, myself.

There's no huge hurry for the legacy code, I think, especially since JJS has been doing a really good job of puzzling out the behaviour of the various 2.x AGS versions.

tzachs

Quote from: Pumaman on Tue 28/02/2012 23:22:39
is there anything else people are needing from me?

Sub-forum(s) for editor and engine development.

monkey0506

It's nice to see that absolutely everything that we were, as a community, doing about this has dissolved completely into some sort of distant cultural memory.

Respect CJ, sure, but the point of him open-sourcing the software was so that we could maintain it.

The source of AGS.Native would be nice, but it's not even essential. If we're refactoring all the code anyway, we could just write our own compiler.

I actually pulled back on the throttle of some of what I was doing due to certain comments of a similar nature to this one (about nothing being done), and I was somewhat upset at those people who apparently never realized how actively I had been working on this.

In any case, I've (personally) decided that SDL seems to be more (pro)actively developed, if nothing else, evidenced by the fact that Allegro only so very recently got ported to Android. Based on that, I've started learning SDL myself. Working on getting it to build in Code::Blocks using the GCC 4.7 compiler so we can take advantage of C++11. It would be ignorant to hold ourselves back from the great functionality of C++11 unless there was a specific reason for doing so (which to date, no one has presented me with).

I'm not angry at anyone in particular, but it does seem a waste of everything CJ did for all the momentum we built up to just die off without anything to show for it. I for one, am going to stand behind what I said, and keep contributing...however I can. Whether my efforts end up totally for naught, whether I end up refactoring the entire code base, or whether I end up writing my own engine based off of AGS 3.2.1....I'm just going to keep trudging blindly forward in the hopes that someday someone will find some use of my work.


-monkey

fuzzie

Quote from: monkey_05_06 on Wed 14/03/2012 18:00:38
The source of AGS.Native would be nice, but it's not even essential. If we're refactoring all the code anyway, we could just write our own compiler.

To be clear, the script compiler in Common/csparser.cpp seems to be up-to-date. But I don't think anyone has been suggesting refactoring the editor side of things? So improving the editor iteratively based on AGS.Native source (if available) seems like a far more productive idea, even if it isn't essential.

Quote from: monkey_05_06 on Wed 14/03/2012 18:00:38
It would be ignorant to hold ourselves back from the great functionality of C++11 unless there was a specific reason for doing so (which to date, no one has presented me with).

Portability (to e.g. console SDKs) is the usual problem with using C++11.

It's unfortunate that my rewritten AGS code is stuck with an unpopular license due to being a ScummVM engine, but I've written an awful lot of code in 90+ commits (and there's a lot of uncommitted work, it's difficult to find the time), and obviously I'm hoping that when it's mostly done (a few months, probably), it will be at least a nice reference for anyone trying to do refactoring of the original code, even if the license makes it unacceptable as-is as an ongoing engine for the community.

In the meantime, all my work is public, and there's a lot of people who have been very positive about it, both from the AGS community and outsiders, as well as various people interested in contributing code. JJS's work on backwards compatibility as well as portability and improvements has had a very clearly positive response too - I don't think that work can be discarded as 'without anything to show for it'.

Calin Leafshade

fuzzie is wise, you should heed her words.

To say that "nothing has been done" is insulting to those that have done something. Fuzzie's repos is very active and JJS's work is invaluable.

What would be more accurate is that *you* have done nothing.

Dave Gilbert

Quote from: Calin Leafshade on Wed 14/03/2012 19:31:25
What would be more accurate is that *you* have done nothing.

To be fair, there are so many threads about this issue scattered all over the forum that it is difficult to asses what actually IS being done. I wasn't aware that anybody had been working on this either. It wasn't that long ago that I was asked to be put in charge of managing the development of the engine (which I eventually accepted), and while I don't mind that things are going in another direction, nobody ever told me that this was happening. Or if they did, it was in one of the many forum threads about this topic. I had just assumed that progress and/or interest had completely stopped.

So for the sake of everyone else like me: what, exactly, is being done for the future development of AGS? Who is in charge of it (if anybody)? What are the short term plans? How long is a piece of string?

-Dave


Calin Leafshade

Well the code is available for all. In reality anyone can set up a branch of the engine and move forward with it. The only person who could sanction any kind of "official" AGS development would be CJ and he hasn't done so.

So if you (or indeed anyone) wants to advance the future of AGS they are welcome to do so. Set up a branch, recruit some coders and have at it.

Since the community (and remember this is only the big blue cup forum community, AGS as a whole is bigger than that) is finding it hard to do anything concrete due to drowning in bureaucracy this might be the best way forward. If everyone moves to do their own thing then eventually the weaker projects will die out and the strong ones will merge or compete until one is the clearly better product. Perhaps we should leave this to market forces and allow those who wish to take matters into their own hands to do so without fear of a backlash.

monkey0506

To be clear, my post was more directly about what Dave is also referencing.

fuzzie has created a fork that if for no other reason than the license alone is completely incompatible with the trunk and official development branch. I don't mean to discount the work that's being done there, but it isn't what I was talking about, as I will explain.

JJS was already developing those ports before any of the aforementioned "momentum" of "managing the development of the engine", etc. set forth. Yes, what he's doing is good and beneficial, but it again is unrelated.

Calin, to say that I have done nothing is simply inflammatory without cause.

I've already made it clear that I don't feel I have the same technical proficiency with C++ as those like JJS or fuzzie. I have made that very clear (from the very first post in this thread!!). So, I don't have as much to show for my efforts as they do (if indeed anything at all).

Still, I was referring to the sense of direction that we finally had built up, that someone was actually going to step in as a lead of the project, that someone was going to take charge of the technical aspect therein. Individuals creating incompatible branches and forks is not what I was referring to.

Aside from the likes of JJS and fuzzie who are working, much like myself, but with greater proficiency in C++, as individuals with their own thoughts, feelings, ideas, and goals in mind, there is no single person currently taking charge of AGS as a whole to move the project forward.

Calin you posted while I was typing, and this "fear of a backlash" is exactly what I was referring to. If nothing else, organizing a team from the forum community would be better than leaving it to a few sparse individuals to bear the weight on their own. As AGS is open source, there's nothing preventing anyone from trying to take it in a new direction, but the fact of the matter is that the move forward has been so slow as to negate the work that has and is being done.

Dave Gilbert

#198
Yes, I meant something "official." Having a bunch of different branches with their own different features and no way to merge them doesn't seem like the best way to go.  What I was hoping for (and others, I'm sure) is a return to the Old Days - one official version of the engine that gets updated on a regular basis.

Sure,  I could start using one of the other branches (or make one of my own), but if another branch develops cool features it will suck that I can't use them. Or if one branch becomes ported to iOS and mine doesn't. Or... well, there are too many variables.

Is there a current branch of the engine that is the most stable/further along? Can we just make that the official branch and be done with it?

-Dave

fuzzie

Quote from: monkey_05_06 on Wed 14/03/2012 20:23:03
fuzzie has created a fork that if for no other reason than the license alone is completely incompatible with the trunk and official development branch.

Yes, mostly I'm just mentioning it since it could perhaps be useful at some point (any relevant bits could be dual-licensed under the Artistic License 2.0 too), but if the community isn't happy with the GPL for the main development branch then it indeed isn't too relevant.

Quote from: monkey_05_06 on Wed 14/03/2012 20:23:03
Still, I was referring to the sense of direction that we finally had built up, that someone was actually going to step in as a lead of the project, that someone was going to take charge of the technical aspect therein. Individuals creating incompatible branches and forks is not what I was referring to.

Aside from the likes of JJS and fuzzie who are working, much like myself, but with greater proficiency in C++, as individuals with their own thoughts, feelings, ideas, and goals in mind, there is no single person currently taking charge of AGS as a whole to move the project forward.

Speaking as an outsider (obviously): it seems like setting some goals in terms of bugfixes and small features might be a good start, since no-one seems to have both the ability and time to start any serious refactoring work, which I think has usually been the first step suggested in most of the discussion so far.

Quote from: Dave Gilbert on Wed 14/03/2012 20:37:15
Is there a current branch of the engine that is the most stable/further along? Can we just make that the official branch and be done with it?

Well, presumably JJS's branch would be the one to pick, since it has improved portability and bugfixes, but then the priority there is more about backwards compatibility than any new development (inevitably).

monkey0506

I understand that the post could have been misconstrued, but there was a big movement in favor of organizing a forum-based team that largely just fell apart. That is what I was talking about.

It is great that we have those who are willing to devote their own time to pushing things forward like portability, but ultimately portability alone is not going to push AGS forward into making it a better engine as such, just a more widely available one.

I think that it would not be a bad idea to start collecting and maintaining an updated bug and feature/request tracker. The existing one is in very, very poor shape at the moment, and just simply seeing what issues are currently outstanding could indeed be a great motivator for when someone does have the time to look at it.

It would be nice to see JJS' repo actually merged with the official dev branch so we could continue building from there with some level of synchronicity. His primary goal has been porting and reaching into the existing backwards compatibility of the code, but it would be good for those efforts to be maintained in the refactoring in so far as they don't inhibit the proposed AGS 4.0.

Snarky

#201
The situation is really just kind of unfortunate at the moment. For a while it seemed like CJ had pretty much left, and that was difficult, but we were getting ready to find a new way forward. Then he kind of came back, which is awesome, but it took some of the wind out of the sails of the whole community organization thing. Now we seem to be stuck somewhere in between, where CJ is around occasionally but doesn't have the time to deal with a lot of the day-to-day things, but no one else has the authority or in fact the necessary permissions to step up.

There are still a number of things that need to be done in order to make real progress on an open-source version, like setting up a dedicated sub-forum (so that people who are interested can get some idea of what the hell is going on), having someone actively manage the official code tree, releasing those final bits of code that are missing, and getting the forums to run more reliably than they have over the last few months. And we need to have some clarity about who's doing what, and open lines of communication with them. (That's part of what we were talking about having a "community lead" for: to let people know what's going on and listen to their concerns.)

I really think it would be best if CJ would delegate some tasks, along with the necessary access to servers, repos or whatever. In fact, unless he gets a lot more free time in the near future, it's a necessity, because things aren't working the way they are now (in the case of the forums, pretty much literally: at least I get timeouts about 30% of the time, and on pretty much every search).

Given the results of the straw poll, I think any or all of the highest-polled candidates would have the trust of the community, so just pick any of them. Or someone else. But AGS needs someone to take care of it if it's not going to wither, and the attention it's getting right now is not enough. (Actually, that's not really accurate, since CJ has been taking care of a couple of issues over the last week or so. So let's say the level of attention seen for most of this year.)

monkey0506

I think a collaborative effort between Mark, Dave, and myself (based on the results of that straw poll, not just drawing three random names :P) could produce some good results. We all have different experiences and expectations for AGS of course, but I've worked with them both before and we seem to get on well enough. Also, it would be nice to have more than just one person in case one of us wasn't around for a little while. It would help alleviate the effects we are now feeling due to CJ's absence.

You're right that as far as the official community goes, CJ is still holding a lot of keys that are at the very least delaying progress into certain areas. I know he doesn't want to lose too much control, but I wonder how he'd feel about giving provisional interim priviledges to a small group in that regard.

Some things though I think we can definitely take a proactive effort in, even in the meantime.

Wyz

I've been working on a plan for a while now under the hood so I could fine tune it as much as possible but it seems to be the right time to publish it. Do know it is only a plan, nowhere in it will I select people for certain tasks. It is just as to give future AGS development a possible sense of direction. I'll open a separate topic to keep the discussion uncluttered.

There is happening more then you think is happening monkey, things are a bit slow though. I wish I could help out but I currenly don't even have time to play adventures.  :'(
So, this is the best I could do.
Life is like an adventure without the pixel hunts.

sonneveld

#204
Hi,

I'm interested in helping out! I have a bit of spare time at the moment and have started looking into refactoring and possibly porting the AGS engine to macosx.  I need to properly read the forums threads but it looks like:

- there are a few different forks.
- the scummvm team is porting ags over to their platform to run current and older games (scummvm is gpl, which is totally cool but prevents possible future ios ports? at least commercially <-- wrong about that, I was confused with recent VLC kerfuffle. eg, recent wolf3d ios release is gpl)
- however there is still interest in maintaining current ags and adding new features.

Right now I've just forked the svn copy of ags and started splitting ac.cpp.  My macport stalled when I realised that allegro4 doesn't even compile on macos lion.  There may need to be discussion about porting to allegro5/sdl/etc.

- Nick

edit: re gpl

Sslaxx

Sounds good. Your sources available on a site like GitHub or Gitorious?
Stuart "Sslaxx" Moore.

fuzzie

#206
Quote from: sonneveld on Mon 19/03/2012 12:16:42
- the scummvm team is porting ags over to their platform to run current and older games (scummvm is gpl, which is totally cool but prevents possible future ios ports? at least commercially)

It's more of a rewrite than a port. The code could be made available under the Artistic License, but obviously anyone wanting to use it would have to port it away from the ScummVM framework again.

The license is no problem for iOS: there are commercial ports of various games (for example, Gobliiins and Beneath a Steel Sky: Remastered) which are using ScummVM. It's apparently an issue for games that wish to integrate with Steam, though, as well as games wanting to use other proprietary plugins, so apparently the GPL is indeed not an option.

Quote from: sonneveld on Mon 19/03/2012 12:16:42
Right now I've just forked the svn copy of ags and started splitting ac.cpp.  My macport stalled when I realised that allegro4 doesn't even compile on macos lion.  There may need to be discussion about porting to allegro5/sdl/etc.

I would suggest starting with JJS's repository rather than the svn version. And you might find it simpler to just fix Allegro 4 to build properly for you, given how intermingled the graphics code is..

Edit: I'm pretty familiar with the AGS code now, so: I'm usually around as 'fuzzie' on freenode if anyone needs any help understanding bits of the code (I don't know anything about how to build it etc though).

sonneveld

Quote from: Sslaxx on Mon 19/03/2012 12:48:16
Sounds good. Your sources available on a site like GitHub or Gitorious?

It wasn't, but is now: https://github.com/sonneveld/ags

It's mainly just me shuffling things around at the moment.

sonneveld

Quote from: fuzzie on Mon 19/03/2012 12:49:31
I would suggest starting with JJS's repository rather than the svn version. And you might find it simpler to just fix Allegro 4 to build properly for you, given how intermingled the graphics code is..

Edit: I'm pretty familiar with the AGS code now, so: I'm usually around as 'fuzzie' on freenode if anyone needs any help understanding bits of the code (I don't know anything about how to build it etc though).

ah whoops, I started with a fresh checkout.  I think Allegro4 is a dead end as most of the new releases are for v5, but it might be worth it if it's not too much hassle.

fuzzie

Quote from: sonneveld on Tue 20/03/2012 08:22:13
It's mainly just me shuffling things around at the moment.

Shuffling things around like that looks like the best approach. :) I autogenerated comments for the script functions using the editor data from Editor/AGS.Editor/Resources/agsdefns.sh, which might be helpful for you to do too, if you're going to be autogenerating comments.

(Note that you've linked to an old version of my tree in the README - you probably meant https://github.com/fuzzie/scummvm/tree/ags/engines/ags, not the one linking directly to a hash.)

m0ds


AGA

Okay, so I'm now admin.  Go here if you want to make suggestions / requests, please.

SMF spam blocked by CleanTalk