This is what I have to say.
I think that the arised problem is primarily a result of organizational failure. About 1.5 years ago we were discussing how to organize the work, yet, as time passed, it appeared that only JJS and me are working on the engine (and Tzachs was making few changes to the editor). Somewhere in early 2013 JJS became mostly inactive (IIRC he told me he is being busy with real life issues) and I suddenly found myself alone. Feeling pretty much baffled by this fact, at first I made attempt to develop engine further, without much understanding where I am going (the result is now known as AGS 3.4.0 alpha). When people started to actually using 3.3.0 beta, they began to find bugs and ask for more features, so I switched back to that branch, completely focusing on improving the release. Meanwhile, numerous organizational issues were stacking, without being resolved. At one point I made a promise to myself to deal with them after final 3.3.0 release, being afraid of getting lost working on multiple tasks at once. The monkey_05_06's commits to master branch caught me by surprise, because prior to that he had mentioned about his plans to work on updating Anroid port, but never about redesigning anything in the branch, which was being prepared for release.
(I'll put this just in case: this is not an excuse, but explanation.)
I believe that we need to make at least two immediate organizational decisions.
First, we need to activate the strict rule on branch usage. There was already a discussion on how to do this here: http://www.adventuregamestudio.co.uk/forums/index.php?topic=46296.msg636445912#msg636445912 ;
if someone wishes to (re)state his opinion (whether accepting or declining) about this, I think this will be a good time to do so.
In brief, the idea was to not use master branch for anything but immediate hotfixes in case something is found completely broken there. The preparation for release should be done in a separate branch (e.g. release_3_3_0), further long-term development in "develop", separate features, which require serious changes or global redesign of code, - in their respected branches (preferrably created in personal repositories, rather than central one).
Second, there should be an agreement made on what is going to go to the 3.3.0 release.
My personal (but strong) opinion is that its development came to the point when it needs only careful polishing in order to make it as stable as possible, therefore no big changes should be applied in there, nor changes that do not explicitly fix incorrect behavior, but serve better program structure, class design etc; nor compatibility breaking changes - absolutely not.
Again, if someone has different opinion, please state it now.
Additionally, it would be very nice to decide a place to upload the binary dependencies, like AGS.Native.dll, which needs to be updated often. Git repository is not the best place for such files: compiled binaries compress badly, causing repository to bloat and people to get annoyed.
Then, after this is decided, we need to carefully fix the current master (so much as it requires) and proceed as planned.
On other issues.
I suppose that people involved in development should divide the parts of code/groups of tasks between themselves. I am speaking about timed division, not permanent. Such division should not prevent developers from discussing things others doing, or putting their own problems for public discussion. This should be done to avoid duplicating or contradictory changes, and to keep related changes and code more organized.
What is certain: if one at least suspects that his change will break what other is doing, the change should be discussed first, at least personally. Or, to put that other way: developer should at least warn about what he is willing to change, so that this change won't come as a total surprise.
I do not want to become paranoid from thinking that while I am working on a feature or a fix, someone else is doing the same (similar or other way).
Again, any possible tension may be easened by simply doing a work in a separate branch and/or personal repository prior to merging it with main development branch.
It also might be useful to make smaller commits, each related to one change or a number of strictly related changes. This will make it easier to pick out parts of code in conflicting situations.
If a developer is unsure about his change, and feels he is unable to come to decision himself, it is better to once again use personal repository to temporary keep the code for public review.
My suggestion is to keep central repository clean (without fanatism, ofc).
On breaking compatibility with anything.
This is not a simple decision, and there's usually a lot to consider. What is certain, if ever, this must not happen at random without preliminary discussion.
For example, here I started discussing breaking compatibility with old engine plugins: http://www.adventuregamestudio.co.uk/forums/index.php?topic=45810.msg636451744#msg636451744;
Compatibility with older games is primarily important for ports, because you cannot run original Windows executables on other platforms. If there will ever be a version which breaks compatibility with previous versions of AGS, a need will arise to maintain both old and new branches for ports, because the compatible branch may still require fixes and updates.
On changing/removing project settings, or any previously existing features.
There are several important points that must be tested when such change is done:
1. Test that the games created with new editor/engine build do work.
2. Test that old game projects could be loaded to editor, and still work with none or little updates to settings/scripts.
3. Test that older projects (pre 3.0) could be still imported and work "out of the box", with none or only little updates to settings/scripts. This may require converting old settings into new ones in such a way that'll allow to simulate old behavior with new features.
4. Test that the games created with previous versions of AGS still work as intended when ran with new engine. Similarily, some runtime data conversion may be needed.
On other branches.
The "develop" branch contains a lot of changes to the engine code, including several refactored classes and few more or less cleaned up routines (namely the evil dialog routine, that ran a "goto" controlled loop). Currently this branch is in a way separated from all other development, and as time passes, the situation becomes worse.
Hence this is my honest belief that "develop" branch should be considered as a place for any further code redesign and big updates.
The only big problem (AFAIC) about this branch is my ugly temporary solution for setting dynamic number of regions in the rooms. There was some discussion about how to solve this by introducing new UI component: http://www.adventuregamestudio.co.uk/forums/index.php?topic=48513.0
If that (or any other solution) would be implemented, the "develop" will become practically ready for normal public use, if I may say so. (Still, as alpha, but at least people could use it without being confused about how to change areas count in the room).
The custom resolutions feature is currently floating somewhere in the middle (although logically more close to 3.3.0); it still requires improvement. The question is whether to continue developing it as a first successor to 3.3.0, or merge straight to "develop" (which version number will that result in - is something not of a real big concern). If the aforementioned "develop" issue would be properly fixed, there will be nothing that would prevent us from just merging everything in there, and have a combined "no limits"/"custom resolutions" build.
I have a lot I wanted to add to this, but am at work using a cell phone to type... My suggestion is that we use a bug tracker to track bugs such ad Mantis. When a bug is received, a developer would assign to himself or someone else and work on it. More to follow as soo as I leave work.
I have always wondered why people stubbornly kept at commiting to the main branch, but I kept my mouth shut because I didn't dare to overstep my station :D
I'm sorry I haven't been much helpful this year, sadly I'm basically stuck at working at one of our clients for the whole year (it was supposed to be only 6 months) and when I get back home I have little left to give.
Anyway, I agree with all your points, the branch model we had picked seemed solid and, yeah, I guess it'd be best to stop adding stuff to the current release, I've heard people on IRC complaining about magical blinking and cursor moving issues with the script editor.
About the custom resolution I think it would be best to cram it directly into develop.
@Joseph we already have an issue tracker, and it seems to me it's being put to good use!
- Alan
Quote from: Crimson Wizard on Mon 14/10/2013 17:30:48
This is what I have to say.
OT: you are doing a great job Mr. Wizard, if we as a community (and me as an individual) can help in any way (dealing with administrative tasks, etc.), just ask!
Your proposed solutions for problems 1 and 2 are sensible, I don't see why anyone would disagree. I think it would be better for everyone to reach a quick consensus on this, git "backtracking patches" is no fun. Regarding a the second point, were you thinking about a "freeze policy"?
As to the commits I made (the validity of the contents aside, because it has already been discussed elsewhere), I pushed them to the branch that I was explicitly told to. This still comes down to an organizational issue.
In terms of organizing this project, I refuse to take any part in it. I will not participate in discussions about such things.
Quote from: monkey_05_06 on Tue 15/10/2013 01:35:03
In terms of organizing this project, I refuse to take any part in it. I will not participate in discussions about such things.
Am I permitted a lol?
lol.
As to point 2, I agree. 3.3.0 needs to have a feature freeze starting
now.
We don't want to fall prey to feature creep before this version is stable.
Quote from: monkey_05_06 on Tue 15/10/2013 01:35:03
In terms of organizing this project, I refuse to take any part in it. I will not participate in discussions about such things.
Well, can you at least give a hint what are you planning to work on in the nearest future? :(
I just want to have a trust that we understand each other.
Like many others, I agree with your
2nd point that there shouldn't be further developments in 3.3.0. I believe it would be much better if it's polished enough to be released as a stable version. Once 3.3.0 becomes sufficiently stable, smaller changes can be added to it and after testing them, you can release it as 3.3.1 and so on.
As for the following part:
Quote from: Crimson Wizard on Mon 14/10/2013 17:30:48
I do not want to become paranoid from thinking that while I am working on a feature or a fix, someone else is doing the same (similar or other way).
I can totally understand that no one would like investing their time on something which is also being developed by another. As a solution to this problem, I think that there should be a thread created for that, titled:
I'm working on..... This thread should be kept
public. It'll give two advantages:
1. Engine/Editor Developers will know that they shouldn't work on a specific feature unless the developer who intended to work on that particular feature specifically asked them to do so.
2. Game Developers, upon reading that their wishes are going to be fulfilled, can sit back and relax whilst wishing Engine/Editor Developers a long and happy life.
Just my two rupees...
Quote from: Adeel S. Ahmed on Tue 15/10/2013 12:22:17
2. Game Developers, upon reading that their wishes are going to be fulfilled, can sit back and relax whilst wishing Engine/Editor Developers a long and happy life.
I like that one, hehe :cheesy:
I just want to jump in and say that I'm watching this thread (not that this information matters much, but I'm posting to keep it alive). I did a bit of work on the path-finding problems, but I did everything locally, unsure about the organization of the project. I had assumed that CW was the default project lead on the engine at this point. Is this correct? Besides CW and Monkey, is anyone else working on the engine?
-TBP
If I am the lead, then I am the lead de-facto, not de-jure (simply because I commit more) :).
JJS was working on making ports & improving compatibility with older games, but he is not commiting much lately (probably being busy?).
Regarding path-finding, the 3.3.0 is feature-freezed now (only fixing broken things and very minor additions), but we may start preparing improvements for the next version.
Since "develop" is separated too much by tonns of changes and will require more corrections and testing, it might be better to aim for 3.3.1, I think.
If you want to publish your changes for public test, consindering merging it with "official" branch later, I'd suggest you make a personal git repository (cloning from https://github.com/adventuregamestudio/ags), create a new branch, like "feature_pathfinding" or "fix_pathfinding" (etc), forking from current "release-3.3.0", and make commits there.
Then, we will discuss how to manage this further.
UPD: I keep forgetting, there's a much more simplier way: if you are editing the local copy of the repository, then you can create a patch. This way you won't have to create your personal repository on github, nor new branch.
I must write couple of normal posts with suggestions regarding further development (something I have in mind for a while), but for now just a couple of smaller notes.
The custom resolutions can't go in 3.3.1, because it's a larger change, and will take more time to polish, so normally I'd like to see it in "limits removing" 3.4.0. On other hand, it will require some time to make 3.4.0 cleaner and usable (also lots of testing), and some people already want to use custom resolutions, or, at least, custom display resolutions (if not the game ones), because players demand the games to be run with their native screen size. And at least one game dev wants to upgrade his recently released game to have this feature.
This is a dilemma... we might have an intermediate release between 3.3.0 and "limits removing" version. Or keep some "temporary" version with just the strictly features we need for running game on any res.
Other thing, there are few games made with Draconian Edition, and people cannot use engine ports to run these, because there are incompatible script functions. Since most (or all) of these functions are good ones, we may consider plan a 3.3.1 release which will not only have fixes to 3.3.0 (if necessary), but also improves compatibility with Draconian Edition.
I think the simple solution is to give a 3.4.0 beta version that allows for custom resolutions, or alternatively put custom resolutions in 3.4.0 and rename the 'limits removing' to 3.5.0. I agree that these are major changes that don't belong in a 3.3.1 build. However, I should also point out that although removing limits is a good development, few designers urgently need it because the limits are pretty high already. $.02
Perhaps I am not giving a clear picture on this situation... the version number is not a big deal. More importantly, the branch that contains limits removal also has more code cleaned up and some things improved, and I'd hate to not use it any longer.
Then I suggest to work from that. I'm curious how many people urgently need a custom resolution build, anyway.
My impression is that custom resolution is the hardest problem and potentially most distracting so I would put that into a feature branch and everything else (limit removal and cleanup, Draconian changes) in the develop branch. The current custom resolution build based on 3.3 is usable right? So people could use that or the custom resolution feature branch (that could be regularly rebased on develop).
Quote from: BigMc on Sat 04/01/2014 17:27:57
My impression is that custom resolution is the hardest problem and potentially most distracting so I would put that into a feature branch and everything else (limit removal and cleanup, Draconian changes) in the develop branch. The current custom resolution build based on 3.3 is usable right? So people could use that or the custom resolution feature branch (that could be regularly rebased on develop).
Speaking just for myself, I'm currently using the custom res build (1600x900). It would be cool if we could get the limit removal+cleanup+draconian with a very basic version of the custom res in a very "temp build" for now and I'd be real happy...is that even possible?
If not, I guess I could always revert all the changes Ive made since using the new res build back to fit my old res of 1024x768 temporarily.
Quote from: Crimson Wizard on Tue 19/11/2013 11:58:25
JJS was working on making ports & improving compatibility with older games, but he is not commiting much lately (probably being busy?).
As for the ports to iOS and Android... The interface which interacts with the OS and the engine only needs some minor work done which M.M. and Wadjet Eyes seems to have achieved already with their version of games. In fact M.M. has sent me his Android code and hopefully I can make heads or tales of how to make it work officially in AGS. With iOS, I am not very familiar with that. Perhaps Janet C can shed some light on that area as they have with Mac and Linux. The bigger issue with the ports are the C++ side of things. I think JJS set the groundwork up for that and with beta testers, ports are very much possible to do. With Android, with every release I can test a game or feature in particular and report back to you if you would like and see if we can trace the bugs together on that end. And I am sure you will have more than a few willing to do the same with the other OS. But unless JJS decides to come back to working on the ports and adding more OS to the list, or if someone else is willing to work on the ports, this would be the best we can do with that.
Also CW, I remember hearing you were working privately on porting AGS to Allegro 5, not sure if that will break things rather than improve them, however, Allegro 5.1 does support Mac, Windows, Linux, iOS and Android and may break portability to PSP(Which I am not really sure if this benefits us much). The only other major port I would like to see is Windows Phone and support for Windows 8(I haven't tried a game on this yet, so there may be no issues anyway).
Quote from: Crimson Wizard on Sat 04/01/2014 00:52:11
The custom resolutions can't go in 3.3.1, because it's a larger change, and will take more time to polish, so normally I'd like to see it in "limits removing" 3.4.0. On other hand, it will require some time to make 3.4.0 cleaner and usable (also lots of testing), and some people already want to use custom resolutions, or, at least, custom display resolutions (if not the game ones), because players demand the games to be run with their native screen size. And at least one game dev wants to upgrade his recently released game to have this feature.
This is a dilemma... we might have an intermediate release between 3.3.0 and "limits removing" version. Or keep some "temporary" version with just the strictly features we need for running game on any res.
Other thing, there are few games made with Draconian Edition, and people cannot use engine ports to run these, because there are incompatible script functions. Since most (or all) of these functions are good ones, we may consider plan a 3.3.1 release which will not only have fixes to 3.3.0 (if necessary), but also improves compatibility with Draconian Edition.
I personally would love to see what ever is in the Draconian edition merged with the current public release. That would be great. In my opinion, as to what comes next after 3.3.1 has all its bugs fixed is to start working in the custom resolutions. For me, the bigger thing would be the limits removed, but it seems that most suggestions are moving towards custom resolutions. But for some reason I feel that trying to get the custom resolutions implemented would cause AGS development to be prolonged further. Would it be easier to add more resolutions rather than a field for custom resolutions for the meantime? For instance, Knox is using 1600x900. Can we add that resolution to the list of resolutions instead of allowing a user to manually set custom resolution numbers? Would that make it less buggy and as a good temporary solution?
Also, are there any limits that can be removed or increased in the meantime as well that wont break anything in AGS(Before removing all the limits completely)?
Personally I feel the priority at this stage is in this order:
1. Bugs.
2. Portability
3. Custom/more resolutions
4. fewer limits
5. Internal implementations of AGS plugins (LUA, RainSnow, etc..) for further backwards compatibility.
6. New Features
7. Forward save game compatibility
8. Further backward game compatibility.
Just my thoughts.
I don't know if it's been done, but perhaps put together a survey where you poll the current userbase on what we want next. Highlight it properly as a big red bar at the top of the forums so no one misses it and make it very easy and fast to click through. Should give you a rough idea of what the masses would like the most. Not saying a majority vote always gives the correct path to take, but perhaps a general indication.
As long as I have a decently stable build that I can use at a 640x360 resolution (which I pretty much have now) I'll be happy :)
Quote from: David Ostman on Sun 05/01/2014 17:57:46
I don't know if it's been done, but perhaps put together a survey where you poll the current userbase on what we want next. Highlight it properly as a big red bar at the top of the forums so no one misses it and make it very easy and fast to click through. Should give you a rough idea of what the masses would like the most. Not saying a majority vote always gives the correct path to take, but perhaps a general indication.
This is something that is not related to the problem I am trying to solve right now. There's a bunch of barely connected features which are 50-75% ready, and I want to put them all together. As time passes and more things are added, it becomes more and more complicated, and also stupid, because I have some "advanced" code in "develop" branch that I wan't to use with new features, or I'd have to start copying same code around and make things even more tedious and ugly.
I don't think we should add big features before everything is joined, that's it.
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.
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.
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.
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?
Quote from: Gurok on Sat 08/02/2014 08:33:17
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?
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! :D
Quote from: Gurok on Sat 08/02/2014 10:23:41
Fix my sprite font rendering issue! :D
It's an engine fault! The plugin makes no distinction between normal guis and text windows.
Quote from: Gurok on Sat 08/02/2014 08:33:17
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.
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. :D
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. :D Yes, you can fuck up with git so you have to know how it works before you start using it.
Quote from: Joseph DiPerla on Sat 08/02/2014 03:54:27
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?
Quote from: Joseph DiPerla on Sat 08/02/2014 03:54:27
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.
Quote from: Joseph DiPerla on Sat 08/02/2014 03:54:27
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).
Quote from: Joseph DiPerla on Sat 08/02/2014 03:54:27
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.
Quote from: Joseph DiPerla on Sat 08/02/2014 03:54:27
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
Quote from: Joseph DiPerla on Sat 08/02/2014 03:54:27
One final question... Has anyone provided you with the source to their plugins since you made the request on the forums?
None.
Quote from: Joseph DiPerla on Sat 08/02/2014 03:54:27
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.
Quote from: Joseph DiPerla on Sat 08/02/2014 03:54:27
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.
Quote from: Joseph DiPerla on Sat 08/02/2014 03:54:27I 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.
Quote from: Wyz on Sat 08/02/2014 13:30:58
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.
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?
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).
Quote from: Monsieur OUXX on Sat 08/02/2014 16:07:30
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.
QuoteJoseph, 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.
Quote
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.
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.
Quote from: Monsieur OUXX on Sat 08/02/2014 16:19:04
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).