I decided to participate in this source code discussion. Unfortunately I haven't read this whole discussion because I came in late and there is a lot to read. So consider this a new start to the discussion if you would like.
Anyway, here are my idea's of where we can go from here:STEP 0: VERY IMPORTANT: Development Forums
We need to have some sort of structure for this whole process, otherwise things will get messy and we will be going nowhere with AGS. We already see several repositories for AGS on gitorious besides the official SVN and we have seen several users contribute their own versions of the Editor. This could make things confusing and one version that we like can exclude a feature we want from another build. Lets stop this now. The first thing we need is a restructuring of the Using AGS forums and the addition of the Development forum, followed by an official development team with a team leader.
How would I restructure the forums? Well for "Using AGS", I would strictly make the Technical forum an advanced user forum for feature suggestions and for how to perform advanced operations in AGS. I would then rename it to "General AGS Discussion". Remove the beginners forum. I would then add a "FAQ and Tutorials and Beginners" forum in "Using AGS" and move those topics from the plugins forum to the FAQ forum.
I would rename the "AGS Games" category to "AGS WIPS and Releases" and move the "Templates, modules and plugins" to that category.
At this point I would then add a development forum which would consist of the following:
A. - "Development Discussion" - used to discuss libraries to use, what code to add/edit/remove and other things all related to development. Public Forum.
B. - "AGS Source Code" - A place for the official team to release daily builds of AGS alpha and Beta editions and also updated archived source code. Public Forum.
C. - "Bug Fixes and issues" - a place to post all errors, bugs and things needing to be fixed. Public Forum.
D. - "Private Development Forum" - A place for the official development team to discuss how to code AGS and what official approaches to take next. Private Forum.STEP 1: Which of the many distributions to use
There is the official SVN version but then there is the gitorious builds. Personally, JJS has developed the best build of the AGS engine and suggest using his repository. His repository works well with many OS's and his latest build is meant to build for Windows, Linux, PSP and Android from the get go. It has the essential feature that all AGSers would like: Portability.STEP 2: Source Clean up
We should take JJS' repository and begin the clean up work on the source. Perhaps splitting up ac.cpp and other similar files as well as improving code execution and performance. Commenting should also be added efficiently. One other thing to do is probably also use update versions of the libraries that AGS uses such as Allegro.STEP 3: Documenting
For better control from this point on, the source code and normal conventions should be documented so that the community can expand on the development properly. This should be done at all times.STEP 4: Testing
After cleaning the source code, it would be good to test the new engine rewrite with several games on all the OS' supported. Once thats done, we can fix the bugs and move on to the next phase of development.STEP 5: Improving the basic framework of the engine
I know portability is a priority for many, but honestly, improving portability performance and limit issues, we need to work on the basic framework of the engine. Once thats settled, we can then begin to move on to different things. How would I improve the framework? Like so:
1. - I would begin adding support for several resolutions, in particular all those that would encourage commercial development and those needed on portable systems such Android, Windows Phone, Palm Pre, IOS, etc...
2. - Limitations. One of the many things that you hear complaints of are the limitations on rooms, objects, etc... Do all these limitations need to be removed or edited, possibly not. What limitations to take care of will depend on the community.
3. - GUI's and text parser would be next since thats main functionality of the engine.
4. - The scripting engine is something else that the community may want to edit.
5. - 64-bit inclusion.
6. - Graphical engine.
7. - File resources - how are sprites split up, etc...
8. - Misc items such as using different libraries and such.
9. - Improving the way Plugins are handled so that plugins can easily be developed for all platforms.
10. - Integration of 3D file formats, and other file formats as well as acceleration for future development. Even if 3D is not a feature to add for a while, lets atleast get the framework in there because I am certain it will come.STEP 6: Bug checks
Needed before we move on to the next step.STEP 7: Performance enhancements
With all the changes, performance can lag. Perhaps at this point it would be wise to look into improving performance.STEP 8: Improving current portability
Lets face it, the current ports could always use some working on. If we port the engine to another OS before we make the current ports stable, something will eventually break. We want to make it as simple as possible to be able to take this source code and allow compilation for any of its ports with few issues.STEP 9: Creating a very stable and current Mac Port
At this point libraries would need to be researched that would perform well with what is currently in AGS. I would suggest having the engine function from MacOS 10.2 and up would be ideal enough of a port.STEP 10: Windows
No doubt several distributions of Windows can play adventure games, even advanced ones. However, for some reason, Windows does not play nice with itself. Meaning, something that would work for Windows XP will stop working for Windows 7. We need to stabilize AGS so that it can work for Atleast Windows 2000, Windows XP, Windows Vista, Windows 7 and the upcoming Windows 8.STEP 11: Linux Distribution
With the various distributions of Linux, we need to either make the port universal or develop several other ports for it.STEP 12: Bug Testing
Once again, lets make sure that nothing is broken and that the new Mac port is still functional.STEP 13: Porting to handhelds
At this point we can begin porting to the major platforms for handhelds and phones. For instance, we already have PSP and Android. Next would need to be iOS, Windows Phone 7, Blackberry, Palm Pre WebOS, Windows Mobile, PSP Go and Nintendo DS/3DS. You might ask, is it really necessary to port to these? No. But eventually we will want to. Lets keep this in step. OpenGL ES and Phonegap would work best to port to these various other systems with minimal code change. STEP 13b: Other ports?
At this point, I really do not feel that AGS needs to be ported to any other system than the ones above. However, some might disagree with me. Again, I strongly discourage Step 13b, but if we cant get past it, we need to consider it I guess. Some might want to port to the Nintendo Wii, Playstation 3 and X-Box. If that is necessary, I suggest the following:
A. - We can make it so that games are playable for the Nintendo Gamecube so that it can be played also on the Wii, or we can just make it for the Wii and have it also be supported for the next system that is released.
B. - Create a Playstation one version of the game engine so that it can be playable on all three systems: PS1, 2 and 3.
C. - Create a version for X-Box 360 or for the original X-Box so that it can be playable on both systems.
D. - Scrap all those options above and create a DOS version of the engine so that those systems can play adventure games on DosBox.
E. - All of the above.STEP 14: Bug Testing again
Yes, its getting annoying, but it has to be done. Trust me. You will thank me later.STEP 15: Error Logging feature
Looking for bugs in the future can be simplified if there can be implemented an error logging feature into the engine for every time it crashes.STEP 16: AGS Run Game option
I like this feature and it should stay. Perhaps we can compile older versions of AGS, such as 2.5, 2.6, 2.72 and 3.0 and up so that we can run mini-games or internal-games within the updated version of AGS. STEP 17: Seperation of Compiler and Editor
This has been long awaited for by many if not all AGS members. Basically, many have wanted to have the whole studio seperated into three components: Editor, Compiler and Engine. So at this point, we can start making improvements to the compiler so that it can be more efficient to use.
A. - The compiler should be able to compile all project files written in text, including room settings and such. It can also compile sprites and other files for our needs. This would basically work similarly to how AGAST and MAD use to work. An editor would write the project out to seperate text files and then the compiler would compile it. This would allow the building of custom editors, interaction editors and portability of the editor.
B. - Make the compiler cross platform to support Mac/Windows/Linux and then the IPad, Android Honeycomb or later, Blackberry Playbook and HP Touchpad.
C. - Create a feature in the compiler that can compile the source code to byte code and that can make the AGS sources unable to be decompiled.
D. - The ability to cross-compile.STEP 18: Bug Testing
You heard me.STEP 19: A revised editor
At this point we should consider what future possibilities AGS could have implemented and how the editor should reflect that, such as having 3D characters and objects and how one would edit that in the editor, Better Syntax Highlighting, a Team integration system so that users can work on a project together remotely and other things just to mention a few. However, I think the editor should also better reflect the state and portability of the current Engine. I think it should also be more modernized offering translations, panels and even a way to test the way objects and characters look in a game. And one thing that is also popular in many of today's suites: Theming. I certainly think that the AGS Editor should be Themable.
I also think that the AGS editor should be ported to other OS' as has been requested and asked for for many years now. So perhaps libraries that can be used such as JUCE and QT 4.5 or even WX Widgets should be considered. I would consider a port of the editor to the same ports of the compiler.
Two final things (Yes, I know now that some of these are suggestions) I would like to see return is the animation editor and also the interaction editor for us newbies to the C++/C# programming language.STEP 20: Backwards compatibility
I have heard the mention of this and to be honest, I am all for this. I hated the fact that for my Simpsons Template, I had to convert it up for every version of AGS to get it to work with the latest. EG: from 2.6 to 2.72 to 3.0. I think its good to be able to have a feature which can upgrade any source version to the latest version of AGS. Lets face it, AGS will evolve constantly and eventually AGS 3.2 will not work with AGS 3.6. So to change that, we could use a system which can convert any older source to the new source. Visual Basic .net sort of used this, so why not us as well? Or another way to handle backwards compatibility is by using source scripts file extensions. For instance, a room file called room1.rm will work for AGS 4.0, however a room file that can be called room1.rm25, room1.rm26, room1.rm272 or room1.rm30 will allow for the developer to develop games using AGS 2.5, 2.6, 2.72 and 3.0 respectively.STEP 21: Bug Testing
Yep, its important.STEP 22: Feature additions
Now with the important stuff done and the groundwork of the future of AGS established, we can begin adding new features to it. An area I would like to see added in would be the addition of features that were done in plugins such as particles, paralax scrolling, TCPIP, etc... Then we can move on to other new features such as 3D characters and objects. Each feature should be worked on one at a time. and tested until it is working perfectly and portably. Then it should be documented in the AGS Manual along with a sample code inclusion. After that, we move on to the next feature.STEP 23: Bug Test
Last one, I promise.STEP 24: Demo Game
Update the Demo game to work with this version of AGS and make sure it works across all platforms. The demo game will be updated along with each new version of AGS to demonstrate the new features developed.STEP 25: Website
Revamp it a bit to reflect the new AGS.STEP 26: Release AGS 4.0
And the rest is history as the development team continues to improve on it and add new features and ports.
I hope this was a good write up, it only took me 3 hours to do.