So here is what we should do... Again

Started by Joseph DiPerla, Sat 23/06/2012 16:59:44

Previous topic - Next topic

Joseph DiPerla

With so many recent idea's on how AGS should move forward and seeing some debates as to what to replace as part of AGS' core, I think this still merrits discussion. Now I know we have many threads about this already, but this is to be a fresh approach to the discussion. We are going in circles and this discussion is meant to say: "ENOUGH. Lets get going and moving forward with this the way Chris wanted it to." No more idea's, no more planning who is going to do what. This discussion is meant to end that.

AGS has come along way since its been open sourced. I give a lot of credit to CJ for doing this. However, I think that the community is getting lost and might even be thinking too big in terms of changes to continue making. People also just have their own idea's as to what they want to see, so everyone has been just going and doing there own thing. While, some progress has been made, its not enough and its not collaborated with each other.

I think sometimes we forget that AGS can do a lot more than many of the adventure game engines we have seen throughout history such as SCUMM, SCI, AGI, AGAST, MAD, Sludge, Glumol, etc... AGS is powerful. AGS is not meant to really be competition for other engines, but rather a tool of personal choice. AGS' goal is not to be a programming language, it is meant to be an Adventure game engine that allows us to easily, quickly and efficiently create adventure games. Though we can add other elements such as action or 3d shootem ups (With a lot of work) or create applications such as calculators, etc... AGS is meant to primarily, and in all fairness, only be a 2D adventure game engine. I feel that part of the reason with Chris taking so long to make AGS open source is that we would forget these things. Does it mean we cant expand on its functionality? No. Does it mean AGS should be strictly used for 2D Adventure games? Does it mean we cant add other gaming aspects within our game? No. But, some are considering altering everything thats at the core of AGS. If you look at many threads, some want AGS to use an embedded scripting language rather than the built in AGS Script which Chris spent years improving and developing. Its something unique to AGS. Others would want to take out the pure foundation of AGS, which is Allegro, and swap it out with SDL. Some even would prefer that AGS not be a community project, but a SCUMMVM project. Did we not notice over the past 13 years that Chris has not done any of those things? Its probably for a reason.

So then, my question is, why completely alter AGS' core? Why change what its supposed to be? Why dismantle Chris' baby? I feel as if this is a slap in the face to Chris, as if we are saying:"You made all the wrong decisions with AGS, so now we are going to replace its brain, heart and lungs and fix its guts." If there are those who want to recreate something, just go ahead and create a new game engine. Thats the way I look at it anyway. Also, I know Chris had mentioned the time factor for releasing AGS open source. Meaning, he wants development to proceed more quickly than it had been recently. If we replace the brain, the heart, the lungs and guts of AGS, wouldn't that slow development down? Couldn't it break so much within the engine itself? That in itself would have us looking for bugs that would not be there if we left things alone. Lets remember, AGS is not a shell. It is what it is: AGS.

Now, while AGS should always remain open source and the community should always be able to see the changes going on every day with AGS such as on Gitorious or Github, what AGS really needs is a dedicated team that will work, wait for it.... TOGETHER. With one purpose and one thought. So, in this discussion, I am going to propose something, and I hope this becomes the official way of doing so.

So for starters, I know some have already done this, but as I said, we need a team that is dedicated to the development of AGS. Some are working together, but now its time to add to the team. My proposed AGS Dream team would be this:

Chris Jones (Project creator/ AGS GOD)
Steve Mcrea/ Kweepa (Project porting)
EvilTypeGuy, if he is around (Porting)
Electroshokker (Porting)
JJS (Project Organzier, Refactoring, Engine core implementation, Porting, Daily Builds, Engine Coding Team Leader, Bug fixes, Idea Team)
Tobihan (Project Organizer, Refactoring, Engine Core implementation, porting, daily builds, Bug Fixes)
Alan V Drake (Project Organizer, Engine Core Implementation, IDE Core implementation, IDE Coding Team Leader, Idea Team)
Calin Leafshade (Project Organzier, Engine Core Implementation, IDE Core Implementation, Bug Fixes, Idea Team)
Crimson Wizard (Project Organizer, Porting, Bug Fixes, Engine Core Implementation Team, Idea Team)
Monkey_05_06 (Project Organzier, Bug Fixes, Engine Core Implementation Team, IDE Core Implementation Team, Idea Team)
Tzach Shabtay (IDE Implementation Team)
ProgzMax (Project Organizer, IDE Implementation Team)
Steven Poulton (IDE Implementation Team)
Nefasto (IDE Implementation Team)
Denzil Quixode (Idea Team, Feature Implementation Team, IDE Core Implementation Team, Engine Core Implementation Team)

Wyz (Feature Implementation Team, Idea Team)
SpeechCenter (Feature Implementation Team, Idea Team, IDE Core Implementation)
Strazer (Feature Implementation Team, Idea Team)
AJA (Feature Implementation Team, Idea Team)
DKH (Feature Implementation Team, Idea Team)
Besh (Feature Implementation Team, Idea Team)
Endmundito (Feature Implementation Team, Idea Team)
Dualnames (Feature Implementation Team, Module Team, Demo Game Team, Idea Team)
Iceman (Feature Implementation Team, Module Team, Idea Team)
Wretched (Feature Implementation Team, Idea Team)
Ali (Feature Implementation Team, Idea Team)
Khris (Feature Implementation, Module Team, Idea Team)

AGA (Project Organizer, Bugs Tracking, Graphics implementation, Implementation Idea Team, Forum Administrator, Dev Team Rules enforcer)
MODS (Project Organizer, Bug Tracking, Implementation Idea team, Forum Moderator, Dev Team Rules enforcer)
abstauber (Template Designer Leader, Help File writer, Idea Team, Dev Team Rules enforcer)
RickJ (Demo Game Leader, Template designer, Help File Writer, Idea Team, Tutorials, Dev Team Rules enforcer)
Darth Mandarb (Project Organizer, Bugs Tracking, Forum Moderator, Idea TeamDev Team Rules enforcer)
Joseph DiPerla (Project Organizer, Bugs Tracking, Implementation Idea Team, Help File Writer, Dev Team Rules enforcer)
Snarky (Project Organizer, Bug Tracking, Implementation Idea Team, Dev Team Rules Enforcer)

"There is wisdom in the multitude of counselors". - Therefore, there will be no one team leader. Just idea's, polls and enforcers. We will all be equal. The only person who trumps any decision or code is CJ.

------------------------------------------------------------------------------

Now, with an ideal team (The dream team, as some would say) set in place, I think I need to mention a few things so that this does not look overwhelming and disorganized. First off, I think the development team will need a private forum to discuss various things together. If an entire community gets involved, then things get messy, arguments will follow and things will never get done. We have a development forum, but the official development team needs to have somewhere private to talk about the important organized stuff that has to go on.

So, now though, lets talk about the various rules, roles, Stages, etc...  that need to take place for this to happen in an organized way:

Private Development Team Forum Structure (Note, coders and project organizers have access to all forums. The Dev Team Enforcers have moderator status for the Suggestions and idea implementation forums. Members allowed access to the other forums are also moderators for that particular forum.):

General Forum - For everyone on the team.
Suggestions - a place for us to offer suggestions
Code Review - a place for just the coders to review source code and discuss the best approach to implement something or fix a bug.
Idea Implementation - a place for the idea team, module team, graphic implementation team, Dev Team enforcers, Demo game Team to talk.
Bug Trackers - a Place for the bug tracking team and bug fixers to organize when bugs are fixed and for what editions they were fixed for.
Porting - a place for the porters to discuss porting options and to discuss the best approach to take.
Engine Core Implementation - for only those team members.
IDE Core Implementation - for only those team members.
Help File writers - a place for the help file team to write the, well, helpfile.
Project Organization - for those that are on the project organization team. Here they will discuss when a new release should be announced to the community and also discuss how the progress is going.
Monthly check in - For everyone to post what they have done for the month. Reports will be compiled once a month. One of the Dev Team Enforcers will initiate the thread each month.

Roles:
AGS GOD - Self Explanatory.
Porting - Those whose responsibilities will include the proper way to port the engine or IDE to other OS's and make sure nothing is broken and that all works well.
Project Organizers - will ensure that that everything is done in an organized way as well as determine the release of the new versions of AGS. They also keep track of everything thats going on.
Bug tracking team - They will track bugs and features that the community reports.
Dev Team Enforcers - They will ensure that everyone is following the guidelines written in this discussion.
Implementation Idea Team- They come up with what AGS needs next.
Engine Core Implementation Team and IDE Core Team - Each will focus on implementing features and bug fixes for either the IDE or the Engine itself.

The other stuff is self explanatory and any team leader can lead the team in however they want as well as request new members.


Rules to follow:
1. Code will be done via Github.
2. Code Documentation - No code is to be added to the engine or IDE without writing detailed documentation of the steps that you took to implement the code and such.
3. No code is to be officially implemented until the coding team can look over the code, assess the situation, see if there is a refinement they need to add to it and then implement it and merge it with the official source code. So for that, maybe we would need a muck up code project on Github and an official one as well.
4. Bug Tracking - The bug tracking team will listen for bugs on the forum and post it in the bug tracker, as well as feature requests. Once in the bug tracker, any DEVELOPER can then choose to handle the bug or feature request and assign themselves to it in the bug tracker. Once thats done, under the bug/feature thread, they are to post updates as to what they are doing to handle the situation so that the team can make sure that action is being taken. Once done, they will mark it off on the bug tracker as being completed. Then they will alert the Project Organizers, Bug tracking team and Idea Implementation team that it has been taken care of.
5. If someone would like to propose an idea, the idea would be discussed for 2 weeks with the entire team. Once everyone has made their case, the individual who came up with the idea can ask to keep his case open for discussion for one more week, or a poll is created to see if the rest of the development team would like to proceed with the implementation. Anyone can propose anything. However, once a decision has been made, action will be taken. If the idea was approved, it goes into the bug tracker. If it has been rejected, it will go into a rejected idea's thread in which the idea can not be brought up for discussion again for a minimum of six months. If an idea will be rejected three times, the idea will go into a forbidden idea thread in which it can never be brought up again.
6. It is the job of any member of the development team to offer a suggestion to be implemented. However, to discourage clutter, each team member will only be allowed to suggest one thing for the engine core and one thing for the ide every two months. Although, the Implementation Idea team members can suggest up to two idea's for each per month. It is their job after all.
7. This is a free, volunteer project. No team member is forced to work on anything if they cannot. However, if you feel that you would not be able to commit to the team in anyway for 6 months or more, it would be wise to step down as a member until you can.

Development rules to follow:
1. No swapping out of Allegro for anything else, such as SDL. However, other graphics engines can be used to supplement Allegro for whatever reason. We want the core of AGS to remain the core of AGS.
2. AGS Script will remain the default scripting language for AGS and will continue to be developed on. However, if you want to add another scripting language, it should be as an alternative in the sense of how Extern C works in C++ or in the fact that one can add a module or script that can be used within AGS. However, AGS Script will still remain the primary Scripting language for AGS.
3. If a member of the Engine Core Team Implements a feature that requires an adjustment to the IDE, they must post that adjustment within the bug tracker for an IDE developer to take on. Until someone takes it on and implements it into the IDE, that feature can exist within AGS, however, it will not be mentioned within the release of any version of AGS until it is supported within the IDE as well.
4. When a new feature is implemented, the person who wrote the function must explain it to the Help file writer team and the project organizers so that they can put it in the help file. After that, the Demo Game Team will find a way to implement the new feature, if it applies, within the game so that the community will be able to see how they can use it and also see a demonstration of it working.
5. No working with the SCUMM Team, atleast not for now. AGS is AGS, not AGS SCUMM. Perhaps way in the future, this can be considered.

Release Rules to follow:
1. The project Organizers will determine when the next version of AGS is to be released, depending on if they feel that the bugfixes and features implemented warrants a new current release.
2. Once they determine that, a brief internal testing period will go on in which the team will test the demo game/ IDE to see if anything is broken.
3. If all looks good, the team releases a Alpha version to the public.
4. If the public finds any bugs, the development team is to stop implementing any new features and work on destroying those bugs once and for all.
5. Once thats done, a Beta version is released. If all looks good, move on to the next step. If not, repeat steps 4 and 5.
6. If its all good, release the official version.


When to accept new members to the team:
There really are no guidelines for this, however, the community and the development team must be able to trust you and you must prove yourself worthy. Perhaps a person who wants to join the idea team would need to either be a long time member of the forums, or a person who has shown that they can create a game. A developer would need to prove themselves by perhaps creating modules, tutorials or plugins, etc... Really, there are no set strategies to determine who joins the team or not. The only real stipulation, so to not over crowd the team, would be that the only time we accept new members to the team is when one team member steps down for whatever reason. A new member acceptance would need to then be accepted via a vote from the team members which will go on for one week.

Priorities for the time being:
Stage 1: Code Refactoring.
Lets let the refactoring team take care of this first. Without doing anything else, let them optimize the code sources and structure and what not. Once this is done, we can begin the next stage:

Stage 2: Documenting the engine source code. This will pretty much be an ongoing thing past the other stages.

Stage 3: Fixing the current ports that exist.
Rather than begin porting to a new OS, the team will focus on making sure that the current ports are functioning and doing what they should to work on their respective OS. Once thats done, it really paves the way for any new port that will be considered.

Stage 4: Modernizing the engine a bit:
Just so AGS can keep up with other modern 2D adventure game engines: A) Remove Limits  B) Allow more resolutions and custom resolutions. C) A compilation option for IPhone and Android   D) Proper Paralax Scrolling   E) A more fully integrated particle effects engine  F) 2.5D Capabilities G) Advanced FMV.

Stage 5: Discuss Goals for AGS.

Stage 6: Proceed with further development.

------------------------------------------------

I know this is a long read and I know this has been discussed to a frustrating degree. But I put a lot of work into this, I didn't just want it lost within other threads. Plus, I think someone really needed to take pointed and affirmative action to unite the developers and to also find a way to properly continue to develop AGS. I hope noone is offended, but if you really think this is a great idea, perhaps we need to start working on doing this now.
Joseph DiPerla--- http://www.adventurestockpile.com
Play my Star Wars MMORPG: http://sw-bfs.com
See my Fiverr page for translation and other services: https://www.fiverr.com/josephdiperla
Google Plus Adventure Community: https://plus.google.com/communities/116504865864458899575

timofonic

#1
I agree about AGS community should start coding ASAP and form a proper team, merging efforts and organizing tasks. But your proposals are a bit monolithic, as you don't count on the personal motivations on this project runned by unpaid volunteer people. AGS is nor a Foundation or a Corporation, but a loosely community driven project (in the sense of not clear direction or strong management on it) with deep origins on a lone programmer that did a quite big effort.

To make the infraestructure, the team needs to be formed in a progressively organical way first. If a Foundation were done, things would get easier and ask for donations and some commercial activities (a cheap licensing for propietary usage, advanced support and paying to have special features done quickly and having a limited exclusivity to them, teaching development of adventure games, etc.) to get funds and paying the most skilled developers to work FULLTIME on the project.

Why that obsesion about Allegro? What's so special and cool about it? Are you a programmer? If yes, what are your facts about it? Despite SDL having some issues too (and still not usable on certain platforms) it's actively more developed and available on lots more platforms than Allegro. OpenGL is another good candidate for certain platforms, too.

You did put JJS as "code refactoring", but his goals are more related to portability. Instead, Crimson Wizard is doing a GREAT refactoring work and he's not listed as "code refactoring".

I agree about not being in SCUMM Team, because that Team focuses on the SCUMM engine only.

I'm not sure if you are using the correct terminology or got some concepts right, really. What's your background in this? Are you making a poll or wants others to totally accept your words because are blessed by God?

God? God is dead, as Nietzsche said ;)

Crimson Wizard

Quote from: Joseph DiPerla on Sat 23/06/2012 16:59:44
I know this is a long read and I know this has been discussed to a frustrating degree
Hah! Basing on my own experience, frustration generally comes from seeing everybody speaking of plans, but having no idea on what conclusion those discussions resulted in neither who is actually working on bringing the plan to life. It is especially tough for newcomers or those who did not track everything from start (e.g. http://www.adventuregamestudio.co.uk/yabb/index.php?topic=46270.0)

Quote from: Joseph DiPerla on Sat 23/06/2012 16:59:44
No more idea's, no more planning who is going to do what.
Now, that's a decision! :D It's a bit funny, I am getting this lesson for the second or third time in last year or so: if you see that everyone is hesitating - do it yourself. Even if you fail, others will see your example and give a hand.

But - closer to the topic.

Di Perla, you've actually raised a very important question. I may be not an ideal programmer ;), but I have an experience in software development, and I've "seen things", as some use to say; I've seen projects being screwed up because people who wrote and maintained it forgot what they are doing and what the program is supposed to be.

It is impossible to make a successful project without explicitly defined idea and concept.
It is possible, but actually not recommended to make a project without an accurate design document, which would state what we are doing, why we are doing this, and what our program supposed to do.
And last, but not least, people should understand that no program can and should be universal. There's always a temptation to add this brand new feature and that additional functionality, and to extend the program core god knows where; I know this feeling too! but one should learn to restrain himself.

There are other guys who are making a game engine with other properties, based on other technology (newer, advanced, name it)? Good for them! Haven't AGS had its own niche in game-making?
AGS is a tool, and as a tool it should be aimed for certain work, result and user.


Regarding "Development rules".
1. I believe there is a way to hide Allegro behind a thin wrapper, like an base interface for example. I am not suggesting to switch Allegro for anything else, but that will give an opportunity to do so in uncertain future, if one would like to do so badly.
3. I actually do like your idea to separate Engine and IDE teams. There are people who know C++ more, and those who know C# more. Plus, implementing runtime functionality and making a proper user interface are much different tasks and not everyone is able to do both on high level.

A side-note: I am happy you placed me in your list :) but I am no "Porting-guy". Unfortunately in my work as a programmer I mainly focused Windows; I did wrote couple of apps for Linux, but I used Qt library, which hid most of platform specifics.

Quote from: timofonic
Are you a programmer?
Are you?
Sorry, but I wanted to ask this for too long :)

Quote from: timofonic
What's your background in this? Are you making a poll or wants others to totally accept your words because are blessed by God
From what I know, he is a long time member of the community. And mind you, people here do not accept anyone's words easily.

monkey0506

Quote from: Joseph DiPerla on Sat 23/06/2012 16:59:44Others would want to take out the pure foundation of AGS, which is Allegro, and swap it out with SDL....Did we not notice over the past 13 years that Chris has not done any of those things? Its probably for a reason.

One of the biggest reasons why CJ probably never seriously considered swapping out Allegro for SDL isn't because Allegro is the "pure foundation of AGS", but rather because it's so deeply embedded into the source code. SDL does have better support for other platforms where Allegro is still playing catch-up, so I think it could be beneficial to do this swap. As a matter of fact, I think the general consensus is that we shouldn't tie ourselves to any graphics/hardware library in particular, but should abstract that out away from the engine core, and then we could allow various back ends to be implemented as needed/wanted.

Quote from: Joseph DiPerla on Sat 23/06/2012 16:59:44My proposed AGS Dream team would be this:

Chris Jones (Project creator/ AGS GOD)
Steve Mcrea/ Kweepa (Project porting)
EvilTypeGuy, if he is around (Porting)
Electroshokker (Porting)
JJS (Project Organzier, Refactoring, Engine core implementation, Porting, Daily Builds, Engine Coding Team Leader, Bug fixes, Idea Team)
Tobihan (Project Organizer, Refactoring, Engine Core implementation, porting, daily builds, Bug Fixes)
Alan V Drake (Project Organizer, Engine Core Implementation, IDE Core implementation, IDE Coding Team Leader, Idea Team)
Calin Leafshade (Project Organzier, Engine Core Implementation, IDE Core Implementation, Bug Fixes, Idea Team)
Crimson Wizard (Project Organizer, Porting, Bug Fixes, Engine Core Implementation Team, Idea Team)
monkey_05_06 (Project Organzier, Bug Fixes, Engine Core Implementation Team, IDE Core Implementation Team, Idea Team)
Tzach Shabtay (IDE Implementation Team)
ProgzMax (Project Organizer, IDE Implementation Team)
Steven Poulton (IDE Implementation Team)

Wait, what the hell? Why does Calin Leafshade make your list twice but I'm only on there once? >:( Also, I see you have other people listed here under "Module Team", but I'm not one. I guess the fact that I've written more modules than anybody else (except possibly SSH, haven't counted recently :P) doesn't qualify me for the module team? Well, fine! I see how you're gonna be about this! (roll)

Quote from: Joseph DiPerla on Sat 23/06/2012 16:59:44"There is wisdom in the multitude of counselors". - Therefore, there will be no one team leader. Just idea's, polls and enforcers. We will all be equal. The only person who trumps any decision or code is CJ.

I think this is a good idea. In the case of any major discrepancy, I think we should follow popular rule. After all, AGS was made by the Onion Ring God, for the people. ;)

Quote from: Joseph DiPerla on Sat 23/06/2012 16:59:44Now, with an ideal team (The dream team, as some would say) set in place, I think I need to mention a few things so that this does not look overwhelming and disorganized. First off, I think the development team will need a private forum to discuss various things together. If an entire community gets involved, then things get messy, arguments will follow and things will never get done. We have a development forum, but the official development team needs to have somewhere private to talk about the important organized stuff that has to go on.

I don't think we have anything to...wait for it...

Spoiler
...hide.
[close]

Feedback from the community should be taken into consideration to help things. If we're taking things in a way that people feel goes "against AGS", then they should have the right to be heard.

Quote from: Joseph DiPerla on Sat 23/06/2012 16:59:44Rules to follow:
1. Code will be done via Github.

This is a silly rule. Just because that's where JJS' repo is presently located doesn't mean we should tie ourselves down to any long standing binds or ties to any particular versioning system/site.

Quote from: Joseph DiPerla on Sat 23/06/2012 16:59:442. Code Documentation - No code is to be added to the engine or IDE without writing detailed documentation of the steps that you took to implement the code and such.
3. No code is to be officially implemented until the coding team can look over the code, assess the situation, see if there is a refinement they need to add to it and then implement it and merge it with the official source code. So for that, maybe we would need a muck up code project on Github and an official one as well.

This seems almost reasonable. Not every change will require "detailed documentation" though. Also, I'm pretty sure checking code in is how it's reviewed. If it gets booted or additional changes are required, the repo can be reverted to a prior revision.

Quote from: Joseph DiPerla on Sat 23/06/2012 16:59:444. Bug Tracking - The bug tracking team will listen for bugs on the forum and post it in the bug tracker, as well as feature requests. Once in the bug tracker, any DEVELOPER can then choose to handle the bug or feature request and assign themselves to it in the bug tracker. Once thats done, under the bug/feature thread, they are to post updates as to what they are doing to handle the situation so that the team can make sure that action is being taken. Once done, they will mark it off on the bug tracker as being completed. Then they will alert the Project Organizers, Bug tracking team and Idea Implementation team that it has been taken care of.

Yes, but they should also alert others that, "Hey, I'm working on fixing this..." and then keep them updated. If they don't get it taken care of, anyone else should feel free to come in behind them and get it done.

Quote from: Joseph DiPerla on Sat 23/06/2012 16:59:445. If someone would like to propose an idea, the idea would be discussed for 2 weeks with the entire team. Once everyone has made their case, the individual who came up with the idea can ask to keep his case open for discussion for one more week, or a poll is created to see if the rest of the development team would like to proceed with the implementation. Anyone can propose anything. However, once a decision has been made, action will be taken. If the idea was approved, it goes into the bug tracker. If it has been rejected, it will go into a rejected idea's thread in which the idea can not be brought up for discussion again for a minimum of six months. If an idea will be rejected three times, the idea will go into a forbidden idea thread in which it can never be brought up again.

Um, no. We shouldn't require threads to stay open for an artificially mandated period of time. Once a significant trend has manifested on a particular issue, we should be willing to follow that (whether it takes 2 weeks, 5 weeks, or 3 days). Ideas that aren't acted upon now shouldn't be thrown out forever though. That is beyond just closed-minded. We shouldn't be constantly spamming the same ideas, but if the paradigm of where AGS is at today has shifted from where it was at when the idea was first suggested, we should always be willing to give it fair review.

Quote from: Joseph DiPerla on Sat 23/06/2012 16:59:446. It is the job of any member of the development team to offer a suggestion to be implemented. However, to discourage clutter, each team member will only be allowed to suggest one thing for the engine core and one thing for the ide every two months. Although, the Implementation Idea team members can suggest up to two idea's for each per month. It is their job after all.

This, is absurd. "to discourage clutter" is the reason why we need the bug/feature tracker, which AGA is currently working ('round the clock I'm told) to get up and running. Anyone should be able to offer suggestions at any time. We should not be artificially impeding growth just because we don't want the forums to have too many threads going at once.

Quote from: Joseph DiPerla on Sat 23/06/2012 16:59:447. This is a free, volunteer project. No team member is forced to work on anything if they cannot. However, if you feel that you would not be able to commit to the team in anyway for 6 months or more, it would be wise to step down as a member until you can.

Again, this is something that...I feel anyone should be able to step up and implement anything at any time, as long as it is reviewed and determined to be good. If you're not fulfilling a particular role, someone else should have the right to step in and take it from you, in part or in whole. If you're that worried about stepping on someone's toes, or having yours stepped on, then maybe you should go write your own game engine. The beauty of a community like this is that we do have sufficient activity and membership that we have amazing skill and talent readily at hand, and willing to offer their time and services. It doesn't always mean that any given person will always be the sole party responsible for that particular role, but insofar as they are able to continue fulfilling it, they should be allowed to do so. There shouldn't be a required process by which to "step down", so much as just a fair warning if you're not going to be able to contribute as much as you have been (as a courtesy rather than a mandate).

Quote from: Joseph DiPerla on Sat 23/06/2012 16:59:44Development rules to follow:
1. No swapping out of Allegro for anything else, such as SDL. However, other graphics engines can be used to supplement Allegro for whatever reason. We want the core of AGS to remain the core of AGS.

No.

Quote from: Joseph DiPerla on Sat 23/06/2012 16:59:442. AGS Script will remain the default scripting language for AGS and will continue to be developed on. However, if you want to add another scripting language, it should be as an alternative in the sense of how Extern C works in C++ or in the fact that one can add a module or script that can be used within AGS. However, AGS Script will still remain the primary Scripting language for AGS.

I agree with this simply because I feel that it is extensible enough that we can make it fit our own needs without having any wide-spread negative impact. As I said in the other thread, swapping out the graphic/hardware back-end doesn't change the way people are going to be using the program. Changing the scripting language does.

Quote from: Joseph DiPerla on Sat 23/06/2012 16:59:443. If a member of the Engine Core Team Implements a feature that requires an adjustment to the IDE, they must post that adjustment within the bug tracker for an IDE developer to take on. Until someone takes it on and implements it into the IDE, that feature can exist within AGS, however, it will not be mentioned within the release of any version of AGS until it is supported within the IDE as well.

Again, we shouldn't artificially withhold this type of information. If the engine has a certain capability, we should be able to clearly and directly state that the engine has the capability. If the editor doesn't have a way to take advantage of it, then that should also be noted, but again, this just seems like artificially impeding growth for the sake of some bureaucratic political correctness.

Quote from: Joseph DiPerla on Sat 23/06/2012 16:59:444. When a new feature is implemented, the person who wrote the function must explain it to the Help file writer team and the project organizers so that they can put it in the help file. After that, the Demo Game Team will find a way to implement the new feature, if it applies, within the game so that the community will be able to see how they can use it and also see a demonstration of it working.

Thank you for realizing that not every feature implemented can/should be showcased in the demo game.

Quote from: Joseph DiPerla on Sat 23/06/2012 16:59:445. No working with the SCUMM Team, atleast not for now. AGS is AGS, not AGS SCUMM. Perhaps way in the future, this can be considered.

This is ridiculous. If the ScummVM team (which by the way is completely different from those who made SCUMM :P) is willing to work with us on developing AGS, they are more than welcome. It has already been well noted that due to licensing issues, that the official branch of AGS cannot and will not be integrated into ScummVM. Due to that, we should not devote our efforts on the engine directly to making it ScummVM-compatible. If we can do that within a reasonable margin, that's one thing, but we shouldn't be jumping through hoops to fill their needs. I think this may be what you were getting at, but saying "Nope, you are not allowed to work with them ever at all" just sounds a bit authoritative.

Quote from: Joseph DiPerla on Sat 23/06/2012 16:59:44Release Rules to follow:
1. The project Organizers will determine when the next version of AGS is to be released, depending on if they feel that the bugfixes and features implemented warrants a new current release.
2. Once they determine that, a brief internal testing period will go on in which the team will test the demo game/ IDE to see if anything is broken.
3. If all looks good, the team releases a Alpha version to the public.
4. If the public finds any bugs, the development team is to stop implementing any new features and work on destroying those bugs once and for all.
5. Once thats done, a Beta version is released. If all looks good, move on to the next step. If not, repeat steps 4 and 5.
6. If its all good, release the official version.

Well the purpose behind the Beta version would be pretty much what you've defined as an Alpha version, and what you've defined as Beta would be more like a Release Candidate. Typically Alpha versions of software are labelled as such because they are not ready for public release. When an Alpha version is made public, it's typically to get more feedback on core changes (like CJ did when redesigning the editor) rather than feedback on feature implementations and bug fixes. Beyond that (arguing semantics, I know), it seems fine.

Quote from: Joseph DiPerla on Sat 23/06/2012 16:59:44When to accept new members to the team:
There really are no guidelines for this, however, the community and the development team must be able to trust you and you must prove yourself worthy. Perhaps a person who wants to join the idea team would need to either be a long time member of the forums, or a person who has shown that they can create a game. A developer would need to prove themselves by perhaps creating modules, tutorials or plugins, etc... Really, there are no set strategies to determine who joins the team or not. The only real stipulation, so to not over crowd the team, would be that the only time we accept new members to the team is when one team member steps down for whatever reason. A new member acceptance would need to then be accepted via a vote from the team members which will go on for one week.

Again, I don't think that "over crowd[ing] the team" is a realistic issue. There shouldn't be required prerequisites for assisting, so long as you're competent and willing to work within the defined methodology, work with the team, etc. Anyone who has the technical ability to do so, for example, should be able to implement a bug fix into the engine. We shouldn't have to wait for one of the "dedicated" team members to take it on if someone else can get it done sooner.

Quote from: Joseph DiPerla on Sat 23/06/2012 16:59:44Priorities for the time being:
Stage 1: Code Refactoring.
Lets let the refactoring team take care of this first. Without doing anything else, let them optimize the code sources and structure and what not.

This is already under way. One of the main goals here should be, more than just organizational structure, actually reimplementing this or that in a common and consistent fashion, so as to create a sense of unity across the code base as a whole. Some might say that goes beyond "refactoring" but then (again, arguing semantics) maybe we should call it "Refactoring and Reimplementation". Besides, everyone can use a little R&R sometimes. :D

Quote from: Joseph DiPerla on Sat 23/06/2012 16:59:44Stage 2: Documenting the engine source code. This will pretty much be an ongoing thing past the other stages.

Right, this type of documentation will need to be created and then maintained consistently so we don't wind back up in the same boat.

Quote from: Joseph DiPerla on Sat 23/06/2012 16:59:44Stage 3: Fixing the current ports that exist.
Rather than begin porting to a new OS, the team will focus on making sure that the current ports are functioning and doing what they should to work on their respective OS. Once thats done, it really paves the way for any new port that will be considered.

I think, for the most part, the existing ports are fixed. I haven't tracked them extensively, but I'm not aware of any major outstanding issues that are specific to any given port of the engine. This also would be an on-going step though, as we must always make sure that new features and bug fixes don't alienate any of the existing ports (and/or that those ports can be updated to resolve the issue).

Quote from: Joseph DiPerla on Sat 23/06/2012 16:59:44Stage 4: Modernizing the engine a bit:
Just so AGS can keep up with other modern 2D adventure game engines: A) Remove Limits  B) Allow more resolutions and custom resolutions. C) A compilation option for IPhone and Android   D) Proper Paralax Scrolling   E) A more fully integrated particle effects engine  F) 2.5D Capabilities G) Advanced FMV.

See, here you've said that we're only allowed to make one suggestion to the engine per two months, and you've just come out with seven within the space of a single day. Thanks for proving my point about that! ;) Removing the static limits should largely be dealt with as part of step 1, IMO. That's one of the things that should be reimplemented as a generic list so that we don't have to worry about these hard-coded limitations. Resolutions should simply be a matter of allowing Allegro/SDL/[insert graphical back-end here] to be initialized or have the video mode changed. I've done some minor tinkering with SDL, and even things like toggling full-screen should be technically feasible. Regarding compilation, we should have this more like Visual Studio/[insert other IDE here] where you can select the build target for compilation. This would require changes to the compiler and its association with the editor of course. The other points we could definitely look more into, but these first few seem particularly relevant suggestions.

Quote from: Joseph DiPerla on Sat 23/06/2012 16:59:44Stage 5: Discuss Goals for AGS.

Stage 6: Proceed with further development.

Stage 7: ???

Stage 8: Profit. :)

Edit: I thought that might happen. Two new replies while I was typing. Now, let me post this so I can read them! :P

Joseph DiPerla

I am a programmer. Not a c++ Programmer or C#. I do know a little C++ and can do a little bit of what I need it to do, but not to the point of using it to help with AGS Development. But I know web development languages and VB. Trust me, I am not trying to be god like here. I am certainly open to suggestions on this. I just am trying to get motivation and development going here?

Also, consider that even though the write up for this was long, the idea's mentioned are not perfect and are up for discussion.
Joseph DiPerla--- http://www.adventurestockpile.com
Play my Star Wars MMORPG: http://sw-bfs.com
See my Fiverr page for translation and other services: https://www.fiverr.com/josephdiperla
Google Plus Adventure Community: https://plus.google.com/communities/116504865864458899575

JanetC

I'm interested in helping port AGS to iOS and MacOS because Wadjet Eye (I'm Dave's wife and work with him) really needs portability at the moment for commercial reasons. I'm a C++ programmer primarily but I can turn my hand to anything. I can dedicate a lot of time to this.

Crimson Wizard

Well, the fact that such discussions appear could mean only that something is not right with organization. And in this context such posts serve their purpose right, whether everything that was written there is correct or not.

What I mean, it is not always important how the discussion started, important is that certain questions need answers.

Personally I try not to dive into discussing things I know not much about, or something that depends on outcome of other more urgent problems. Hence I am not going to write long posts here about Allegro or scripting language improvements, etc. There are people around who know better about that so they'll do. You may call that philosophy,... or maybe sheer pragmatism :)

I am totally sure that there should be an announcement made to the users of AGS, that would explain situation in general. Sooner or later people will start to wonder what's going on, and it would be impolite to make them read all those verbose threads :) Besides you may never know if a newcomer with skills would like to participate in development.

monkey0506

Hey Janet, Dave's talked to me a few times about porting AGS, and I know it's something you're very interested in. JJS has done some work on porting the engine to iOS, but I'm not fully aware of the current status of that port (as I don't own any iDevices). You should definitely get in touch with him and check out his repo.

As a matter of fact, it looks like the most recent commit was only a few hours ago, with a sample config file for running the iOS port. :)

JanetC

Quote from: monkey_05_06 on Sat 23/06/2012 18:59:40JJS has done some work on porting the engine to iOS, but I'm not fully aware of the current status of that port (as I don't own any iDevices). You should definitely get in touch with him and check out his repo.

I've messaged him. Not sure where to start!

Crimson Wizard

Quote from: monkey_05_06 on Sat 23/06/2012 18:59:40
As a matter of fact, it looks like the most recent commit was only a few hours ago, with a sample config file for running the iOS port. :)

As a matter of fact, here is probably Janet's repo :)
https://github.com/jeancallisti

Unless it is someone else with similar name...  (roll)

JanetC

Quote from: Crimson Wizard on Sat 23/06/2012 19:02:44As a matter of fact, here is probably Janet's repo :)
https://github.com/jeancallisti

Huh? I haven't written a line of code yet! :) Planning to start next week.

monkey0506

As I've told Dave I don't really have much experience with portability of code, but if you browse around his repo you'll find the work he's done to get the source to build for Mac OS X as well as iOS, Android, PSP, etc. You may also want to take a look at this thread. I'm sure your feedback there would be invaluable.

P.S. I'd love to have you as an active part of developing the engine. Working with Dave has been a great experience (and not just coz I was getting paid (laugh)).

timofonic

Quote from: JanetC on Sat 23/06/2012 18:56:00
I'm interested in helping port AGS to iOS and MacOS because Wadjet Eye (I'm Dave's wife and work with him) really needs portability at the moment for commercial reasons. I'm a C++ programmer primarily but I can turn my hand to anything. I can dedicate a lot of time to this.

That's very good! You and your husband are getting profit and enjoying AGS, it's good you want to contribute back to the project. Also, both of you can know better what the project needs in a more professional way ;)

Terrorcell

I am so glad to see this kind of push towards continuing AGS's development!
Having used (on and off) AGS for 6 years now, its an amazing feeling to know that people from the AGS community are ready and willing to improve on what has already been a great experience.
I'm pumped to see how this pans out, no matter how long it takes :D

Crimson Wizard

Quote from: JanetC on Sat 23/06/2012 19:04:25
Quote from: Crimson Wizard on Sat 23/06/2012 19:02:44As a matter of fact, here is probably Janet's repo :)
https://github.com/jeancallisti

Huh? I haven't written a line of code yet! :) Planning to start next week.

Erm. Looks like I was mistaken after all. Jean Callisti has "(monsieur xx)" alias :D (https://github.com/jeancallisti)
But it was funny coincidence - JanetC, Jean Callisti...

Joseph DiPerla

OK, so I have had some time to reply to this thread a little more appropriately now.

QuoteI agree about AGS community should start coding ASAP and form a proper team, merging efforts and organizing tasks. But your proposals are a bit monolithic, as you don't count on the personal motivations on this project runned by unpaid volunteer people. AGS is nor a Foundation or a Corporation, but a loosely community driven project (in the sense of not clear direction or strong management on it) with deep origins on a lone programmer that did a quite big effort.

As you said, AGS should start coding ASAP and get a proper team. I agree that AGS is a loosely community driven project, however, that doesn't mean we cant have an official team. And just because we have an official team, it does not mean everyone has to work with deadlines and such. Re-read the rules I suggested. You are not obligated to work on AGS as if its a full time, or even part time job. You work on it in your spare time. Thats what the bug tracker I suggested was for: Make a suggestion or bug listing in the bug tracker. If the community agreed that its a wanted feature, someone can volunteer when they feel like it (Nothing is assigned) to take on the task in the bug tracker. Then from that point on, it gets implemented when it gets implemented. If the coder decides to let go of the feature or bug, they can unassign themselves. So there is no pushing someone to be forced to work on something or to complete it by a particular deadline. The monthly reports are just a suggestion so that we can see how the progress is going and whats going on with AGS.

As far as having AGS be open source... You do need a dedicated team. Look at SCUMMVM or at Open Sludge. These have dedicated teams. Yes, people who are not on the team are also developing stuff with it, but they still have an official team to offer official development branch releases. I almost never go and download an altered version of a program. I always download the official until its officially discontinued. Another example is Blender 3D. They have other branches, but I use the official one.

Same with AGS, we can have a Draconian Edition, A Ryans edition, A JJS edition... etc.. But I try to use the one thats official. Most different editions can have features I like, but because of so many development branches, I couldn't use them all in my project. See what I am trying to say? I hope I am coming off clear, but humbly in this. I just think a dedicated official team would do some good. And part of the reason why I suggested so many names and so many positions was so that development can be a little faster, diverse and have more powerful progress.



QuoteTo make the infraestructure, the team needs to be formed in a progressively organical way first. If a Foundation were done, things would get easier and ask for donations and some commercial activities (a cheap licensing for propietary usage, advanced support and paying to have special features done quickly and having a limited exclusivity to them, teaching development of adventure games, etc.) to get funds and paying the most skilled developers to work FULLTIME on the project.

I guess read what I wrote above.

Quote
Why that obsesion about Allegro? What's so special and cool about it? Are you a programmer? If yes, what are your facts about it? Despite SDL having some issues too (and still not usable on certain platforms) it's actively more developed and available on lots more platforms than Allegro. OpenGL is another good candidate for certain platforms, too.

You did put JJS as "code refactoring", but his goals are more related to portability. Instead, Crimson Wizard is doing a GREAT refactoring work and he's not listed as "code refactoring".

I like Allegro personally. Its not ported to as many platforms as SDL is. SDL is certainly more popular. However, I do feel that Allegro is more robust. I feel its graphic capabilities are very clean and powerful. I do not however agree that SDL is more actively developed. Allegro does not provide as many releases as SDL does, but it is very active behind the scenes as I have been told by the development team. I think the main problem I have about moving to a new Graphics core is that we then have to re-implement everything all over again. This could take time, hard work and also cause some confusion. It would also have potential to break a lot of things and cause more bugs. But what if Chris would like to still contribute to AGS' code? How well would he know SDL then? Why hadn't he moved to SDL in the first place? He took time to alter a lot of other main things about AGS, why not that? I also feel that Allegro, even though not readily ported to other systems, seems to be the easiest to modify the code to allow it to be ported to other systems. I do not personally know how true that is, but I have read on the internet many people saying that.

I do like OpenGL as well. I think it paves the way for some 3D content as well as support various platforms far better than any other library. My beef with it is nothing really important, rather that when ever I try to program with it, I cant seem to understand a damn thing about it. Remember, I am not a great programmer in C++, just a casual one. So that may be my problem. Also, I do like Nokia's QT library as it provides support for OpenGL, mixes well with other libraries, offers its own scripting language (If we really were going to do that) and also has many GUI Widgets for both the engine and editor alike. Just look at what its done for kbasic.org and q7basic.org .

QuoteI agree about not being in SCUMM Team, because that Team focuses on the SCUMM engine only.

I'm not sure if you are using the correct terminology or got some concepts right, really. What's your background in this? Are you making a poll or wants others to totally accept your words because are blessed by God?

God? God is dead, as Nietzsche said

For SCUMMVM, I do not mind if they wanted to try and port AGS into SCUMMVM themselves. If they want to, more power to them. However, they use SDL and that would mean again, leaving Allegro. I also feel that this would put too many cooks in the Kitchen, figuratively speaking. If SCUMMVM would like to include AGS, thats fine. But I think they should be branched apart from the official AGS dedicated team. I probably should have specified that a little better. Sorry.

I have had background experience in working with coding projects, just not C++. Mostly VB and PHP/HTML 5/ CMS. So, I might have gotten the terminologies and concepts wrong as well. I admit to that.

I do not certainly want others to accept what I am saying. Good god, no. I am just proposing an idea and a system for getting a team to work together. I would love if most of my idea's would be implemented here (After all, who wouldn't?). But this is certainly up for modification and discussion. I just want to find a way for AGS to go on living (officially I mean) and to get coding on it done a bit more progressively and timely.

---------------------------------------------------------
Joseph DiPerla--- http://www.adventurestockpile.com
Play my Star Wars MMORPG: http://sw-bfs.com
See my Fiverr page for translation and other services: https://www.fiverr.com/josephdiperla
Google Plus Adventure Community: https://plus.google.com/communities/116504865864458899575

Joseph DiPerla

Apparently there is a limit to how much I can post in a reply....





QuoteNow, that's a decision!  It's a bit funny, I am getting this lesson for the second or third time in last year or so: if you see that everyone is hesitating - do it yourself. Even if you fail, others will see your example and give a hand.

I wish I could take the lead in this, however, I am a newbie in the C++ and C# language area's and couldn't do more than just alter string values at this point of AGS' development. LOL. I am still learning however and perhaps one day I can take a more advanced lead (by example of course) with it. What I would be able to do is make a version of AGS editor available for multiple platforms by using kbasic or q7basic, but thats if the compiler was seperated and able to compile text files and graphic images into game code seperately from the official editor.

Quote
But - closer to the topic.

Di Perla, you've actually raised a very important question. I may be not an ideal programmer , but I have an experience in software development, and I've "seen things", as some use to say; I've seen projects being screwed up because people who wrote and maintained it forgot what they are doing and what the program is supposed to be.

It is impossible to make a successful project without explicitly defined idea and concept.
It is possible, but actually not recommended to make a project without an accurate design document, which would state what we are doing, why we are doing this, and what our program supposed to do.
And last, but not least, people should understand that no program can and should be universal. There's always a temptation to add this brand new feature and that additional functionality, and to extend the program core god knows where; I know this feeling too! but one should learn to restrain himself. 

You know something... I feel that you can have a team of not so ideal programmers and coders and such and still be successful at a project. But only if teamwork is involved. It is possible that you can make a great engine even without a team and without a plan. But that can slow things done and it can still create a lot of bugs. Looking in from the outside, many potential developers can also see this as a downside to using AGS. Can you immagine what could happen?

Outsider: "So what is AGS?"
Community: "Its a powerful 2D point and click adventure game engine."
Outsider: "Does it support 3d?"
Com: "No, it is strictly 2D."
Com 2: "Not true, you can use the plugins or modules to simulate 3D."
Com 3: "You shouldn't say its strictly 2D. Some are going to be implemented this into the engine soon."
Com: "Oh yeah? When?"
Com 3: "I heard within the next release?"
Com 2: "Thats not what I heard."
Com 4: "Me neither."
Com: "Well, if it comes, it comes."
Outsider: "???"

Outsider: "Is AGS actively maintained right now?"
Com: Yep, it sure is. CJ is its creator, but he open-sourced the app to the community."
Outsider: "So is CJ actively developing this himself?"
Com: "Well, not so much anymore since he has limited time to do this. He left it for the community sort of to handle."
Out: "I see....???"
Com 2: "But the community has done lots of work with AGS though."
Out: "Oh... Like what?"
Com: "There are a few development branches out there. You have AGS Draconian Edition R6 which contains "blah blah blah.""
Com 2: "You also have JJS build which has ported AGS to various systems."
Out: "Thats awesome!"
Com 3: "Downside is that all the stuff in the Draconian edition isn't available for those ports since his build is not involved in that branch."
Out: "Oh.."
Com: "Oh, and there is another branch that does...."
Out: "Its ok, I am just gonna go use Wintermute or Visionaire..."

I could have kept going on like that, so I stopped myself. Granted, maybe I am wrong in how I think outsiders may react to this or even if some will, its not that many that will.
[/quote]

Quote
There are other guys who are making a game engine with other properties, based on other technology (newer, advanced, name it)? Good for them! Haven't AGS had its own niche in game-making?
AGS is a tool, and as a tool it should be aimed for certain work, result and user.

Agreed with that. But it doesn't mean new features shouldn't be implemented. It is a tool. But tools get better with time.

Quote
Regarding "Development rules".
1. I believe there is a way to hide Allegro behind a thin wrapper, like an base interface for example. I am not suggesting to switch Allegro for anything else, but that will give an opportunity to do so in uncertain future, if one would like to do so badly.
3. I actually do like your idea to separate Engine and IDE teams. There are people who know C++ more, and those who know C# more. Plus, implementing runtime functionality and making a proper user interface are much different tasks and not everyone is able to do both on high level.
1. I can agree with that.
2. Just what I was thinking.

Quote
A side-note: I am happy you placed me in your list  but I am no "Porting-guy". Unfortunately in my work as a programmer I mainly focused Windows; I did wrote couple of apps for Linux, but I used Qt library, which hid most of platform specifics.
Hehe, sorry about that. Its hard to keep track of what skills everyone in the community has. Either way, you seem to be a talented programmer.

Quote
Quote from: timofonic
Are you a programmer?
Are you?
Sorry, but I wanted to ask this for too long

Yes, but mostly for PHP/HTML 5/ VB. I can do very little as far as c++/c# goes.
Quote
Quote from: timofonic
What's your background in this? Are you making a poll or wants others to totally accept your words because are blessed by God
From what I know, he is a long time member of the community. And mind you, people here do not accept anyone's words easily.

I am not blessed by god, thats for sure. lol. But, I have been in the community since 1999. Just ask Mods and CJ. They can remember me from the earliest memories of when AGS/AC started. You can even look up archives of the older ez board forums to see how far back I go. I am mostly known for my giant Simpsons Template for AGS.

------------------------------------------------------------------------

Quote

One of the biggest reasons why CJ probably never seriously considered swapping out Allegro for SDL isn't because Allegro is the "pure foundation of AGS", but rather because it's so deeply embedded into the source code. SDL does have better support for other platforms where Allegro is still playing catch-up, so I think it could be beneficial to do this swap. As a matter of fact, I think the general consensus is that we shouldn't tie ourselves to any graphics/hardware library in particular, but should abstract that out away from the engine core, and then we could allow various back ends to be implemented as needed/wanted.

Well look, we obviously know whats involved in replacing the graphics core. If thats what the development community would like to do, then so be it. One thing I do like about SDL is that it can work with OpenGL as Allegro, from what I hear, can not. I also like that it is readily available for many platforms. But like I said, I feel Allegro is more solid, its already there and is a major part of AGS and also, though sdl is available for more platforms, I hear that porting it yourselves to another platform is far easier than porting SDL to a platform that is not supported. Just what I heard.

Quote
Wait, what the hell? Why does Calin Leafshade make your list twice but I'm only on there once?  Also, I see you have other people listed here under "Module Team", but I'm not one. I guess the fact that I've written more modules than anybody else (except possibly SSH, haven't counted recently ) doesn't qualify me for the module team? Well, fine! I see how you're gonna be about this!

Hehe, sorry, its hard to keep track of who is who with real names and nicknames (EG: CJ/Pumaman, Steve M/Kweepa, etc...) I have you as a core programmer because I love your modules/plugins and feel you have so much talent that I would rather personally see your stuff implemented directly into AGS. I really really do like your stuff.

Quote

I don't think we have anything to...wait for it...
hide.

Feedback from the community should be taken into consideration to help things. If we're taking things in a way that people feel goes "against AGS", then they should have the right to be heard.


Agreed, but to keep things more organized without too many outside comments within the development forum, it should be limited at the very least to the development team for commenting. Everyone else can post in the other general or technical forums.

Quote
This is a silly rule. Just because that's where JJS' repo is presently located doesn't mean we should tie ourselves down to any long standing binds or ties to any particular versioning system/site.

Its not just his, but its also where any work thats being done on AGS unofficially is being done. At first, even before JJS, Gitorious was being used a lot. But it seems that many people are more active on Github. Honestly, the main SVN should be used, but I feel like thats been stuck on Revision 76 or something for a while.

Quote
Yes, but they should also alert others that, "Hey, I'm working on fixing this..." and then keep them updated. If they don't get it taken care of, anyone else should feel free to come in behind them and get it done.

But thats the purpose of the bug tracker and monthly reports forum is for. The bug tracker will show you who assigned themselves to the feature/bug/enhancement. Then the monthly report will alert us to see if they had a chance to do anything in that regard. Then if someone else wants to take over, or lend a hand, they can. But atleast this way, we know whats going on.

Quote
Um, no. We shouldn't require threads to stay open for an artificially mandated period of time. Once a significant trend has manifested on a particular issue, we should be willing to follow that (whether it takes 2 weeks, 5 weeks, or 3 days). Ideas that aren't acted upon now shouldn't be thrown out forever though. That is beyond just closed-minded. We shouldn't be constantly spamming the same ideas, but if the paradigm of where AGS is at today has shifted from where it was at when the idea was first suggested, we should always be willing to give it fair review.

Agree and disagree. A topic needs to end in a moderate order, otherwise the discussion can go on forever. Really, the topic is only there for the purpose of presenting the pros and cons and the voting is used to make the final decision so as to not just keep going in circles. Sometimes you just need to stop talking and get to the point. Its like the presidential campaign. You have a set amount of time to campaign, but when its voting time, its voting time, END OF STORY. And yes, I know its not a presidential campaign and understand the differences. Again, structure, organization, team effort, time limits... These are things that allow a project to succeed in the long run. In the work place, these things are essential. Now, while AGS is free and voluntary, it doesn't mean that the official branch can not follow a workplace like system. Ok, you are right about not throwing an idea out forever. That was wrong of me to suggest. However, rules need to be in place so as to not SPAM the idea over and over and over again until we hate the person offering it.

Quote

This, is absurd. "to discourage clutter" is the reason why we need the bug/feature tracker, which AGA is currently working ('round the clock I'm told) to get up and running. Anyone should be able to offer suggestions at any time. We should not be artificially impeding growth just because we don't want the forums to have too many threads going at once.

I wouldn't say its absurd, particularly as it was meant to be something to help, but I have thought about what you said and agree that the bug tracker is what should primarily be used to discourage clutter.

Quote

Again, this is something that...I feel anyone should be able to step up and implement anything at any time, as long as it is reviewed and determined to be good. If you're not fulfilling a particular role, someone else should have the right to step in and take it from you, in part or in whole. If you're that worried about stepping on someone's toes, or having yours stepped on, then maybe you should go write your own game engine. The beauty of a community like this is that we do have sufficient activity and membership that we have amazing skill and talent readily at hand, and willing to offer their time and services. It doesn't always mean that any given person will always be the sole party responsible for that particular role, but insofar as they are able to continue fulfilling it, they should be allowed to do so. There shouldn't be a required process by which to "step down", so much as just a fair warning if you're not going to be able to contribute as much as you have been (as a courtesy rather than a mandate).

I think you misunderstood what I was trying to suggest. I agree, if a role is not fulfilled, anyone should be allowed to step in and take over. If anyone wants to implement something not suggested, go ahead. But, before you put it in there, make sure everyone is ok with it, or perhaps someone else is not working on it and then someones work needs to be discarded or altered significantly. Its supposed to be organized and time well spent. Thats the purpose of my suggestion. Honestly, I wouldn't care of having my toes stepped on. But we should all be concerned about stepping on anyone elses toes. Thats what being teammates means. Again, reread what I wrote. I never mentioned that someone should be replaced or kicked off the team as a mandate. Its totally a conscious decision of the individual. Please reread my suggestions. I think you are misinterpreting my intentions and idea's. It almost seems like you are getting mad at me Monkey. Please, my intentions are only for the best not for selfish reasons.

Quote
Development rules to follow:
1. No swapping out of Allegro for anything else, such as SDL. However, other graphics engines can be used to supplement Allegro for whatever reason. We want the core of AGS to remain the core of AGS.

No.

I do not mind being disagreed with and my idea's rejected, but come on! Give me something more than a no. I mean atleast agree/disagree with the points I made about WHY Allegro should stay in place. Again, if you read my replies, you will see that I am not stubborn as to say "its my way and thats that." I am willing to swap out Allegro, but present me with a logical reason as to why this should be done and reply to the reasons why I feel this shouldn't be done. Monkey, think about the stuff going on in the discussion about AGS Script. Its sort of a similar argument here.

Quote

2. AGS Script will remain the default scripting language for AGS and will continue to be developed on. However, if you want to add another scripting language, it should be as an alternative in the sense of how Extern C works in C++ or in the fact that one can add a module or script that can be used within AGS. However, AGS Script will still remain the primary Scripting language for AGS.

I agree with this simply because I feel that it is extensible enough that we can make it fit our own needs without having any wide-spread negative impact. As I said in the other thread, swapping out the graphic/hardware back-end doesn't change the way people are going to be using the program. Changing the scripting language does.

Again, as with Allegro, though I prefer to have AGS Script remain, I am also open to it being swapped out. I hope that yours and my argument on this matter stick though. I much prefer other languages supplementing AGS and not replace AGS Script, if you understand what I am saying. I believe it was timofonic that expressed correctly what I would like to see in the thread about scripting.

Quote
3. If a member of the Engine Core Team Implements a feature that requires an adjustment to the IDE, they must post that adjustment within the bug tracker for an IDE developer to take on. Until someone takes it on and implements it into the IDE, that feature can exist within AGS, however, it will not be mentioned within the release of any version of AGS until it is supported within the IDE as well.

Again, we shouldn't artificially withhold this type of information. If the engine has a certain capability, we should be able to clearly and directly state that the engine has the capability. If the editor doesn't have a way to take advantage of it, then that should also be noted, but again, this just seems like artificially impeding growth for the sake of some bureaucratic political correctness.

I do see why you would say this. I really do. But think of this logically as well. If we tell someone that the engine has a particular capability that everyone wants, yet noone can use it because the editor doesn't support implementing it, what would the reaction of the community be? It would be "Well, you should implement this now.", "Why haven't you implemented this yet? The feature is there, why tell us about it if we cant use it?", "Whats taking so long to get this implemented?", etc... You want to minimize these kind of comments and also not get someones hopes up if the feature will not be useable for a while. We do not want to raise expectations. Perhaps we can add a whats being worked on section in the updates so everyone can see what will eventually be fully implemented. Perhaps something like "TCPIP features:  30% done", would be something that can hold people off for a while. However, if the development team decides to do it your way, thats fine too. Remember, nothing I say is written in stone, nor do I expect it to be. Part of perfecting something is to have a nice mature and progressive discussion.

Quote

Well the purpose behind the Beta version would be pretty much what you've defined as an Alpha version, and what you've defined as Beta would be more like a Release Candidate. Typically Alpha versions of software are labelled as such because they are not ready for public release. When an Alpha version is made public, it's typically to get more feedback on core changes (like CJ did when redesigning the editor) rather than feedback on feature implementations and bug fixes. Beyond that (arguing semantics, I know), it seems fine.
Whoops! You're right.

Quote
Again, I don't think that "over crowd[ing] the team" is a realistic issue. There shouldn't be required prerequisites for assisting, so long as you're competent and willing to work within the defined methodology, work with the team, etc. Anyone who has the technical ability to do so, for example, should be able to implement a bug fix into the engine. We shouldn't have to wait for one of the "dedicated" team members to take it on if someone else can get it done sooner.

Very true. But still, you do not want to just accept anyone to a team. You want to make sure they fit the bill, otherwise they can screw something up, or even destroy the dynamic of the team in general. I have seen this happen when I was working on another game project with some other fellows.

Quote
5. No working with the SCUMM Team, atleast not for now. AGS is AGS, not AGS SCUMM. Perhaps way in the future, this can be considered.

This is ridiculous. If the ScummVM team (which by the way is completely different from those who made SCUMM ) is willing to work with us on developing AGS, they are more than welcome. It has already been well noted that due to licensing issues, that the official branch of AGS cannot and will not be integrated into ScummVM. Due to that, we should not devote our efforts on the engine directly to making it ScummVM-compatible. If we can do that within a reasonable margin, that's one thing, but we shouldn't be jumping through hoops to fill their needs. I think this may be what you were getting at, but saying "Nope, you are not allowed to work with them ever at all" just sounds a bit authoritative.

I sort of meant that. I made a comment about this earlier in this post. Look it up. I am too tired to keep writing. LOL.

Quote
Stage 4: Modernizing the engine a bit:
Just so AGS can keep up with other modern 2D adventure game engines: A) Remove Limits  B) Allow more resolutions and custom resolutions. C) A compilation option for IPhone and Android   D) Proper Paralax Scrolling   E) A more fully integrated particle effects engine  F) 2.5D Capabilities G) Advanced FMV.

See, here you've said that we're only allowed to make one suggestion to the engine per two months, and you've just come out with seven within the space of a single day. Thanks for proving my point about that!  Removing the static limits should largely be dealt with as part of step 1, IMO. That's one of the things that should be reimplemented as a generic list so that we don't have to worry about these hard-coded limitations. Resolutions should simply be a matter of allowing Allegro/SDL/[insert graphical back-end here] to be initialized or have the video mode changed. I've done some minor tinkering with SDL, and even things like toggling full-screen should be technically feasible. Regarding compilation, we should have this more like Visual Studio/[insert other IDE here] where you can select the build target for compilation. This would require changes to the compiler and its association with the editor of course. The other points we could definitely look more into, but these first few seem particularly relevant suggestions.

Hehe, ok you got me on that one I guess. Look above for a reply to what you said earlier. I guess it makes sense to remove the limits of how many suggestions the development team should make. Again, I was just trying to limit having 30 pages of topics with idea's with some even being repeats. As for the building version... Thats not particularly easy. I am working on a way to do this for Android and put it into the editor, but it is proving a little difficult. Really, as far as Android (And perhaps IOS-not sure since I do not do IOS programming) goes, you would need to have the engine recompiled using the SDK and a user would need to have the SDK properly installed on their systems. There are other easier ways to perform a compilation, but it would not be as fail safe though as to do it the way I just mentioned. However, you can do cross compilation. Really, from what I remember, A single executable is really only the main AGS engine with the data appended to the end of the file. Sort of like how a property bag worked in VB6. Atleast I remember CJ telling me that a great many years ago. So all that would need to be done to cross-compile within the editor would be to repackage the data files with the appropriate executable. This is in theory of course.


---------------------------------------------------------------------------------------------
Quote
Well, the fact that such discussions appear could mean only that something is not right with organization. And in this context such posts serve their purpose right, whether everything that was written there is correct or not.

What I mean, it is not always important how the discussion started, important is that certain questions need answers.

Personally I try not to dive into discussing things I know not much about, or something that depends on outcome of other more urgent problems. Hence I am not going to write long posts here about Allegro or scripting language improvements, etc. There are people around who know better about that so they'll do. You may call that philosophy,... or maybe sheer pragmatism

I am totally sure that there should be an announcement made to the users of AGS, that would explain situation in general. Sooner or later people will start to wonder what's going on, and it would be impolite to make them read all those verbose threads  Besides you may never know if a newcomer with skills would like to participate in development.


I do not fully understand all the concepts behind the AGS Source. However, I understand programming, I understand how to use many different Operating Systems, I also understand how to work with teams as this is my job. As far as gaming goes, I also know that :) . I am not totally ignorant, and I see some shortcomings though with how this development is going forward. So far, the only thing that has been going forward are unofficial ports and some refactoring. But I can not help but immagine the possibilities of what AGS can become if there was a dedicated team. Again, I hope noone was offended by my posts. I wrote it with good intentions and for the benefit of AGS, this community and Adventure games. I just do not want to see AGS die, not ever! It in my opinion is the reason why Adventure games are coming back to life.
Joseph DiPerla--- http://www.adventurestockpile.com
Play my Star Wars MMORPG: http://sw-bfs.com
See my Fiverr page for translation and other services: https://www.fiverr.com/josephdiperla
Google Plus Adventure Community: https://plus.google.com/communities/116504865864458899575

SMF spam blocked by CleanTalk