Jibble

Author Topic: The future of the AGS engine: STALEMATE!  (Read 33970 times)

Wyz

  • anno 1986
    • I can help with making music
    • I can help with story design
    • I can help with translating
    • I can help with voice acting
    • I can help with web design
    • Wyz worked on one or more games that won an AGS Award!
    •  
    • Wyz worked on one or more games that was nominated for an AGS Award!
Re: Regarding C++ and the state of the engine source.
« Reply #20 on: 11 Jan 2012, 18:20 »
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: [Select]
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)


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?
« Last Edit: 11 Jan 2012, 18:24 by Wyz »
Life is like an adventure without the pixel hunts.

Calin Leafshade

  • Long live King Cat!
    • I can help with making music
    • I can help with voice acting
    • Calin Leafshade worked on one or more games that won an AGS Award!
    •  
    • Calin Leafshade worked on one or more games that was nominated for an AGS Award!
Re: Regarding C++ and the state of the engine source.
« Reply #21 on: 11 Jan 2012, 19:32 »
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.
« Last Edit: 11 Jan 2012, 19:45 by Calin Leafshade »

monkey0506

  • SEND PIZZA.
    • Best Innovation Award Winner 2017, for his work to help AGS games reach the widest possible audience - through popular distribution platforms (Steam, Galaxy) as well as other operating systems (Android, Linux)
    • monkey0506 worked on one or more games that won an AGS Award!
    •  
    • monkey0506 worked on one or more games that was nominated for an AGS Award!
Re: Regarding C++ and the state of the engine source.
« Reply #22 on: 11 Jan 2012, 21:27 »
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.
« Last Edit: 12 Jan 2012, 05:07 by monkey_05_06 »

Wyz

  • anno 1986
    • I can help with making music
    • I can help with story design
    • I can help with translating
    • I can help with voice acting
    • I can help with web design
    • Wyz worked on one or more games that won an AGS Award!
    •  
    • Wyz worked on one or more games that was nominated for an AGS Award!
Re: Regarding C++ and the state of the engine source.
« Reply #23 on: 12 Jan 2012, 03:49 »
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.

Re: Regarding C++ and the state of the engine source.
« Reply #24 on: 12 Jan 2012, 08:37 »
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

  • Long live King Cat!
    • I can help with making music
    • I can help with voice acting
    • Calin Leafshade worked on one or more games that won an AGS Award!
    •  
    • Calin Leafshade worked on one or more games that was nominated for an AGS Award!
Re: Regarding C++ and the state of the engine source.
« Reply #25 on: 12 Jan 2012, 08:52 »
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?

« Last Edit: 12 Jan 2012, 23:13 by Calin Leafshade »

Alan v.Drake

  • ...
    • Alan v.Drake worked on one or more games that won an AGS Award!
    •  
    • Alan v.Drake worked on one or more games that was nominated for an AGS Award!
Re: Regarding C++ and the state of the engine source.
« Reply #26 on: 12 Jan 2012, 21:58 »
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

  • Mittens Serf
  • GARBAAAAAGE DAAAAAAY!
    • I can help with animation
    • I can help with characters
    • Lifetime Achievement Award Winner
    • I can help with making music
    • I can help with proof reading
    • I can help with scripting
    • I can help with story design
    • Shane 'ProgZmax' Stevens worked on one or more games that won an AGS Award!
    •  
    • Shane 'ProgZmax' Stevens worked on one or more games that was nominated for an AGS Award!
Re: Regarding C++ and the state of the engine source.
« Reply #27 on: 12 Jan 2012, 22:58 »
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

  • Guest
Re: Regarding C++ and the state of the engine source.
« Reply #28 on: 13 Jan 2012, 16:19 »
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  :=
« Last Edit: 13 Jan 2012, 16:21 by m0ds »

Calin Leafshade

  • Long live King Cat!
    • I can help with making music
    • I can help with voice acting
    • Calin Leafshade worked on one or more games that won an AGS Award!
    •  
    • Calin Leafshade worked on one or more games that was nominated for an AGS Award!
Re: Regarding C++ and the state of the engine source.
« Reply #29 on: 13 Jan 2012, 16:27 »
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)
« Last Edit: 13 Jan 2012, 17:29 by Calin Leafshade »

Snarky

  • Global Moderator
  • Global Moderator
  • Mittens Lord
  • Private Insultant
    • Best Innovation Award Winner 2018, for his numerous additions to the AGS open source ecosystem including the new Awards Ceremony client and modules
    • Snarky worked on one or more games that won an AGS Award!
    •  
    • Snarky worked on one or more games that was nominated for an AGS Award!
Re: Regarding C++ and the state of the engine source.
« Reply #30 on: 13 Jan 2012, 17:51 »
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

  • fix'n one thing and break'n two ...
    • I can help with scripting
    • I can help with story design
    • RickJ worked on one or more games that was nominated for an AGS Award!
Re: Regarding C++ and the state of the engine source.
« Reply #31 on: 13 Jan 2012, 19:48 »
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?

Re: Regarding C++ and the state of the engine source.
« Reply #32 on: 13 Jan 2012, 19:52 »
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

  • Long live King Cat!
    • I can help with making music
    • I can help with voice acting
    • Calin Leafshade worked on one or more games that won an AGS Award!
    •  
    • Calin Leafshade worked on one or more games that was nominated for an AGS Award!
Re: Regarding C++ and the state of the engine source.
« Reply #33 on: 13 Jan 2012, 19:55 »
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

  • fix'n one thing and break'n two ...
    • I can help with scripting
    • I can help with story design
    • RickJ worked on one or more games that was nominated for an AGS Award!
Re: Regarding C++ and the state of the engine source.
« Reply #34 on: 13 Jan 2012, 22:34 »
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

  • Long live King Cat!
    • I can help with making music
    • I can help with voice acting
    • Calin Leafshade worked on one or more games that won an AGS Award!
    •  
    • Calin Leafshade worked on one or more games that was nominated for an AGS Award!
Re: Regarding C++ and the state of the engine source.
« Reply #35 on: 13 Jan 2012, 22:42 »
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"

Re: Regarding C++ and the state of the engine source.
« Reply #36 on: 13 Jan 2012, 22:53 »
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.

Quote
What 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.
« Last Edit: 14 Jan 2012, 00:58 by Sslaxx »
Stuart "Sslaxx" Moore.

Snarky

  • Global Moderator
  • Global Moderator
  • Mittens Lord
  • Private Insultant
    • Best Innovation Award Winner 2018, for his numerous additions to the AGS open source ecosystem including the new Awards Ceremony client and modules
    • Snarky worked on one or more games that won an AGS Award!
    •  
    • Snarky worked on one or more games that was nominated for an AGS Award!
Re: Regarding C++ and the state of the engine source.
« Reply #37 on: 13 Jan 2012, 23:11 »
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.

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?
« Last Edit: 13 Jan 2012, 23:19 by Snarky »

Calin Leafshade

  • Long live King Cat!
    • I can help with making music
    • I can help with voice acting
    • Calin Leafshade worked on one or more games that won an AGS Award!
    •  
    • Calin Leafshade worked on one or more games that was nominated for an AGS Award!
Re: Regarding C++ and the state of the engine source.
« Reply #38 on: 13 Jan 2012, 23:31 »
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.

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


That seems reasonable if it comes down to that.

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

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.

Re: Regarding C++ and the state of the engine source.
« Reply #39 on: 14 Jan 2012, 00:17 »
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.

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

I will also make myself available for this position if i am seconded by another member of the community.

I second you.

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.