The Engine/Editor Development Process

[Lt. Smash]

IMO the most important improvement to AGS would be the extension of the current scripting language.
Please don't forget taking that into account... There are many things missing. Like for, switch, break, return, 2/3..D arrays, static extenders, array.length and many more.

[Wyz]

Well, I kind of agree with Alan v.Drake.
I think if we try to build on the existing code base it might even take longer because we first need to understand it very well, and there is a lot of code there. But also it would be silly to not have a bleeding edge while a bottom up project is in progress. Therefore I think we need to split development up into two (actually three, but I'll get to that) parts:

• Maintenance
  
• Future version
  
  Essentially the idea is that the two branches will meet somewhere in the middle. The future version will of course not reinvent everything, but it will make sure every part of the engine is treated, and keeps everyone motivated because it has a clear goal. Also because AGS is based on a lot of libraries that might not have stand the time as good as AGS, a bottom up project will tackle any issue with portability.
  Speaking of: I think portability is one of the most important things for future versions of AGS. The adventure genre has been revamped and this is caused mainly by the popularity of hand held devices. We must embrace this and try to get a future version working on all of them. The newest versions off Allegro support some of them, SDL support others, well it would be really nice if we wrap around both. Also it would run natively on any system of any importance that way which would be awesome.
  Also when adding things like unicode support, getting that into an existing code base is hell. When you start fresh it will be easy to keep it in mind.
  
  But as I said that is only one part of the process, there should always be a bleeding edge, keep on improving on the original code base. I've also been talking about the engine only, the editor is in fine shape. That does not have to be redefined in any way, but there should be developers keeping it in good shape. There are a few updates that can wait much longer, transparency should be fully featured and the blending modes as Calin made them into a plugin, the smooth rotation plugin etc. would do great in the engine natively. Well I don't feel it's up to me to decide stuff like that but I would like it. So that's the other part, and however it might feel ambiguous to work on two engines separately this is a quite common practise.
  
  I like to state a third branch: the 2.7 branch. People still use it and there have been hundreds of wonderful games made with it. It would be nice if there will be support for them for future platforms. I'm not going to say a lot about it since I've done before in other topics, but getting ScummVM to run it would be awesome.
  
  I know I am repeating myself with all this, but I just want it off my chest. Last things I want to say about it:
  Backwards compatibility is a bless and a curse at the same time. If you start fresh you should not worry about it initially because otherwise it will hold you back. You might change resolution and palette stuff because it will result in a more efficient program, but breaking compatibility. Well in that case a compatibility mode should come in handy. On the other hand: each game comes with an executable. The only reason this would be useful is to allow older games to be played with the newer engine for platform compatibility. This might be resolved by porting the 2.x and 3.x branches separately. Let's not worry about that for now!
  
  

  
  No one is seemingly interested in leading the project. We need a project lead who is a capable programmer and a decent leader. I know who I would choose for the job *cough*Wyz*cough* but that doesn't mean that they or indeed anyone else is willing/able to put in the work.
  

  
  Well I'm flattered, but unfortunately I feel like I don't have the time a project like this needs. But eventually if noone does come forward I will.
  
  

  
  Out of those, I'm most familiar with Google Code, but only as a consumer and not as a project owner. If anyone has better suggestions or bad experiences with GC, let us know. Otherwise, I propose that the eventual chief starts a new project there.
  

  
  Same for me, I haven't yet found any obvious flaws at Google Code. It has a wiki, bug tracker, code browser and a really really nice search feature for code. Also everyone with a Google account can use it immediately, well not that it matters. Most programmers already have a multitude of accounts for repo sites.
  Oh, also I really encourage the use of decentralised version control like git and mercurial. It means people can work separately without bother and decreases the amount of administration needed and that we can use. I prefer mercurial because it's lightweight and easy easier to learn.
  
  Loong loooooong post, sorry.
  Kudos if you've read it.

[mjomble]

Oh, also I really encourage the use of decentralised version control like git and mercurial. It means people can work separately without bother and decreases the amount of administration needed and that we can use. I prefer mercurial because it's lightweight and easy easier to learn.

In that case, we might want to try Atlassian instead.
It's also free for open souce projects.
And although my experience with both Git and Hg is rather limited, I also prefer Hg.

[Wyz]

Ah, I don't have experience with that site, but it looks nice.

[Monsieur OUXX]

Digging up (only one week old).

About the question of getting CJ's blessing : You might want his blessing for the development roadmap, but I think you don't need to wait to create such tools as a bug tracker, etc.

In other words: ask him about the goals, not necessarily about the underlying work organization/structure/toolset.

[dbuske]

When do the powers that be think a new version of AGS will be released?

[Calin Leafshade]

Since JJS and bero have a decent crossplatform build process and stuff i propose we adopt their branch as the official (or at least the actively developed) one.

[Sslaxx]

Since JJS and bero have a decent crossplatform build process and stuff i propose we adopt their branch as the official (or at least the actively developed) one.

I assume they're working together, then? Is there anywhere their stuff is available?

[Calin Leafshade]

Heres Beros version: http://gitorious.org/ags/ags

JJS's version is a fork of that repos.

Edmunditos mac version is also a fork

[timofonic]

Heres Beros version: http://gitorious.org/ags/ags

JJS's version is a fork of that repos.

Edmunditos mac version is also a fork

Are there plans to merge those forks eventually?

Gitorious is nice, but I think GitHub is cooler. It has many advantages like easy view of forks, pull requests, nice way to look commits and more!

You know, it's "Social Coding" and has a cool mascot called Octodex!