Topic: Resolving current situation

[Crimson Wizard]

Since 3.3.0 is practically finished now, I will restate some suggestions.

1. I will make a new branch for 3.3.1, and we should open a new thread to discuss what is going in there. My opinion is: fixing bugs, compatibility with Draconian Edition + any random minor improvements. I was contacted by Gurok who wants to add  at least one new property to gui class (text window padding), so this is where it will go.

2. Custom resolutions branch I was doing; I think I made a mistake by creating it in the central repository at first place; I continue its development in my personal repository for now, because, frankly, although working, its changes history is becoming a mess (numerous attempts to redo things slightly differently). I will continue to update it to all official builds (betas too).
My idea is to let people use & test it, then remake this feature in a more clean way in 3.4.0.

3. 3.4.0 can be continued in parallel to 3.3.1 (or any further minor update). I've already merged one of the last 3.3.0 betas there, so most difficult part of the integration is over. 3.4.0 will become actually usable (by "regular" users) when the GUI for managing room region lists is implemented.
I believe all larger changes should go straight into 3.4.0, so if anyone have larger feature ideas, it is better to consider 3.4.0 branch (called simply "develop" now) as a start.
It will also benefit from testing... but oh well.

4. One problem that really bothers me is ports updates for compatibility with both newer and older versions of AGS. This really is a separate task, because those updates are not related to any new features. On other hand, this may be a better idea to have a separate stable branch for ports, which won't receive any new features until they are proven working. Such branch could get all compatibility updates. In fact, this could be even "master" branch. I would really wish to hear JJS's opinion on this, and from other people who use and/or maintain ports code.

5. Long ago we had an idea to split repository into at least two parts: one for Editor and another for Engine. Although this will duplicate some code and require more caution when changing things, the benefit is more compact dedicated repositories with their respective histories of change, that could also be customized for the needs of the project (with settings like forced line endings). This split may be accompanied by cleaning repository history from excess files (e.g. compiled binaries), thus reducing their sizes.
This needs to be discussed first as well, to see which problems may arise.

[BigMc]

Maybe that's also a good time to remind everyone of http://nvie.com/posts/a-successful-git-branching-model/
If we still want to do it like this everybody has to be aware of this:
master is the branch we suggest everybody to use and is only changed when a release is done (the release branch is merged into master and the commit is tagged).
All development happens in other branches.

EDIT: As you say there are sometimes small but important fixes needed for ports (e.g. Linux version does not build with new library version) that don't make a new Windows build / version number necessary. Maybe these should be done in master and always merged into the release branch and/or develop right away.

[Joseph DiPerla]

Hey CW. Again, thanks a lot for taking charge in this and providing updates and bug fixes. You really are amazing and if it weren't for you (As well as a handful of others of course), AGS would be dead in the water. So thanks a lot to everyone on this!

My thoughts on what you are proposing depend on a few things. For one thing, I totally agree that the Bug Fixes need to be taken care of ahead of anything else. Once the bugs are squashed, development can proceed with a clean slate, so to speak. But for everything else, I had some questions that I was curious about which was mentioned at some point in AGS Development discussion. For the next part of the discussion, I would like to apologize as it would seem I will be bombarding you with a billion questions. Please forgive me. This is mainly to figure out what is next for AGS and for my own curiosity. Knowing what you have in mind will help me and anyone else make more constructive suggestions.

Firstly, Is there an Allegro 5 port being worked on? I know someone said they were personally experimenting with this and I am just curious as to the progress on that. The reason why this interests me is that first and foremost, it will bring more compatibility with Linux, Windows and Mac support as well as iPhone and even Android(Experimental). It would break the PSP port, however I am not sure how many people really find that port useful as it seems to be more of a novelty. I do not believe we can sell our games for PSP without a $10,000 license. Regardless, if people really would like a PSP port, I am sure Allegro can be adapted to work with it. Is SDL 2.1 being considered as a new alternative? I know that was a discussion at one point too.

Second, Are you (Or anyone else) still planning on refactoring the source code? Or is this already considered done based on all the updates that have gone into AGS in 3.3.0? If this is still an option, at what stage of development should/is planned to be done? Or another question could be: Is it really necessary?

My next question is, how much work would it be to provide compatibility with the Draconian Edition and implement its new features? Just curious about this. Also, as far as Mac/Linux compatibility, I know Wadjet Eyes had provided the community with the source they have. Is this planned to be used as well?

One final question... Has anyone provided you with the source to their plugins since you made the request on the forums? If so, how would these sources factor into AGS?

Again, accept my apologies for asking so many questions. I just want to get a clear indication of what the next work load consists of.

Now as far as what I personally think is the best option for 3.3.1 would be to just keep it small and simple. For instance, fix whatever remaining bugs you can find out there, merge the Draconian code in there and add very very very few minor new features. AGS is feature-full already, but as far as new features go, we can wait on those a little longer. I think the exception would be to remove limits and have custom resolutions, but I don't think these should be in 3.3.1.

I know I contribute nothing to the source code of the AGS Engine or the editor, but perhaps my insight might be useful. There's a first for everything after all. I always feel that having a roadmap for several versions ahead can help give you perspective and allow you to develop appropriately. SCUMMVM had always done that and it has helped them tremendously. Having said that, the way I personally see how AGS should go forward from now until 3.4.0 would be this way:

3.3.1:
*Bug fixes
*Draconian Compatibility/features
*Some small limit removals.
*One or two very minor features.
*Ports to other OS improvements if possible and if there is time.
*Some small improvements to the Winsetup(I say this because I already see this happening. Perhaps it can be merged with 3.3.1 if all is working well.)

3.3.2:
*Further development on the ports and getting the bugs fixed on Linux/Mac, iOS, Android.
*Possibly experiment in removing a few other limits

3.3.3:
*Bug fixes from previous two versions.
*Some more improvement on the ports.
*Creating some way for us to eliminate the need for a winsetup(optionally of course) and change settings within our game.
*Not custom resolutions, but perhaps some preset resolutions that AGS does not currently have. That may allow control over the code and bugs to be a bit more stable.
*One or two minor features
*Some small compatibility implementations with plugins that become open sourced??

3.3.4:
*Bug Fixes
*Port improvements
*Remove some more limits
*Some new features.

3.3.5:
*Bug fixes
*Port improvements

3.4.0:
*Custom Resolutions
*Bug Fixes

Beyond 3.4.0:
*Full removal of limits
*Ports to Blackberry, Windows Phone/RT and others.
*More plugins becoming open sourced
*More bug Fixes
*More new features (Obviously)
*Ports of the editor to MacOS X, maybe Linux too.

Again, all of you as the main developers would really know whats best in regards to the roadmap. From how I understand things currently, from what I would personally want and from what I have been reading around the forums as well as what work I can see that many users have done in other branches... This is the way I would arrange it. But please do not take this as me "telling" you or "Strongly suggesting" that you do it this way. I am just putting in my two cents. It's the best I can do under the circumstances

Anyway, thanks again for all the hard work you guys do. You deserve a lot of credit and praise as well as thanks from the whole community.

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

I also wanted to provide some resources or thoughts if you would need or like them. For one thing, in regards to Git or SVN, has anyone considered hosting the source on Sourceforge or Google? Another option would be to house the code on the AGS web server using http://www.projectfork.net/.

Finally, for those who are/will be working on ports... If you need a MacOSX Environment, you can use virtualmacosx.com. It is a Cloud desktop which runs MacOSX(Similar to desktop.onlive.com) so that you can develop Mac OSX apps and iPhone Apps. Just a thought.

[Gurok]

What are the Draconian features you want, Joseph? I am looking at DX9 Vsync currently.

Do people want #region and #endregion? I'm just asking because I'm kind of in that zone right now. On my local repository, I added for, break and continue statements. I am thinking of proposing these as additions to AGS script too.

Obsidian theme? Did people use that?

[Calin Leafshade]

On my local repository, I added for, break and continue statements. I am thinking of proposing these as additions to AGS script too.

You added these to the script language?

[Gurok]

Yeah, I haven't committed anything yet. It wasn't hard. Low hanging fruit and all. The hard one will be switch(), because I think it means restructuring the handle_if_else function, which is very messy. I just refactored the code for parsing an assignment and I was able to do the for loop pretty easily. Break and continue were pieces of cake. There were already jumps in place for the start and end of loops/if statements.

Fix my sprite font rendering issue!

[Calin Leafshade]

Fix my sprite font rendering issue!

It's an engine fault! The plugin makes no distinction between normal guis and text windows.

[Joseph DiPerla]

What are the Draconian features you want, Joseph? I am looking at DX9 Vsync currently.

Do people want #region and #endregion? I'm just asking because I'm kind of in that zone right now. On my local repository, I added for, break and continue statements. I am thinking of proposing these as additions to AGS script too.

Obsidian theme? Did people use that?

I purely mentioned the Draconian Edition as it was in CW's plans and people have been wanting those features integrated into the new version of AGS. For me, I would want all the editor improvements, the 5 parameter tinting and the Directdraw filters. Although I am very interested in your break/continue, for loop and switch cases though. I though the for loop and switch was already implemented in AGS. Maybe it was when Chris was using the SeeR engine??? Oh well.. Would be nice though Gurok.

[Wyz]

I haven't been around much the last year or the year before that really so I haven't exactly follow AGS development. I might be looking a period where I have more time some of which I'd like to invest in the AGS engine. At this point I don't really know where it's at so I need to get back to speed which is going to take a while. I'm also working to refactor the joystick plugin (nearly done) and make a sockets plugin. Both will be released on Github in due time.

So I've been skimming through this topic and I'm just blindly going to make a few remarks so forgive me for that.

As for development it is very import to have a separate branch for release and development; I've heard there were some issues there. Ideally you'd have two teams: one implementing new features and one working on releases. There also would be someone responsible for the main branch and ideally this person is the only one pushing there. So what happens is that the dev-team is ahead one version and implementing all features required by some milestone. In the meantime the release team is testing the previous version to the point where it is a release candidate. They make sure potential bugs caused by new features are found and fixed. When it goes release candidate I guess the general public will also try out this version and when all is good it needs to be pushed to the main branch and tagged accordantly. Git is wonderful for this because it can both be used as a push or pull system. The dev-branch will be pushed by the developers while the main branch will be pulled by the release team. This creates a safety system making sure that the main branch is in good shape. When working on a feature your local repo can be in any state (both the next or the previous version) it is not really a problem as long as you're not touching the same bits of the engine. Even then git has a very good merge system and I've only witnessed very few catastrophic merge conflicts in my live and almost all of them were caused by someone fucking up. Yes, you can fuck up with git so you have to know how it works before you start using it.

For one thing, in regards to Git or SVN, has anyone considered hosting the source on Sourceforge or Google?

AGS is hosted on Github I noticed. I don't know if this is the official repo but I like to think it is because Github is the best. It is not only a place where you can share code, you can also discuss code. Select a line you have a question about and you can comment on it and anyone interested will receive a notification. They call it social coding.

About releases: Github has a system these days to make (binary) releases. You can even have a compile script that automatically compiles binaries and releases them when you tag something I believe. I haven't really used this system a lot but by the looks of it it is quite useful.

One final thing: who decides on the milestones? Do we poll or have a committee for this?

[Crimson Wizard]

Firstly, Is there an Allegro 5 port being worked on? I know someone said they were personally experimenting with this and I am just curious as to the progress on that.

I experimented with this and I abandoned this experiment many months ago, and have no plans to start again. It takes time while it is uncertain how much beneficial it would be, while there are more interesting things to add to the engine; it breaks compatibility with 8-bit games (and even though there may be some workarounds, it is uncertain how well they work and how to implement them), etc. I have personally no idea whether SDL is better. I never used either of these libraries.
Also: http://www.adventuregamestudio.co.uk/forums/index.php?topic=47264.msg636472189#msg636472189

I should underline that the fact that I do not work on this does not mean that no one should. If only the AGS can be magically converted to Allegro5 or SDL2, that would be very nice . The problem is that there are only few people and a lot of tasks. And there are even some old tasks that are still in progress and require to be finished.

Second, Are you (Or anyone else) still planning on refactoring the source code? Or is this already considered done based on all the updates that have gone into AGS in 3.3.0? If this is still an option, at what stage of development should/is planned to be done? Or another question could be: Is it really necessary?

There's no distinct task "refactor all the code right now". We are improving old code over time as we add new features. And this progress will be continued. 3.4.0 has more improvements on this aspect (more code refactored).

My next question is, how much work would it be to provide compatibility with the Draconian Edition and implement its new features?

Not much, I seriously think it's a matter of a week or two, but it should be well considered which features to add and which not. Maybe some can be implemented differently, such as dark editor theme.

Just curious about this. Also, as far as Mac/Linux compatibility, I know Wadjet Eyes had provided the community with the source they have. Is this planned to be used as well?

Someone have to work on providing Mac port in a proper way. I've already mentioned the problem and possible solution here: http://www.adventuregamestudio.co.uk/forums/index.php?topic=46152.msg636478469#msg636478469

One final question... Has anyone provided you with the source to their plugins since you made the request on the forums?

None.

If so, how would these sources factor into AGS?

I hope most of them won't. My opinion is that plugins should remain plugins, except some particular cases, like SpriteFont plugin, that may be  converted into built-in feature.

I think the exception would be to remove limits and have custom resolutions,

Limits are already removed in 3.4.0 branch (well, mostly, except few which were too difficult to get rid of at the moment).
There's no need to remove "some" of them in an intermediate version. 3.4.0 is already practically usable, just need an updated GUI to work with room regions.

I always feel that having a roadmap for several versions ahead can help give you perspective and allow you to develop appropriately. SCUMMVM had always done that and it has helped them tremendously. Having said that, the way I personally see how AGS should go forward from now until 3.4.0 would be this way:

Joseph, I don't mean to be offensive, but I think you are inventing a plan for the plan's sake. In my opinion the lesser versions are situational and are only made when there's a need to add minor improvements to already stable version, while major version is being developed but not yet released.
In my opinion we should rather use the next major version as the primary aim and reference, and release minor versions only if such need arises.

One final thing: who decides on the milestones? Do we poll or have a committee for this?

I would like to know that too :.


@Gurok, regarding Draconian script commands, there's unmerged branch "feature_drac_srccmd", which contains some (or all) of them. Made long ago, but I got carried away with other stuff and forgot to merge it.
Also I kept suggesting to discuss the script additions with community, see if the new script functions are made in a good way (syntax and usage), etc.


//-------------------------------------------------

EDIT: Right, I forgot to say this... Regardless of what you think of me, in fact I feel rather disoriented in a situation when people start to invent/contribute things to a project. That's still a lack of organization. I don't have time to check/test everything (and frankly do not want to do this all the time ), so there must be a way for people to organize, that is:
1. Define milestones for the next major version;
2. Discuss and assign tasks to people, so that no one duplicate/spoil others work;
3. Define a set of rules and conventions to let more people contribute previously unplanned additions without messing things up.

[Monsieur OUXX]

I'm interested in only one thing with 3.3.x and 3.4.x : did you fix the bug that was making AGS 3.3.0+ repeatedly complain that a script had been edited externally, when it actually hadn't been?

[Radiant]

Regarding organizing and milestones, I suspect that a good place to start would be the issue tracker. There are about 180 open issues listed (not counting the "legacy" category), which is a manageable amount. It would be useful to sort these into "low hanging fruit" (straightforward bugs and very minor additions go in 3.3.1), moderate-term goals (complicated bugs and feasible or highly demanded features and additions go in 3.4), long-term whenevers (complicated features or things that would be nice but have no priority go in a category for "unspecified future"), and issues that have already been solved or are incomprehensible can simply be closed.

Then based on this, there is a clear list of what should be done for the two pending versions (i.e. 3.3.1 and 3.4).

[Crimson Wizard]

I'm interested in only one thing with 3.3.x and 3.4.x : did you fix the bug that was making AGS 3.3.0+ repeatedly complain that a script had been edited externally, when it actually hadn't been?

I think this was fixed in one of the early betas, at least no one complained since.

[Joseph DiPerla]

Joseph, I don't mean to be offensive, but I think you are inventing a plan for the plan's sake. In my opinion the lesser versions are situational and are only made when there's a need to add minor improvements to already stable version, while major version is being developed but not yet released.
In my opinion we should rather use the next major version as the primary aim and reference, and release minor versions only if such need arises.

EDIT: Right, I forgot to say this... Regardless of what you think of me, in fact I feel rather disoriented in a situation when people start to invent/contribute things to a project. That's still a lack of organization. I don't have time to check/test everything (and frankly do not want to do this all the time ), so there must be a way for people to organize, that is:
1. Define milestones for the next major version;
2. Discuss and assign tasks to people, so that no one duplicate/spoil others work;
3. Define a set of rules and conventions to let more people contribute previously unplanned additions without messing things up.

Hey CW, definitely not offended. Believe me, I know you have under-taken a large task with not a lot of help. Like I said, you have done an amazing job vastly improving an already AWESOME engine. And that goes for everyone that has helped out on AGS over the last few years. And I know that, even though that there are guys like me and others just trying to provide our two cents to help, that it can be difficult to hear all these things coming from different directions and people. The community would still like to help in whatever way we can. The thing is, we are unsure who to goto to offer this help. While the community views CW and maybe even JJS as the leaders of the development of AGS, we are not sure who is taking the lead. Maybe noone wants to step up or many may feel that it is not necessary, but a project lead would be beneficial. Maybe the community can vote on it? Or maybe all the developers involved can vote on picking one? Don't know. We should leave that with the powers that be, but I think it should be there.

With having that said, and this goes for CW as well as any other developer working on AGS, what is it that us non-C++/C# programmers can do to help in the progression of AGS? We all would like to lighten the load but at the same time not add extra burden on the developers. Would it be beneficial to see if we can recruit other developers from other sites/projects and see if they are willing to lend a hand? Would monetary/material contributions help in any way? How/what can we beta test to help you out? Would it just be better if we simply stick to the basics and just make feature requests/post bugs when we need/encounter them? If there is something we can do to help, then we want to help.

[Monsieur OUXX]

Every now and then, monkey or someone posts links to the bug tracker, but for some reason (permissions...), it seems that non-developers can't see them. Am I right or am missing something? It would be cool if everybody could see the open issues.

EDIT: in addition to Jospeh's post: yes, I also want to thank CW explictly for his awesome work. And the few other contributors too.

[Crimson Wizard]

Every now and then, monkey or someone posts links to the bug tracker, but for some reason (permissions...), it seems that non-developers can't see them. Am I right or am missing something? It would be cool if everybody could see the open issues.

There's some bug in access rights that prevents certain people from going there. While number of people not belonging to "developers" list opened new issues there or made comments (e.g. to "Engine ports" category).
In my memory this happend to cat (something related to "AGS Baker" user group), and someone else... ( was that Ali... or Radiant?.. I forgot :/ ).
Normally this should not happen, everyone should be able to see and open issues. We need to discuss this with site admins (AGA and others).