Messages

Hey! that's totally not what I meant

No worries. I know thats not what you meant. I meant it as a . Although its hard to convey expressions in text.


Thanks AGA, I think if we knew what his goals and desires are for this, we could proceed more peacefully in mind.

First of all, I am not going to post any theoretic plans here, dream team lists (sorry, Di Perla ), etc.

No worries. I have accepted a long time ago that I am merely a laughing stock in this community. But, I do want to mention that a lot of things mentioned by Tzachs seems to be what I was mentioning in my other thread, just in smaller sentences and fewer details. CW, the things I mentioned were because I have taken a lead in development team projects for my prior company and have had success. In fact, I was told that I sped up development by 150% over the last guy who had my position. I know what I mention is elaborate, but I do know that it also works.

But, who are we kidding. Lets face it guys... We all really need CJ to just make a stop by and write a post of how he would want things to go on. Without his approval and his statements, I think we may just keep repeating the same idea's over and over again. Honestly, AGS is his baby and he has the right to tell us what to do with it officially and thats what we probably should be waiting for.

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

Now, 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.

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]

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.

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.

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 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 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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.


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

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.

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

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.

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.

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.

I guess read what I wrote above.

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 .

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

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.

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

@timofonic, CW and all those who agree: +999999 I like that idea. I actually wanted that implemented, but realized that the amount of work involved for that can be a bit tricky and time consuming so I didn't suggest it. But I think that personally, this implementation can make everyone happy, keep AGS the same but make it more powerful at the same time. +999999.


EDIT: Progz, check your PM and also your PP acct so to give me an answer on whats going on please.

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.

One point where I somewhat shy away from Joseph is his apparent fear that AGS is changing too big and too soon. Replacing Allegro with SDL would be a great move, IMO, because from everything I've seen/heard/read, SDL is being more actively developed, and tends to be more readily available on other platforms. This would be one change that would not take away from the non-programmer developers, but would serve to benefit everyone. These are the types of changes I would like to see.

Later, once the issues with the engine's code base and compiler have been cleaned up (JJS and Crimson Wizard are doing a lot of good here, and I'm still trying to find a way to actually get in the door on this), then we can look at abstracting the scripting language itself out away from the core of the engine. From there, we could provide an interface with which it would be possible to plug in languages like Java, LUA, etc., without having to completely get rid of AGScript. Giving the end-user a choice of language would be better than forcing Java on anyone. Trust me.

What about then an SDL Wrapper for Allegro for future ports? Also, do you mean something like : Extern C {} type of thing?

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.

I can see your point and reasoning Snarky, but then let it evolve slowly rather than replacing everything at once.

But Ryan, I also understand your reasoning, but sometimes, if you take time to develop something, it becomes something more. I think we are losing sight of the fact that AGS is not a Programming language, but rather a Game Engine. I agree there is a lot thats missing from AGS Script, but if WE work on it, it can become something more than we can immagine. How do you think some of these other projects started? LUA, AngelScript, or even others? They evolved from something Smaller into what they are now. Thats why its called HTML 5 or PHP 5 or Python 2(Or whatever version its at). It evolves. I believe that eventually, with the work the team puts into it, it can evolve into something more. Atleast then the team is at the mercy of themselves when they want to implement something, rather than at the mercy of the LUA or AngelScript team. I dont know. Its just the way I see it personally.

To tell you the Truth Ryan, I do feel there are more important things that AGS needs to work on at the moment. The scripting engine, while not perfect, nor allowing us to script something quickly, does do the trick and allows for a really impressive game making experience. I mean, just look at Resonance or the other Wadjet Eye games or even Games like Minds Eye or Yahtzee games. AGS can do what we need it to do with the current scripting engine.

The thing is, even though Java may somewhat be superior to AGS Script, AGS Script does what it needs to do. Yes, there are a few things missing, however, we do not need a full blown programming language such as Java to develop adventure games. Its nice to know the features are there. It may streamline certain other things. But, despite a few missing features, AGS Script works very well. To tell you the truth, with AGS Script, if something is missing, it can be added, which makes using AGS more satisfying. Also, the language can be customized beyond the features of what other programming or embeddable languages provide with a little work, while with AngelScript, Java, Python, etc... that would be a little harder to do.

The thing I am seeing with AGS at the moment is there are so many big changes everyone wants to make that really defeat the purpose of AGS to begin with. Some want to implement it within SCUMM, others would like to swap out Allegro with SDL. Some prefer to use different languages to program the IDE. Now we want to swap out AGS Script with something else. Whats next? What was the point in having AGS become open source if we want to make all these BIG changes? Why not just get together and create a whole new engine then? Chris released AGS so that we can CONTINUE Development, not alter and change it completely. Just my two blue cups.

About the repository: I gave Crimson Wizard commit rights to it. monkey_05_06, let me know when you sign up and I will add you too. Also anyone else interested is very welcome.

So how do you want to organize this? Do you want to pull all of the branches of the refactoring fork into it or just the latest one? I am honestly not well-versed into how to do that correctly.

As for the forum builtin bug tracker: That is pretty cool! And I would be for just giving everyone admin rights. I think the risk of nobody stepping up for it now is higher than that of people invalidating each others work.

I do not want to put anyone on the spot, but perhaps giving priviledges to Calin Leafshade  and Alan V. Drake would be a good idea. Calin seems to be talented when it comes to programming (I believe he worked on an AGS to X-Box converter, no?) and Alan has a pretty neat version of AGS Draconian Edition r6. Would be cool to have all you guys working on that. And do not forget CJ of course

So JJS, is Github your new home for development or are you still using gitorious?

it occurs to me now actually that we dont really need a new construct for managed structs since there is already a construct for just that purpose. Namely "managed struct". If we could simply make the managed keyword mean something and implement the new keyword to instantiate them we dont need to invent anything new.

EDIT: Oh, also, we should definitely stick with AGS Script in my opinion since everyone knows it and changing it seems somewhat counter productive.

I agree. AGS should stick with AGS Script. After all, we do not want this project in the end to be something other than "AGS". Also, many of us "not so code at c/c++/c#" people are used to how the scripting engine works. Stick with whats there. There is a reason why Chris used his own scripting language over LUA, AngelScript or Python which were all available at the time that he rewrote the scripting engine.

As far whats proposed with this thread, lets start with the referenced structs. This seemed to have tapored off to a whole new discussion. KISS. The script engine is in place, no need to discuss more details about it. What should be done is take each idea one at a time and start working together to implement that idea. If we can put aside what we want, and just start one at a time with the idea's, development would be more productive. So, I say, leave the script engine as is and lets figure a way to reference custom structs as Calin had mentioned when he began this thread. After thats implemented, we can move on to Dynamic Array's of pointers to custom structs and go on from there. Within a few months, AGS can have quite a nice scripting language implemented. Now, wouldn't that be nice?

EDIT: Also, think of those who are in the middle of producing a large game and would want to keep using the current version of AGS. If we alter something monumental like the scripting engine, they would have a lot of hard work ahead of them.

This community has been so good to me. I owe a lot to everyone here, especially CJ and several of the other members who were able to help me financially. I want to give back to all of you. I don't know how I could do that. I want to make a game, but I suck at graphics. I really do. But I am gonna have to give you all something I can do.

There is no easy way to package an AGS game for Android so that it can be uploaded to the android market. Not yet anyway. I am trying my hand at C# and am trying to implement a way that would offer the user to compile the game for android. What it would do is take JJS sourcecode, compile it and package with your game via a command to the external Android Compilers. This is a little tricky and will require some time. However, in the meantime, I would like to offer a service which will become available Starting July 15th. This service will be queue based and what it offers is for me to compile your game (No game sources required, just the game data and executables) with AGS into an APK so you can upload it to the Android market. The price for such a service: FREE. COMPLETELY FREE. But because of that, your game will have to wait in queue to be packaged. Here are the options however if you would like to package the game:

1) You can have your game compiled with a version of AGS that only loads your game and not anyone elses.
2) You can have your game compiled with a version of AGS that allows the current full version of JJS's port of AGS that loads games from a list.
3) You can have your game compiled into an APK Installer so that AGS is not attached to the game data (For those who already have AGS installed on their devices).

I am still trying to figure out all the complications of this, but I wanted you to get ready for it. What I can also do is this:

1) Send you a link to the APK so that you can upload to your google account store.
2) I can upload it to my account and have it be under my developer name.

So if you are interested, keep this in mind, figure out which choices you want and stay tuned for more information.

I may take you up on voice acting later on. In the meantime, pass this message along to other artists in other communities.

David Fox is not a license holder as he doesn't really work for Lucasarts any longer. I am not worried about license issues. In fact, they have not shut down zak2.org and that game has been released for I think 3 years now. The plan is not to have a website open to the public while the game is in production. If need be, once the game is done and I have something to show for it, perhaps I can run a small kickstarter trying to buy out the rights to Zak so I can release the game without a problem and then after, donate the rights to David Fox himself. So, I do have a contingency plan for it.

Hopefully I can find a team though for this.

OK, this has been something I have wanted to do for years and I am hoping I can find a team that would help me on this. While I know I need more members for music, voice acting and translations, at the moment I only want to begin with Graphic artists.

As mentioned above I am looking for 3D Graphic artists for backgrounds of the game and character art and animation. The whole story is already written out and I am adding some more stuff to the game with input I received from David Fox himself a year ago. So I know what I want and how I want it. The question is, is there anyone willing to do this for free.

I considered doing a Kickstarter on this, but I want to avoid that route and am looking for artists to work for free. However, if I cant find anyone willing to do it for free, please tell me how much you want to get paid or how payment for 3D art works and I will start coming up with some figures for Kickstarter then. But please note, if you work for free, you can take your time on the project. If I have to pay you, then I will expect faster results, especially since those on Kickstarter who pledge would want to see faster results.

The art style I am looking for is a rather mix between 3D anime and DOTT Style. I actually want the game to be brighter rather than darker, atleast for the earth renderings. I kind of almost want a toon shader rendering. Not quite toon colored, but on its way there. I hope that makes sense.

Please note: Before I accept you on the team, I want to see some work from you to see if you are what I am looking for. If you will want payment, I am expecting some mockups of characters and Backgrounds for the game free of charge so that I can have something to present the Kickstarter community with. The more they can see, the better the odds of people pledging.

If you are interested, please post here. Do not PM me. I will PM you after you post here.

Thanks for looking. I hope I can find someone to help me fulfill this dream of mine. Lets go Blue Cups!

While I admire your stand against doing things illegally, I do not understand how it would differ if you extracted the resources or someone else did it for you. Anyway, if it helps, try this: http://adventurestockpile.com/SCUMM/

Maybe if the other developers aggree here to merge their stuff into JJSs repository and JJS agrees to let them do it, the circle could be broken. I suggest the merging should take place in separate git branches of the ags-for-psp repository and slowly and carefully be merged into the main branch when everybody approves.

Agreed.

Wow, I am so psyched about this! I really hope that they get funded. They got a good amount, but I have a feeling they are not gonna get all the money backed on this. I hope they do. Mean Streets and Martian Memorandum were among my favorite games of all time!

OK last link. (BTW, I hope I am not breaking rules by posting in a new post rather than editing the prior ones. I just feel that then this thread would not be recognized as being updated).

This link is a tutorial that shows you how to convert an Iphone app to a webos app in ten minutes using phone gap. I am not sure if this would work with the way you have the iphone port set up or not. But thought I would post it anyway:

http://www.youtube.com/v/wWoJfQw79XI?autoplay=1