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-ElevenThe 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 TeamI 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 ConventionsCouldn't agree more. Coding conventions are like assholes. Everybody has one; some people have more than one.
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 - RefactoringThe 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 , 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]
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
[/code]
