Messages

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.

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.

[YES, INTERESTED:]

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

[not]

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.

You need two IN-GAME screenshots.  Please update the first post accordingly.  If you do not have two in-game shots I will lock this until you are ready and can comply with the rules (menu/title screens and promotional art do not count as screenshots).

Karens implied that they don't at the moment have anyone to program the game.

[How long should we talk about who is suitable to take leadership of AGS?]

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.

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.

Some of us appear to be putting words in other peoples' mouths here.

The offending line of code was removed, and several other bugs have been fixed, so this game should be functional now. Version 1.1 is up, but it won't work with your old save-games.

Checking it out. You know, the Chicken Run sequence never crashed for me during beta-testing. Odd.

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.

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.

[VERY]

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.

[I]

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.

[not necessarily what I think]

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.

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.

WHOA!!!!!!!!!!!!!!!!THIS helps!!!!!

And you created another account to reply to here why?

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

Walk areas are like that, certainly. I think walk-behinds, regions and hotspots also are low-res.

Lock this baby, http://www.adventuregamestudio.co.uk/yabb/index.php?topic=45119.0 - the game's been released!

thank you

- Alan

Have a good one!

I'd be interested in doing voices, but I'm not sure if the microphone'd be up to the job (never mind my ability or probable lack thereof). I'd suggest Blackthorne as Vohaul by the way, he does a good job of it in the SQ2 remake.

Thanks for the soundtrack, by the way!

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.