The future of AGS III - The plan

Started by Wyz, Thu 15/03/2012 00:37:51

Previous topic - Next topic

Wyz

For the past two months I've been working on a plan. A plan for the future of AGS. It is by no means a plan what I think the future development of AGS must look like or should look like, no: it is what the future development could look like. I've been reading a lot of discussions and been silently collecting information and opinions; added that with what I would advise if anyone would ask me; and put it all in a document. I also put in insight about some of the subjects that have been debated intensely and try to make them clear also to people that are not really into it.

This document is not just for developers, it is for everyone to read, think about, philosophy about, talk about and have a good laugh at with your pals. I don't care what you do with it really, but I hope it will trigger a positive feeling about AGS' future. A feeling that the we as a community will manage to make this into something great, all differences in opinions aside.

So without further ado:

I've kept this all under the hood while I was working on it so I didn't get distracted. I've been waiting for some people to review it while others already gave me useful feedback. Now it is in the open this does not stop. If you want to review the plan as well, just send me a PM and I will give you access to the document so you can comment on it.

Thanks for your time!
Life is like an adventure without the pixel hunts.

Construed

Very complete and well thought out plan.

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

Snarky

Well, that sounds fine in general, though I wouldn't call it progress as such. I think some of the specifics are going to be whatever they end up being, you can't really say for sure in advance that it's definitely going to happen in this particular order.

The tl;dr version seems to be:

1. There are things that need to be set up on the forums, site and repository side in order to make effective progress.
2. The people/team who are going to manage development going forward need to have the access to set up and maintain that stuff.
3. There needs to be good communication between the leads and developers and the community at large.
4. Step one of actual code development should be consolidating the different branches and refactoring/documenting/standardizing the code. That might take a while.

Yes, absolutely. Agree with all of those.

Minor point: I think you're wrong about the Artistic License. It does not prohibit an unsanctioned modified, commercial version of AGS, as long as it is open source.

bicilotti

Very interesting, sensible and well written. I especially agree on the 'infrastructres' outlined in the doc (dev boards, bug tracker request tracker, etc.).

straydogstrut

A very well thought-out, sensible plan in my humble opinion. This is an overview and there will be lots of nitty gritty details to consider, but I think the future of AGS is in safe hands if an approach like this can be taken.

I don't fall into the developer camp. I'm just one of those pesky community users that expects the world (and 'runs AGS on a separate partition' until the day it gets ported to Mac ;) ) That said, I hope all the community-involvement you've suggested does happen because that's definitely an area i'd want to be involved in: submitting bug reports, voting on features, proof reading the wiki etc. I use other forums for things like web and iOS development and there's big community involvement with documentation, bug reporting, tutorials, plugins etc. I know we have much of that but a cohesive plan for the new site can only be a good thing in my opinion.

Thank you for writing this document Wyz

m0ds

If it's the one you showed me it's a good document, I hope to re-read it again soon. Nice one Wyz for going public wi' it! I'd urge others to have a read, now is a good time to yay or nay it if you have a strong AGS opinion of some kind  ;D

LimpingFish

The future of the forums is an ongoing discussion over in Modland, and something that will hopefully result in action sooner rather than later (much sooner!).

I can't fault the plan for moving AGS development forward, though. It makes a lot of sense. Good work. :)
Steam: LimpingFish
PSN: LFishRoller
XB: TheActualLimpingFish
Spotify: LimpingFish

miguel

Not a Dev myself but so much in love with AGS as anybody else!
Thanks for "The Plan" Wyz, good work.

I hope that we get our shit together and start working on it as soon as possible!

I know this has been said before and there's CJ coming and going when he has time but due to the current state of the forums, posting this is a nightmare as is to even open topics...let's fix the forum first please. I think it's priority number 1.
Working on a RON game!!!!!

timofonic

#8
I did read the document while it's conception (as it has been shared by using Google Docs to some community members and the link showed in the IRC channel) and was critical with it but at same time agreed on it.

As Wyz already know, there are some things that happened while writing the document. Maybe it should need a second edition after some time...

- Alyssa Milburn (aka fuzzie) from the ScummVM Team is working on an AGS engine for ScummVM. It's in WIP state, but she's implementing it alone and trying to understand the mess the AGS runtime is (. There's even some talking about hardware acceleration of the graphics, due to being needed by AGS and Wintermute engines (another candidate, due to the Wintermute Lite runtime having nice code and implmenting only the 2D part).

- CJ already appeared again, he said about publishing the new website soon and the last stuff is going to be done. While I'm sceptical most of the time and prefer to support on facts rather than faith, I would like to believe that Mr. Chris Jones is going to put the new website soon and assign one or two webmasters (and some admins for tasks like updating information of the site).

- AGS Archives is a very important thing in my opinion, A LOT MORE than people may think. the AGS community is full of creativity and motivation by indie and hobbyist devs, but their projects need to have more visibility and some way to reward the best projects by different criteria in an extensive way (best game, best history, best innovative game, best artistic quality...). The site needs to be totally integrated and maintained in an extremely active and detailed way ( I suggested even show the AGS runtime version, for example).

- A core team must be formed, with at least some experienced (two or more) able to make complex decisions about the design and implementation. They can be the mentors of novices into the project, so they can learn and improve their skills. Of course, this is related to the WIP implementation of the AGS engine for ScummVM, so they should be a strong collaboration in this area (because ScummVM can be the multiplatform runtime to play AGS games on lots platforms, improving the popularity of AGS games so both indie/hobby and commercial game makers benefit of it).

- DRM is a no go, it's retarded and is even worse for commercial developers. This has been mentioned in "The Plan" document, but not enough detailed in my opinion. The work to make DRM difficult to crack is quite big, and the same effort on other areas can improve a lot the project. Plus DRM makes multiplatform and data preservation a lot more difficult, and in my opinion AGS games are worthwhile to be preserved so future generations can enjoy and study them.

- Web server must be actively maintained ASAP! I'm a Linux guy so I can be biased to it, but I think Linux is a lot better alternative for a web server rather than by using Windows Server. The forum is hosted in Windows Server and is showing lots of reliability problems. This is making a lot bad to the community, because forums are the primary communication way of it.

- In my opnion, it's not too early to colllect improvement ideas for the future. This should be done in an organized way , started by people that already know the inner workings of AGS (like jjs, fuzzie and other developers but also game makers with technical level).

The community MUST understand one thing: The most important thing is THE CODE, because the tools used by the community need to be improved and maintained constantly. So please think about it and center the main efforts mainly in this. But please don't continue the solo developers syndrome, there must be formed a properly organized development team. I personally think that all other efforts are irrelevant compared to this one, because it's the main force that makes the project stay alive.

Let's motivate the community and specially their developers, so AGS can stop to be jokingly named  Abandoned Game Studio and being a serious alternative for all kind of 2D adventure game developers!

Eric

Quote from: timofonic on Fri 16/03/2012 14:25:39While I'm sceptical most of the time and prefer to support on facts rather than faith, I would like to believe that Mr. Chris Jones is going to put the new website soon and assign one or two webmasters (and some admins for tasks like updating information of the site).

Well, you can see much of the new site in action at http://www.adventuregamestudio.co.uk/Newsite/Home.aspx

So that's something, at least.

RickJ

Wyz, 

"The Plan" is a great start on documenting what needs to be done.  You present sound and sensible ideas in the plan.  I have some comments that may be helpful in refining the plan.

Phase One-Eleven
The document would have been easier to read and digest if there were descriptive titles.  These sections also seemed to need more structure (i.e. categories,k sub-categories, etc).  It seems to me you were thinking in terms of chronology and so a linear structure was chosen.  I can see where a hierarchical structure would tend to de-emphasize the chronology.   Perhaps chronology could be preserved by assigning categories/sub-categories to phases which could be defined something like the following:  Representation of dependencies could be achieved using do notation (i.e. Phase-1.1 comes before  Phase-1.2).

  • Phase-1    0-2 months
  • Phase-2   2-6 months
  • Phase-3  6-12 montsh
  • Phase-4  12+ months


    Phase Three - Engine Coding Team
    I think we agree in principle but perhaps disagree on some of the terminology and/or group dynamic.  As you correctly point out there are developers who can commit nearly full time to the project and those who can commit to specific tasks. For now, they can be referred to as core and casual developers.  Individual developers self-select by the amount of time the can contribute.   I also agree that casual developers are an important resource.  However,  to effectively utilize them requires that suitable tasks are identified and defined.     

    The are also two kinds of development efforts; 1) Deciding what to do and  2) Doing it.  "The Plan" alludes to this fact but then goes on to confuse it with the two kinds of developers.   In my view the following more accurately reflects the situation.
     
    o Architecture (deciding what to do)
       - Lead Developer(s)/Technical Leader/etc
       - Core Developers
       - Casual Developer
    o Implementation (doing it)
       - Core Developers
       - Casual Developers
    


    Everyone can participate in either activity (think forum discussion here).   One could imagine that most of the time a consensus could be reached and natural leaders would emerge from the group.  However, there will be times when consensus is not forthcoming and the "hand of authority" will be required to nudge the group along.  So there will need to be some kind of governance  (i.e. Technical Leader(s), Project manager, etc) in place. 

    Phase Five - Coding Conventions
    Quote
    There needs to be a consensus but for the love of AGS don’t be a dick about it
    Couldn't agree more.  Coding conventions are like assholes. Everybody has one; some people have more than one.   ;D

    The ScummVM team have a nice and well documented standard.  It has been suggested in one of the other threads that this would make a good starting place and I agree.   I would take a good look at CJ's style to see if there is anything that ought to be (or not be) included or modified in the ScummVM standard.

    I would suggest using ScummVM's horizontal and vertical spacing rules.  I've done my share of refactoring and porting other people's code and I can tell you from experience that repetitive tasks such as adjusting indent spacing (or changing tabs to/from spaces) are not a waste of time as one would think.  Believe it or not this exercise is invaluable and helps the person become familiar with the code.   

    Phase Six - Refactoring
    The ScummVM team are way in front of us on this.  It's my  understanding that their architecture consists of front and back ends.  They have a backend for each platform the support.  They  have a front end for each engine they support.    If this is the case it may make a lot of technical sense if AGS and ScummVM were able to use the same front end.  To be sure there are some licensing issues to be addressed but I think the benefits are too great to pass up the opportunity.

    Somebody from here, who has the time, should really really be working with fuzzie and giving her as much help as possible.   The more the AGS community contributes to her efforts  the easier it is to make the case for a common, dual licensed, front end. 

    Monkey, please forgive me for volunteering you for this task ;D, but you are one of the best Deep Divers of code I have ever had the pleasure of working with.   I think you could be an immense help to Fuzzie and that you would gain a great insight into the  workings of both the current AGS engine and of the ScummVM innards.   I hope you would consider taking on this challenge (if you haven't already).   Anyone who is currently working on the engine should be communicating and helping Fuzzie whenever possible.


    Here are some thoughts on a hierarchical organization of "The Plan" or the AGS project itself.  It is just a illustration of some of my earlier comments and by no means a finished or even partially finished product.  Just something to stimulate more discussion.

    Code: ags
    
    Project Organization
      Infrastructure
        Forum
        Website
        Code Repository
      Legal
        License + Clarifications w/regard to games made with AGS
        Contributor registration and agreements
        Copyright assignment
      Administrative
        Groups & Specialties
        Objectives
        Governance
      Standards
        Coding Style
        File naming conventions
        Procedure(s) for development cycle
        Repository policy (i.e merge/commit)
    
    Engine
      Refactor Code
        Deep dive code
          Document what's there
          Document refactor ideas
        Plan
          Architecture/Structure/Overall Vision
          Identify milestones, chronology
          Identify individual tasks
        Execute plan
      Release
        Test
        Merge with Editor Release
      Future
    
    Editor
      Enhance File/Project handling
        Multiple targets
        Multiple game versions 
        Integrate management of game resources/assets
        Retain resource import source, parameters for mass re-import
        BuildAll => Build Target, Build All Targets
      Deepdivers
        Resear4ch porting issues & options
      Release
        Test
        Merge with Editor Release
    
    Compiler (AGS Native)
      Feature freeze until after refactoring
      Deep Divers
        Investigate alternatives (AngleScript etc)
        Learn how to make changes to compiler
        Identify desired and required language features
      Documentation
        Auto-generation (AGS Help File)
        Alternative formats (HTML)
      Future
    

bicilotti

Quote from: timofonic on Fri 16/03/2012 14:25:39
- DRM is a no go, it's retarded and is even worse for commercial developers. This has been mentioned in "The Plan" document, but not enough detailed in my opinion. The work to make DRM difficult to crack is quite big, and the same effort on other areas can improve a lot the project. Plus DRM makes multiplatform and data preservation a lot more difficult, and in my opinion AGS games are worthwhile to be preserved so future generations can enjoy and study them.

"The Plan" addresses the point in a sensible way:

Quote
Encryption of resources

[...] everything the game has access to can also be accessed by someone else. They don’t even need to have the source code, when a motivated cracker starts working on it, it can be broken in a matter of days. The reason why no-one ever did this is because they did not see the value of it. Frankly this is the best solution; if you try to encrypt things really well all you are accomplishing is attracting code crackers.

Still, we don’t want to make it too easy. All we need is a simple encryption algorithm (there are tons of them out there) to obscure the package files a bit so they can’t be read by programmers.

Still anyone with the source code could write a decoder so this might not be enough for some users. I think this can be solved with a separate plugin that can encrypt it in a secret way, with no source code available of it. We don’t have to supply this plugin ourselves, but we should enable plugins to have control over package loading.

to sum it up:
    - encrypting is seldom a wise move
    - still, plain data is not a wise move too: we just need to obfuscate the packages a bit
    - if you are, e.g., a commercial developer and are really worried, that could be solved with a closed source pulug-in, not provided by us.

That would: take very little time to implement (and in the case of the closed source plugin: no time to implement, since it won't be developed by the AGS coders).
Multiplatform/data preservation wouldn't be a problem at all! The encrypt/decrypt routines are there for everyone to use (without even studying them), the encryption/decryption routines would be multiplafrom (hell I don't see any reason for them not to be).

So, to stress it again: minimum effort for a little feature many could appreciate.


Quote from: timofonic on Fri 16/03/2012 14:25:39The community MUST understand one thing: The most important thing is THE CODE, because the tools used by the community need to be improved and maintained constantly. So please think about it and center the main efforts mainly in this. But please don't continue the solo developers syndrome, there must be formed a properly organized development team. I personally think that all other efforts are irrelevant compared to this one, because it's the main force that makes the project stay alive.

Wyz's plan clearly states that the first steps would be 'giving the community' (better: setting up) some tools which would instantly make possible a collaborative effort (a common repository, bugtracking system, feature request system). Way to go!

Quote from: timofonic on Fri 16/03/2012 14:25:39
I would like to believe that Mr. Chris Jones is going to put the new website soon and assign one or two webmasters (and some admins for tasks like updating information of the site).

I would like to see someone trusted to be given the keys to the server (for general mantaineance, dealing with events like forum wide announcement for the awards, etc.) too.

suicidal pencil

The plan is very well written Wyz. I wish I could help with the plan but I'm not too knowledgeable of C++, nor have I ever undertook a project of such magnitude. However, I will pledge what assistance an intermediate Perl coder can bring  ;D 

here's my qualification:
Code: ags
@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{
@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*=2)+=$f=!fork;map{$P=$P[$f^ord
($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[P.]/&&
close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];sleep rand(2)if/\S/;print

:)



straydogstrut

While it would tickle me silly to see stuff happening, I don't think the lack of public updates means nothing is happening. I got the impression that discussions are going on behind the scenes and some things, like a seperate forum for dev discussion, were partly waiting on CJ to set things up. I would presume the right people are still in discussions and I see no reason to rush into things.

timofonic

Quote from: straydogstrut on Thu 05/04/2012 19:15:07
While it would tickle me silly to see stuff happening, I don't think the lack of public updates means nothing is happening. I got the impression that discussions are going on behind the scenes and some things, like a seperate forum for dev discussion, were partly waiting on CJ to set things up. I would presume the right people are still in discussions and I see no reason to rush into things.


That's the BIG problem, WAITING...

Why wait when other people with more time and/or motivation could do it? That's the advantage of a community project, that's why properly organize Free Software projects stay alive.

AGS needs a community culture evolution...

m0ds

In an effort to keep things legit and official waiting is really the only option at this point. Lots of things are on the table, its a matter of cj looking at the options and working with us to bring the best to light. But that doesnt mean I dont agree, only so much waiting can be done before its just pointless to wait any longer.

BigMc

If you have decided on some people who are trusted, why don't you tell them to set up a website and other infrastructure? Has CJ ever announced that he wants to hand over his website to AGS, the free software project? If not, what are you waitig for?  You really need these things to get started.

Andail

As Mods says, we still have to wait some more.
There is a model being worked out, and we more or less only need CJ to greenlight some stuff before changes will take place.

fuzzie

At some point the phases of the plan are going to need a re-think; for example, Nick Sonneveld has made a good start at refactoring the code into sensible commented pieces, so a lot of phase 6 might become irrelevant.

Also note that the ScummVM section is irrelevant now too (my ScummVM AGS engine is largely refactored/rewritten already).

SMF spam blocked by CleanTalk