So, over the last year or so it has been becoming increasingly clear that I no longer have the time to maintain and improve AGS like I did back in the good old days.
I feel particularly guilty about the bug reports that are filed here in the Tech Forum but I no longer actually have time to go away and investigate them and fix them.
So I've been trying to work out what to do about this; and I'm still not totally sure what the right answer is.
I certainly don't want to just give up and say "AGS is cancelled", because that would be throwing away 10 years of hard work, and would betray everyone who's developing games here.
On the other hand, I can't continue to pretend that nothing has changed, because it's evident that new versions and patches just aren't being released within any sort of reasonable timescale any more.
So, what are the options?
Well, ideally I'd like to recruit an assistant, somebody to help with development of AGS. But it would probably be practically impossible to find anyone with the skills and dedication to do it (after all, it's my baby, so it would be very hard to find anyone else who would have the same level of dedication to it).
Another option is to open-source all the code, and hope that some sort of open source community takes over. But then I would completely lose control of it, and it's not certain that any open-source developers would want to continue developing it or taking it in the right direction anyway.
So considering the lack of any obvious way forward, my current thinking is this:
As a first step, open up the .NET source code of the AGS Editor.
Whilst ideally I would like to see AGS Editor enhancements done as plugins, I appreciate that the current plugin API doesn't provide all the functionality that would be needed for this. So preferably I'd like to see somebody take the editor and enhance the plugin API, so that plugins become more powerful and the need to actually modify the core editor code is reduced.
I would still have control of official AGS Editor versions and releases, but other people could go and add features and fix bugs, and then submit these code changes back to be incorporated into the core.
If this works out well, then go on and open up the majority of the AGS Engine source code. I'm still not sure what to do about the code that handles the AGS file formats, because opening that up would make decompilers very easy to write. But that's a small amount of code in the grand scheme of things, and something we can discuss later on.
So, I'm curious to hear your feedback. Would anybody actually want to make their own changes to the AGS Editor, if the code was available? Do you think this would work as a process going forward?
I'm surprised decompilers do not already exist for the file formats. Nothing's going to stop a committed cracker. Consider the effort it took, for example, to reverse-engineer the Z Machine (the Zip interpreter), or Ultima VII (or any of the others - projects like Exult and Pentagram). Frankly, you're probably just lucky.
And "completely lose control" with regards to open sourcing the project? I'm not sure Larry Wall, Guido van Rossum or Linus Torvalds would agree somewhat with you. Ultimately, how much control you'd want to exercise (or lose) depends on you. Not to mention that there are more options out there than the GPL or LGPL - MIT and its relative licenses, Zlib etc. And I'd be astonished if AGS would just wither away if you were to open source it (in whole or in part) - that could be taken as being pretty insulting towards the AGS community at large.
You may want to (if you've not already) look at Inform 7's current model, which does seem to be somewhat similar to what you're proposing at the moment.
I think CJ it totally on the money with his vision.
There is clearly the motivation to do things with the engine but its just too difficult to work around the engines quirks trying to do something that it relatively simple.
If a hardcore group of developers were given more intimate access to the engine in order to open the plugin interface and fix common gripes then I'm pretty confident that AGS would become infinitely more powerful very very quickly.
Whatever you decide, thanks for the time and commitment you put in AGS.
Well, if you opt for the open-source, once the rumor spreads I'm pretty sure there'll be enough programmers interested to keep the thing going, after all AGS is pretty estabilished by now.
- Alan
The fact that AGS is the product of a single vision is probably why I'm still using it. AGS is AGS, and going open source might lead to fractured development paths and subversion builds that split focus on, rather than unifying, the core program.
I've made the argument for plugins before, so working to improve and enhance the plugin API would be aces in my opinion.
Opening the editor source to a select few (we're not short of coders here, are we?) is something I would also support.
CJ, honestly, it's a bit early for April Fool's, don't you think? :=
I have a limited knowledge of C# as compared to other languages (namely, AGScript :P), but I would definitely be willing to commit a(n un)reasonable amount of time to continual development of AGS.
Regarding the issue of the engine code and AGS's file formats, wouldn't it be possible to keep those code snippets in one or more separate DLLs that could have exposed methods whilst not actually exposing the contents..? Then whoever was working with the engine's source could make improvements and just link to those DLLs as necessary for any of the proprietary file functions.
I think that opening up development of AGS will likely make it easier to see it evolve as the community's needs do, and in a more timely fashion. I mean no disrespect to the hard decade of work you've given here CJ, just simply that the fact that you have a life beyond AGS (*GASP!*) has probably played a major contributing role in the rate in which user suggestions are able to be implemented.
Anyway, whatever you decide is best, rest assured CJ that I'll be right there blindly following you. :D
Edit: In response to LimpingFish's post, I think that broadening the spectrum of the Editor Plugin API is probably one of the first points that should be addressed. I myself have had several ideas for editor enhancements that simply never came about because of limitations and restrictions in the API that were..difficult at best..to work around.
I'm not a programmer of any relevant caliber (I only know out of date coding practices), so take everything I say with a pinch of salt.
One engine that really benefitted (and bloomed) from open sourcing the code was OHRRPGCE (http://hamsterrepublic.com/ohrrpgce/Main_Page.html) - lots of things that community wanted were implemented in record time and it's still growing to this day. It's still the child of James Paige, and he takes an active role in it's development, but it's still leaps and bounds above what he could do alone. Open sourcing it merely made it easier for programmers to contribute. And that community is smaller than ours. AGS is established enough and with famous games enough that there a programmers willing to make it happen. Source ports to other platforms, for compatibility, for one, would be a major, major boon. I think the advantages of open sourcing vastly outweighs the disadvantages. Decompilers are the least of our concerns, when we could get so much in return for that risk being a little higher.
Open sourcing the editor code is a good step forward. I'd love for really old AGS engine versions to be open sourced, too, so more people can play them. There are plenty of gems that falter on new machines, and anyone who wants to make an AGS game isn't likely to use the versions that only have a DOS engine. (I know, DOSBOX, but isn't that a bandaid rather than a cure?)
I too, am afraid of the fragmentation of the core, since it'll mean only certain iterations get love, but you can still retain control of the trunk, and lots of cool stuff can be merged into it. (for instance, all the bugfixes and agreed features first.)
I appreciate all the hard work you've put into this thing, and it's one of the most amazing programs I have ever used (and cannot live without!). I think with the entire community's help, we can help it evolve together.
I sure don't want it to peter out and die. I want it to grow!
One of the reasons I like AGS so much is because its API is consistent and concise. It is flexible enough to do almost everything I want with just scripting. If I need a function that does not exist, I can add or extent existing. It also features a flexible plugin API that enables us to create whatever extension we could dream of.
A lot of editors out there are horribly bloated and/or have a chaotic naming convention in their API. Inconsistency often happens when a lot of people are working on a program and there isn't a strong figure that directs it.
This can also cause the program to become less concise when everything the user base request is bluntly added without putting it in perspective.
But this can be prevented by making an application that is like a swish army knife, it is small, strong, yet contains every tool needed, or a module based application with a small core which can be extended with just the functionality the user needs, each module with its own quirks. AGS is the swish army knife kind of type but on the other hand also supports plugins and modules.
I think separating the editor from the engine could be a good thing. It is time consuming with all the little request from the people that use it day to day, enough people around that are eager to automate a lot of things in it.
I like how I can also create editor hint when building plugins, thats really cool. But when separating the engine it might also be useful to separate editor and engine plugins.
Just some food for thought for those who are concerned that open-sourcing the editor would be a bad idea..
Java, PHP, MySQL, phpMyAdmin, Apache, Mozilla Firefox, GIMP, FreeBSD, OpenOffice, MediaWiki and more programs/software are all open-source projects. Some of these are among the most popular programs/software in their respective fields of computing.
..just sayin'. ::)
I think its a good idea to open-source the Editor if the alternative is no more AGS updates. Still, you should keep your hands directly in the mix somehow...perhaps at least by reviewing the user-made plugins to determine which get your stamp of approval and maybe in the process dole out some advice.
As long as there is some figurehead that decides what directions should be headed for, I see open-source as no issue.
With that said, there will be trying times ahead as soon as the creator passes on a project.
It's sounds to me like the reasonable tradeoff, and if you do indeed open source the editor, I probably will attempt to dedicate some time and support further development of it.
@Monkey_05_06:
Those projects are successful because of the commercial interests behind them.
e.g. php became popular because of 100k webshops and phpnuke spinoffs. Also it was the only good & free solution and ran on Linux.
[/uncited rants]
But with game engines that's a whole different story, there are a lot out there even offering dual licensing. I'm not sure that Dave, Vince or the JBurger would hire a freelancer to add certain functionality to the engine, because Indygaming makes them rich ;)
Also I think the editor is already in great shape - if something has to be open sourced, do it with the engine. That way AGS might get interesting for these hip and cool smartphone devs and could benefit from it.
But my real favourite would be that you'll find an assistant and keep it closed sources but controllable.
I think alot of people are assuming that 'open source' means that CJ is going to just punt it into the wilderness. It doesnt work like that.
CJ would still control the trunk but people could get hold of the source code and do one of two things:
a) make modifications and release their *own* game with that version of the engine.
In this case no one else knows or cares that the engine has been modified in some way.
or b) make modifications to the engine and *submit* the patch to CJ or whoever who then decides if it gets added to the main trunk.
The latter of these two scenarios simply means that the addition of this feature has been done by someone else and not CJ.
the programming conventions of AGS still need to be followed and if the patch doesnt conform to those conventions to his satisfaction then CJ simply doesnt accept the patch into the trunk.
I commend your realistic and honest approach to this difficult situation, CJ. I realize it's a tough decision, like allowing your teen daughter to go on her first date. Despite the metaphor turning out a bit creepier than intended, I am sure that all of her suitors here on the forums will be well mannered, treat her with the utmost respect and accept that "no" means no. ::)
Open source seems like the popular choice these days, and I've yet to see it fail in any epic fashion. Some open source projects do branch out, but mainly for the sake of diversity and portability, rarely in a way that creates feature redundancy or confusion in the user base. Though I would strongly suggest some sort of official or semi-official working group to help coordinate efforts and avoid contributors creating unnecessary compatibility issues.
It *will* take a lot of discussion and we're never going to end up agreeing entirely on how stuff should be implemented (not even discussing the priorities of implementation - I'm assuming here that engine features will be added first and foremost because the people doing it finds them useful themselves). But it would be nice to avoid any reinventing-the-wheel issues or second-guessing what others may have in the works.
Personally I don't have any reason to change the editor, so I'm crossing my fingers this first experimental release turns out well, so we can start extending the engine itself. I'll be honing my C# skills in the meantime ;)
All in all, great idea CJ, and the only viable future for our beloved engine.
If it came to it, I'd love to code additions to the plugin API, engine and anything else required to improve and update AGS as part of a group, just as long as I was only codemonkeying, so as to not use up my creative juices. :P
While I could probably only just manage it skills-wise at the moment, if my exponential increase in programming skills over the past few months means anything, I'm sure I'd have the skills to be of use within no time.
I'd like to thank CJ for all the work he has put in AGS himself, I think this is a nice direction forward in my honest opinion. I find that CJ will be there, but just as a director and not much of an actor (except like a guest star at points) a really good path. Mostly because lately there are rumors of him acquiring a REAL LIFE (GASP!).
I don't think AGS should go fully OS, and this is really the best decision here. All I have to ask is for people that create cool thanks, be legit enough to share with the rest of us, cause that's what CJ has been doing. ;)
Thanks AGAIN CJ (I know you're not leaving geez) for the great and inexplicably awesome amount of work put in AGS.
Thank you.
You know the best part of all this? Now CJ will finally get time to finish the original DemoQuest!
I heard someone dies at the end...
or someone gets an inventory item to take home with them.
Open source certainly doesn´t have to mean bloatware. I prefer to think possibilities. I think alot of indie game companies would appreciate being able to hire a coder to do the changes they need and possibly give back to the community, for example.
I think the way to go would be like the Blender Foundation, where the original programmer (Ton Roosendal) has stepped back from coding duties but still controls in great part the path that the program takes. Obviously Chris would have that role. It has worked well for them, and it could work just as well for AGS. There are a lot of gifted programmers in this community who has real love for this engine, and I have faith that they could contribute a lot of good stuff with their hands more free..
my 2c.
With regards to the AGS File Formats problem, the simple answer might be to never release this code - let someone else write a new game data file system and wire this into both the editor and the engine (assuming this opens up too). Older games would continue to be protected from decompilation, and with an enforced separation of the executable and game data it makes future 'pure' AGS engine ports all the more likely.
It reflects well on CJ that he's inclined to open things up rather than abandon AGS or let it stagnate. After ten plus years and thousands of hours of effort, that must be quite a difficult thing to do.
I don't have a lot of experience with AGS to date because of that life stuff so I don't feel qualified to comment, but I wholeheartedly want to see AGS continue and flourish (if only for all the projects I have on the backburner at the moment!)
Quote from: Calin Leafshade on Mon 18/10/2010 11:00:53
I think alot of people are assuming that 'open source' means that CJ is going to just punt it into the wilderness. It doesnt work like that.
CJ would still control the trunk but people could get hold of the source code and do one of two things:
a) make modifications and release their *own* game with that version of the engine.
In this case no one else knows or cares that the engine has been modified in some way.
or b) make modifications to the engine and *submit* the patch to CJ or whoever who then decides if it gets added to the main trunk.
The latter of these two scenarios simply means that the addition of this feature has been done by someone else and not CJ.
the programming conventions of AGS still need to be followed and if the patch doesnt conform to those conventions to his satisfaction then CJ simply doesnt accept the patch into the trunk.
If it actually works out like that rather than splintering off then i'm all for it, so long as CJ is happy with that approach. But, while I do like the collaboration and flexibility promised by OS projects - and i'm sure AGS would thrive with the coders in this community - I do also like the stability, consistency and trust worked into a piece of software with a dedicated author(s).
Whatever form it takes going forward, CJ and AGS have my full support, and I will try to contribute in what little way I can.
One teeny tiny point. I can tear open AAA multi-million dollar games and access their player models, sound effects, textures and everything. Trying to continue to protect the art and scripting that people made for their AGS games might not be something that needs to be a priority anymore? [or in the past?]
Well, this has always been your baby and I'm well aware of how difficult it is just to release the source on it, so instead of doing that why not something like this:
1. Form a panel similar to the ratings panel, made up of 6-7 senior AGSers that you trust with appropriate programming experience and interest.
a. This panel will basically provide 'source control' and work together to select fixes and improvements in some kind of order of importance and utility.
b. Each member will implement a fix/improvement with the awareness of the rest of the group and their support and assistance (as needed).
c. One member will be elected the mediator of the group for issues with settling on fixes/improvements (we could also open some of that up to public polls down the line).
d. CJ retains a 'chairman' type final say on any major improvements or changes to be made.
This could certainly be a solid first step before going completely open source. I know there are a lot of programmer vets on this site (myself included) who would be happy to apply a fix here or a feature there with oversight and assistance from the rest of the team. This keeps you in the loop and a good chunk of control in your hands and AGS in the hands of people you have chosen while at the same time providing for a quicker turn around on improvements. Obviously the risk of source leak is there, but with a smallish group it will be easier to find out who is responsible.
I take this as a cue for me to start expanding my teeny weeny knowledge of C#/Visual C++. ;D
If the editor plugin API is made more flexible, then there would be no need for people to write their own editors.
Where open sourcing the engine code is concerned, I don't think it as absolutely necessary (the idea of releasing the source code to a small group of dedicated developers makes more sense in my opinion).
I feel first an approach similar to the one suggested for the editor should be tried for the engine, i.e. first we should see if enhancing the engine API can eliminate the need for open sourcing it. (I'm saying this because the existing plugin API for the engine is already quite flexible.)
And as far as AGS file formats are concerned, I feel it would be better to move them into a separate DLL (as suggested by monkey_05_06), and also provide a separate API at the engine level for registering/replacing file formats, like the way we currently have for script funtions (e.g. RegisterScriptFunction).
And finally, a big thank you for creating this excellent editor/engine and maintaining/improving it singlehandedly for over a decade. :)
Whatever you decide, I know it will be for the best of AGS!!!
Spoiler
Give every man thine ear, but few thy voice:
Take each man's censure, but reserve thy judgment.
--William Shakespeare in Hamlet
Personally I can't see the harm in open source at all, as everybody says the resource file issue is simply a matter of accessing the data through a closed-source .dll (or whatever the format is on non-Windows platforms). To be honest I'm not even sure patching onto CJ's source code would be the most productive approach - though it's perhaps unfair to make such a statement without actually seeing the inner workings.
It would be a total waste not to take this great opportunity to make platform agnostic by default, including the plugin API, so I'm not sure how much the original code could be salvaged or if it would be worth the effort to convert the C++ to, say, C# instead of rewriting from scratch. Clarvalon has done such a great job with XAGE so it may seem a moot point, but I'd hate to see some great AGS schism where we're again stuck in a situation of choice between system compatibility and expandability (as was the case with 2.72 and 3.0+ for a long time - just ask Tolworthy ;)).
Quote from: MrColossal on Mon 18/10/2010 20:26:17
One teeny tiny point. I can tear open AAA multi-million dollar games and access their player models, sound effects, textures and everything. Trying to continue to protect the art and scripting that people made for their AGS games might not be something that needs to be a priority anymore? [or in the past?]
Tell me, has this happened with any of the other open source game engines? Wintermute? Sludge? Just curious, seems so simple to do, they way you put it..
Quote from: ProgZmax on Mon 18/10/2010 20:32:45
Well, this has always been your baby and I'm well aware of how difficult it is just to release the source on it, so instead of doing that why not something like this:
1. Form a panel similar to the ratings panel, made up of 6-7 senior AGSers that you trust with appropriate programming experience and interest.
ProgZ had me at panel -I think there should be a proliferation of panels! That way the community can take more ownership over itself. If you think about it, most of the following ideas have been taken up by individuals at one point or another, but many have sputtered through lack of "succession" schemes. The beauty of panels is that if an individual gets burnt-out there are other people around to carry on. Some ideas:
Ratings panel (existing)
Source Code panel (proposed)
Wiki panel
Manual panel
Demo game panel (existing/has existed, at least informally)
Recruitment panel (anyone else noticing declining newbie numbers in the stats?)
Training panel (creating web seminars/tutorials for best-practices, new features, gaps in documentation...)
Pimping panel (to promote AGS and AGS games around the net)
Mittens panel (facilitating organization)
Worship panel (keep CJ's cult going strong)
Newsletter panel
Death panel
Web Page panel
AGS Awards panel (maybe organizing, maybe acting as an academy to judge....)
Orphans panel (to find level-appropriate projects for interested members)
Arch panel (a panel to oversee the other panels and bring them to heel if power goes to their heads)
Yeah, some of the above are jokes, but seriously I've seen a lot of initiative in some of the above fields that simply can not be sustained by individuals alone over the long term. Also, the more that we can defray CJ's workload the more he will be able to devote his limited spare time to what he does best -ensuring AGS is the
awsmoest!
Baron and ProgZ, you have it down!
Also, even though you say that some of those proposed panels are jokes, I could see them all being useful, especially since AGS has suck a strong, close-knit family-like community.
Even the ones like the Death panel would be great! For example: has anyone seen JimReed in a while? he used to be very active, and then he suddenly disappeared...
I think he's gone off to visit Ashen.. ::)
Quote from: wonkyth on Tue 19/10/2010 03:33:58
Baron and ProgZ, you have it down!
Also, even though you say that some of those proposed panels are jokes, I could see them all being useful, especially since AGS has suck a strong, close-knit family-like community.
Even the ones like the Death panel would be great! For example: has anyone seen JimReed in a while? he used to be very active, and then he suddenly disappeared...
Don't hit that on me Wonkyth. :(
Hilarious post Baron. Can we have a Dualnames panel too?
Quote from: Dualnames on Tue 19/10/2010 04:06:56
Quote from: wonkyth on Tue 19/10/2010 03:33:58
Baron and ProgZ, you have it down!
Also, even though you say that some of those proposed panels are jokes, I could see them all being useful, especially since AGS has suck a strong, close-knit family-like community.
Even the ones like the Death panel would be great! For example: has anyone seen JimReed in a while? he used to be very active, and then he suddenly disappeared...
Don't hit that on me Wonkyth. :(
Hilarious post Baron. Can we have a Dualnames panel too?
No, but we'll need a Harg panel for sure.
Back on topic,
YAY OPENSOURCE!!!
First, I want to say, that I like very much the newest version of AGS. Whatever happen, I'll have this version of AGS and together with the wonderful modules and plugins (especially tween module) I can do what I like.
But I understand the need of development. And I think that the best thing to do in the situation is "open source", but with supervising of CJ. I'm afraid of possible "chaos" in AGS editor.
This is my opinion. Sorry about my strange english.
See what you think of what this guy is doing with his adventure development system, and the reasoning...
http://www.axeuk.com/blog/2010/10/18/quest-5-0-is-now-open-source/
Wow! There is a lot to think about here....
I don't mean to disparage anyone but I think it's important to keep this discussion rooted in reality if anything is to be achieved. Many of the above comments are a bit naive with regard to the magnitude and difficulties sure to be encountered via OS or in bringing assistants on board. For example these few things come immediately to mind. There are certainly other issues which would quickly surface.
- Coming up to speed on legacy code is tedious and boring
- CJ's singular dedication to AGS is irreplaceable
- Open source doesn't automatically solve everything
- :
I would suggest that AGS be opened up in stages rather all at once. This would make it easier to control and adjust the transition process (presumably by CJ. perhaps with input from the AGS community).
Perhaps a first step would be to open source the runtime. As mentioned above this would potentiality lead to ports to other platforms. The legacy resource file formats problem is either a non-problem or is easily resolved. There are already three people intimately familiar with that codebase (CJ, EvilTypeGuy, and Electroshocker) who would be able to mentor new developers. We would perhaps be able to attract the interest of the SCUMM project in making their engine capable of running AGS games? And who doesn't want to see an Android port so AGS games can run on all the other "PAD" computers soon to be on the market?
I suspect the relationship of the current AGS editor to the runtime is less modular than desirable to support multiple target platforms. So perhaps this could be the first non-CJ editor work to be
done? There are perhaps other editor development tasks CJ would like done that others would be able to undertake. This would allow some others to become familiar with the editor and CJ's design/coding practices. Under his mentorship they would become familiar with the editor code and would acquire CJ's vision.
This could the beginning of an open source editor that would avoid some of the pitfalls such as fragmentation, stagnation, etc..
Wow. This is sad to hear. But Chris, thanks so much for all the work you have done so far. The truth is though that I dont think you will be able to let go of this baby. You may not work on it as much as you would like, or maybe ever again. But the thought of handing this over to someone else must be killer. But rest assured you are a pioneer and a pillar when it comes to the world of Adventure Games. You have contributed more so that anyone else has in this world. You are one of the few reasons that Adventure Games are still alive today. For that, I and the rest of the forum members thank you.
With that said, I would like to suggest what I would do in this situation that you are in...
*Not release the source code. Instead, get a small team of coders that have worked on porting AGS Runtime to other platforms and others who have written great plugins and have them be a part of the AGS team of coders. This keeps it sort of Open Source, but not available to the public, yet this ensures new releases and ports to other OS's as well. This team can add new features, optimize AGS and fix bugs that will inevitably show up while at the same time CJ allowing you to do the same via a CVS system. If all progress is well documented, AGS can go on for quite a long time. Just thinking off the top of my head for good candidates for this: Electroshokker, Steve Mcrea, dkh, scotch, Scorpiorius, Abstauber, SSH, Besh, RickJ, etc.. For just some people I can think of that can take up the mantle of AGS team if they are so willing.
*I would open source the Editor completely, but remove the compiler aspects of it from the source code. Instead, I would create a whole new compiler that works as a runtime executable so that it stays in tact without being comprimised by would be hackers and allow others to edit the Editor.
* I would do one last Hoorah before going in these directions and release one more proper build of AGS with some minor new features, if possible. If not possible to release new features, what I would do at this point is then make sure to release a complete API for the AGS Runtime that would allow any user to create anytype of plugin for AGS runtime, allowing it to be in a sense, worked on to time indefinite without opening the source code. If AGS can be ported to other OS's, the plugins can then be recompiled into other platforms to work on those versions of AGS as well. One thing I would do though is remove all limits (GUI, Rooms, Items, etc...) as if this is not removed, the users will never have a %100 true ability to modify AGS with plugins only.
So essentially, all this allows you and a team to continue to develop and bugfix AGS at leisure without open sourcing it. It allows fully powerful and capable plugins to continue to add features and capabilities to the AGS engine. The editor would be open sourced without comprimising the compiler and everyone wins here. Just my two blue cups.
Joseph there are a number of cross platform plugin systems, QT (http://qt.nokia.com/products) being the one that comes instantly to mind. QT also has nice graphics, multimedia, network, web support, etc that could freely (as in beer) be taken advantages of if the runtime were to become open source. I am certain there are other possibilities equally attractive possibilities.
If the goal were to get AGS runtime ported to multiple platforms then open source would be the way to go about it, IMHO.
The compiler is irrelevant to the preservation of legacy resource files which seems to be your concern. As previous posters suggest a new compiler output could be created that would be open source. The legacy format could be supported by a closed source binary in the form of a DLL, static linked library, ect.
:o OMG, Very said to hear that, so the 15 Walking areas limitation will be last for Eternity. :'(
I second ProgZmax approach, i guess its a lot of work in the beginning for CJ,
but when the Panel is well attuned, this would be the best solution for all IMHO.
Quote from: Rocco on Wed 20/10/2010 12:25:01
:o OMG, Very said to hear that, so the 15 Walking areas limitation will be last for Eternity. :'(
I second ProgZmax approach, i guess its a lot of work in the beginning for CJ,
but when the Panel is well attuned, this would be the best solution for all IMHO.
The thing isn't dead yet, far from it. This thread is about the future of AGS.
I can't help but feel almost entirely responsible for this. I started the AGS 3.3 Wishlist (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=36284.0) to encourage some serious and responsible suggestions and while that was the case for some of it, the 23 page topic took-off beyond what I unwittingly thought would be a manageable amount of feedback for CJ to draw from. I know this decision was inevitable and CJ would naturally grow lethargic from the repetition of his release/feedback/improve/bugfix routine but I still feel indirectly responsible for 'seemingly' breaking CJ's spirit. :'(
The majority seem so quick to dismiss all the hard work involved with keeping AGS a proprietary format. As a long time AGS user, who really only started to get serious with it in the last 5 years, I remember - As much as I tried to fight it, I respect the old-day mindset of keeping AGS proprietary. I firmly respect the decisions made back then as I believe they were relevant then, and it remains a serious topic even today. Times have moved on, I see this, and I pushed for this, perhaps a little too boisterously if you read back through the history of my posts, however I am extremely proud to have eventually come through with an unconditional sense of honor for those responsible for holding our community together and backing the one man responsible for all of this. Thats you CJ!
The irony is clear: Even I now miss the old days and fear the new, but it is a brave new world for our community and I believe, have always believed, that we lot are responsible enough to slowly become familiar with an open source environment and I strongly agree with the fundamentals some of you have laid out. Here's looking at you, RickJ, Dualnames, Baron, ProgZ, Garage and Calin. I think you've all hit on some key points that sum up what I think needs to happen rather distinctly.
So, in the end I suppose I get my wish. But it comes with great humility and a strong appreciation for what some of us take so well for granted.
I stand by CJ and his elite community driving force, and insist that something so refined and precious deserves careful and steady planning. We MUST NOT rush 10 years of passion out into the wild. This whole thing must be prepared in such a way that its community remains faithful enough to carry the collective spirit of the past decade into whatever lies ahead in the next.
Forgive my omen-esque, WW2-era sentiment but may I leave you all with this:
Only through the window of history can insight into the mistakes of the future be seen.
May Adventure Game Studio live to see a new day in our hearts and on our hard disks! ;)
Cheers,
Paul (Sparky).
Now look what you have done! ;)
But seriously it is a delicate matter including a great resource and a tight community. I've only been around for two years but feel connected. For every other application I would to have shouted 'YAY opensource!', but this one includes a custom script language and API that are only this tight because they were handled with utter care.Further more AGS has evolved, it had ten year to find an interface that suits its purpose the most. The Hourgames prove that it can be used to create a adventure game in just an hour. Any careless development will break that beyond repair. At this point CJ has given me the trust AGS will also remain solid in the future, although I know opensource can be a success, I can't argue with my guts.
I hear two different scenarios: 'opensource it yay!' and 'we need a panel'.
Well I've come up with the ultimate compromise. Open source it but not completely, that means: release the source but not allow it to be redistributed without permission of CJ, maybe accompanied by a panel. Still allow people to modify it, compile it into a game and redistribute this, but if they want to add something to AGS it should have the CJ stamp of approval. They can make improvements and send them to a panel, who might change it a bit so it fits, or prefer it becomes a plugin. Furthermore because you don't allow it to be published without permission you can prevent it branches out and the quality of the program is in jeopardy.
I know all of this discussion is somewhat academic since CJ gets to choose what happens anyway but I don't really see the mechanism by which the shit will hit the fan.
So what if someone releases their own game with some crappy version of the engine? It has no bearing on the engine as a whole. People release crappy stuff with every engine/programming language/platform.
The trunk of the engine and the "official" version would still be controlled by CJ and official additions would still require his approval but the advantage of releasing it wholesale is that any flashes of genius from the community are not wasted by bureaucracy and the ruling of a panel. It gives an individual coder a chance to prove that their addition is worthy by virtue alone.
If the idea of that addition is sound but the implementation is not consistent then the panel/CJ are open to say so and provide guidelines to the coder in order to help them fix it.
If the idea is shitty to begin with then the panel/CJ merely has to say that the addition is not part of the vision but they are welcome to use it in their own games.
There would be no splintering of the vision because CJ would still control that vision.
Granted there is still the issue of reverse engineering a game but as MrC pointed out that is a problem with all games and always has been.
If I am missing something here please someone point it out to me.
While I agree that a panel would be more or less necessary to keep "Future AGS" (aka FAGS) consistent and structure development in an efficient manner, I don't see any real benefit in limiting source access. What exactly is it you fear will happen if AGS goes completely open source? Paint a worst case scenario if you wish - and please do give examples if you know of any other game engines, 3D renderers etc. that have somehow suffered by going open source.
Edit: Yeah, what Calin said while I was writing this :)
I'm going to mingle in this discussion...simply because I can. Anyway...I would applaud open-sourcing AGS.
Of course I can understand that companies would prefer a closed-sourced (propriety) file format to store their resources in (although that never stopped applications like SCUMM Revisited). But let's face it: even if the files get extracted you would still hold the copyrights. So the worst case scenario is that someone would be using them for a freeware fangame...
What I would find much more interesting, though, is that open-sourcing AGS would make it possible to implement it in ScummVM (something people have asked for every now and then over the last several years); thus removing the platform restrictions for the games...and even more so: providing ScummVM with a game development suite.
As for the fragmentation. As indicated earlier, that all depends on how things are organized. If you take ScummVM for example, there is a version for Palm HP WebOS. But it's not available from the ScummVM website because it's not official; simply because there hasn't been any (official) contact between the developers of ScummVM and this version. In the case of open-AGS things would be very much the same: everyone can compile and edit their own version (for whatever platform one wishes); but that doesn't make every version official.
The only thing that I'm doubtful about is whether C# as a language (and AGS's reliance on .NET) won't hinder future development at some point...and if so, whether the first step should be to have a small team rewrite the application for a more universal language.
Ps. when going open-source...should there be an open-AGS 2 and open-AGS 3? - Not that I care, but some might (since some still use AGS2.x).
I would like to add another point- if work and improvement on AGS would stop, completely stop, I would not really see that as "AGS dying".
AGS is already a very flexible, versatile and stable program. It offers everything and the kitchen sink for adventure game making. In it`s own right
it is the full package, and to be honest, the changes from 2.7-something to 3 were more about the editor itself than the scripting commands/functionality. Whatever you do, CJ, here´s one guy who thinks that you`ve already reached a level of perfection that is rarely found. Just wanted to say that.
I agree with making AGS open source for the reasons Calin mentioned. So long as CJ continues to maintain quality assurance by overseeing all of the features/fixes that get implemented into each "official" AGS build, the release process wouldn't really be any different than how it already works. This way, a panel of hand-picked assistants could implement additions that are approved by CJ, while at the same time, innovation emanating from beyond the panel would be given a chance to flourish (and the really good things could be considered for inclusion in the next official build).
I guess the main argument to be made is whether or not CJ actually feels comfortable releasing all of AGS's code to the masses. I recall him mentioning once that on a previous Open Source project someone tried to claim his work as their own. That may have some bearing on his decision.
Well, whatever approach is taken, the main workload will be lifted off CJ's shoulders while other people contribute to making frequently requested changes happen faster, as well as shrinking the bug tracker list down in size. Whatever decision is made, AGS will be on-track to getting things done in an efficient and timely manner, which is great. Thanks CJ for all the excellent work you've put into AGS over the years, and for being-forward minded in thinking about the best way to handle the engine's future so that we can all continue doing what we all enjoy. :)
PS. About commercial games and reverse engineering etc. I think the benefits of Open Source outweigh the risks. As others have mentioned, there's always someone who will find a way to crack, rip resources from, or copy your game if they really want to. If you make a commercial game, it's going to be uploaded to a plethora of torrent and rapidshare links within days regardless. There's little you can do about it, and this is arguably more damaging than someone simply being able to rip your resources (which they could already partially do with the printscreen key and Windows Sound Recorder anyway). At the end of the day, the large majority of people who buy games will buy them, and those who copy and hack them will always do that. You just want to stop casual pirates and hackers as much as possible. Doesn't really make sense to stifle AGS's improvement in an effort to prevent people from doing what a skilled hacker is already capable of.
I think CJ needs to modify his first post with a notice..this thread is becoming very repetetive:
HAI
CAN HAS STDIO?
I HAS A AGS ITZ A YARN
LOL AGS R "OPENSOURCE"
IZ AGS LIEK "OPENSOURCE"?
YARLY
IM IN YR FORUMZ BTW LOOP
IM IN YR THRED
VISIBLE "YAY OPINSORZ!!1"
VISIBLE "O NOES! OPINSORZ R T3H BAD!!"
VISIBLE "NO WAI!! OPINSORZ R T3H WIN!"
VISIBLE "LOOKIT..THIS HOW OPINSORZ WORK"
VISIBLE "OIC WAT U DID THAR"
BTW NO GTFO MEANZ NO END LOOP
IM OUTTA YR THRED
IM OUTTA YR FORUMZ
NOWAI
VISIBLE "CJ R T3H OWNAR OF AGS FOREVAR!!1"
VISIBLE "YAY! FTW!!"
KTHX
KTHXBAI
For those who don't understand programmatic logic or LOLSPEEK, the point is, CJ said he's considering open sourcing AGS. A few people got excited, and then a few people came along and told them they don't know what they're talking about and open source is the devil because it inherently and inevitably leads to splintering and slow, painful death of the project.
Following that a few people explained how open source works (CJ and/or a panel control "official" versions of AGS whilst anyone is free to write their own modifications for their own use and/or non-official distribution depending on the actual licensing).
After that everyone pretty much came back to the agreement and understanding that open source would allow AGS to move forward at a faster pace than CJ doing all the work by himself. Never to discount the dedicated, loving service he has granted all of us completely free of charge; rather, simply recognizing the fact that due to CJ having responsibilities, wants, and needs beyond the realm of developing the program he's put so much hard work into, he has earned a break.
I think a panel for official revisions would help alleviate even more of the workload from CJ's shoulders. He can continue to monitor and of course always have the final say in things, but he wouldn't have to bear the sole responsibility of every single suggestion that might come across the forums.
There is a danger associated in a panel of course. I personally look to Wikipedia as a perfect example of this. Wikipedia is supposed to be able to be edited by anyone, yet the "official" Wikipedians have today become a very elitist group who will reject modifications to meet their own arbitrary desires. Notoriety, for example, is something that I feel has absolutely no place in Wikipedia. If the information is verifiably accurate, what difference should it make if it's not as popular as another page?
The panel should be made up of people who understand where AGS has been, have a clear vision of where it's going, but yet are open to suggestions that might not have come from their own minds. Clearly no one can match CJ's dedication to the program he started in his mom's basement (citation needed :P) more than a decade ago, but there are plenty of members who are dedicated to the program. The members who have been around the forums for years, doing things to help further the community, like SSH, Steve McCrea, Electroshokker, and dkh as were mentioned.
These are the type of people we can count on, as a proposed panel, to keep AGS going where it needs to be going.
Surprising that, given CJ's clear antipathy to open source, that he does not appear to have considered the opposite option - going commercial.
So. If he did decide to, say, set up a Blue Cup Ltd. to develop and support AGS as a commercial product, how many of you would buy it?
I would buy every update when its released... Even though I havent made a game, I am determined to one day do so. Buying and paying for AGS will motivate me further. I am willing to pay around $30 to $60 and $25 for each upgrade.
Quote from: Joseph DiPerla on Wed 20/10/2010 18:27:28
I would buy every update when its released... Even though I havent made a game, I am determined to one day do so. Buying and paying for AGS will motivate me further. I am willing to pay around $30 to $60 and $25 for each upgrade.
I'll just move to other stuff. Me and most of the community.
Yeah, even though I would pay, I don't know about all the students and other poor people.
If AGS has to make money, I suggest selling a snob pro version that compiles games for smart phones :D
Quotethe worst case scenario is that someone would be using them for a freeware fangame
If this were to happen to me, from the perspective of a competent studio, I would find it difficult NOT to be somewhat flattered.
QuoteThe trunk of the engine and the "official" version would still be controlled by CJ and official additions would still require his approval but the advantage of releasing it wholesale is that any flashes of genius from the community are not wasted by bureaucracy and the ruling of a panel. It gives an individual coder a chance to prove that their addition is worthy by virtue alone.
If the idea of that addition is sound but the implementation is not consistent then the panel/CJ are open to say so and provide guidelines to the coder in order to help them fix it.
If the idea is shitty to begin with then the panel/CJ merely has to say that the addition is not part of the vision but they are welcome to use it in their own games.
Again you reiterate/refine exactly the steps I believe should be put in place to allow
free-er use of the engine. To for the very first time enable developers, right down to the individuals themselves, to take AGS home with them and make it work for them in a way that complements their project and indeed perhaps compliments the majority of us through the acceptance of that code through the main trunk. Again I think it's important for the community supporting AGS, with the few surefire expectations we hold to its tangibility, for there to still be an 'official' face on it. So I think the main trunk is extremely important for this.
Cheers,
Sparky.
Quote from: Alan v.Drake on Sun 17/10/2010 20:19:29
Well, if you opt for the open-source, once the rumor spreads I'm pretty sure there'll be enough programmers interested to keep the thing going, after all AGS is pretty estabilished by now.
- Alan
This happens a lot these days. Just slap something like the AGPL, LGPL, Apache or a BSD license on it, and the people that really love it will carry it on. As of right now, Google Wave's "Wave-in-a-Box" code initiative is being adopted into several corporate and open-source projects by Novell, VMWare, Red Hat, and a few other people with their hands heavy in FOSS development.
If anything, AGS has developed itself to a point of code maturity that I think it would take very little time at all for a community to wrap itself around. Go for it.
Quote from: Sslaxx on Wed 20/10/2010 17:47:18
Surprising that, given CJ's clear antipathy to open source, that he does not appear to have considered the opposite option - going commercial.
So. If he did decide to, say, set up a Blue Cup Ltd. to develop and support AGS as a commercial product, how many of you would buy it?
Quote from: Joseph DiPerla on Wed 20/10/2010 18:27:28
I would buy every update when its released... Even though I havent made a game, I am determined to one day do so. Buying and paying for AGS will motivate me further. I am willing to pay around $30 to $60 and $25 for each upgrade.
Quote from: abstauber on Wed 20/10/2010 18:57:17
Yeah, even though I would pay, I don't know about all the students and other poor people.
If AGS has to make money, I suggest selling a snob pro version that compiles games for smart phones :D
Clearly the appeal of AGS is its price ($0). I don't think you can argue that the community would be as strong or the amazing games made with it nearly so numerous if you had to pay at the gate. And if proliferating the genre and midwifing great adventure games into the world isn't the point of AGS, what is?
Having said that, the market potential for an "elite" version somewhere in the neighbourhood of $25-30 is probably sufficient to allow CJ to dedicate some work time (rather than leisure time) to AGS -pending the necessary flexibility in his current work arrangements, of course. It would be hard to quantify the market precisely but there are 103 WiPs commented on in the forums in the last 6 mo. and reasonably an equal or greater number of projects that are unadvertised by their developers. Add to that the folk that always mean to start a game or like to play around with the latest stuff and you might have a market of 300-400 per upgrade cycle. We're not talking huge money here, but enough to justify the time spent. Sexy upgrades (editor skins! Live in-editor chat!) may well increase the market.
A happy medium may invovle charging for new upgrades, but the upgrade version becomes free as soon as the next upgrade is released (and so on). That way we keep our wonderful community of starving artists and starving students (with software 6 mo. to a year out of date), while the more serious developers (and those artists and students who can exercise enough self-discipline not to go to the bar for one night and save the $25... ::) ) can play with the latest features. This scenario also motivates CJ with a small amount of additional income, possibly replacing part of his work-week. Heck, he could even get all capitalistic and farm-out some of the scripting grunt-work, leaving him with absolute control, more spare time, and of course all the money. Ah... the system works.
Are we yet on the war that was caused by AGS topic?
Why is everyone constantly saying random things expressing their fears and doubts, when CJ has actually told on his first post, exactly the direction he'll be somewhat taking?
We're all concerned about the course of actions CJ will take, but suggesting over imaginary things without actual actions happening is just really silly. Calm down, and take a walk on the wild side.
We're all here to support him and his actions. So for once let the man step down and do something that at this point we all rather agree is a positive step in AGS development.
I for one would pay for a license for this fine program, and I'm lucky if I have two pennies to rub together. A one-time fee of something like $30-60 USD for an entire version number (like 3.0-4.0) wouldn't kill anyone and most of the kids without money could ask for it as a Christmas/Hannukah/birthday/something gift. There will still be the people who whine and say they absolutely can't buy it and oh god what a sell out but ultimately if it going commercial then gives you, the buyer, an actual stock in the improvement of the product then I see no real losers here. I've never lamented buying Pro Motion twice(v5 and v6); Jan Zimmerman's a lovely fellow who not only made me an official tester but reviewed and committed several of my suggestions and bug reports to the final product. If you think about it, that CJ's been doing this for free for years is quite special, and while not unique, sets him apart from many creators. I know he's been almost as adamant about receiving payment as he has been about going open source, but if payment would induce him to be active again (ie, money is involved so it's not just a time sink now) then I'm all for it. If not, by all means ask a selection of agsers you trust to get together and carry on under your supervision and approval until/unless you feel comfortable just releasing the source altogether.
I'm actually for any of the three eventualities, but more importantly, I'm for the option CJ is most comfortable with himself. We all stand to come out winners either way, and if it does go commercial there will still be 3.2.0.103 plus all the plugins and mods for the people who won't or can't pay.
The appeal of AGS, for me, is not it's price. My appeal to AGS is that it's a solid program that can make adventure games (3rd person avatar games and other kinds of games) with a ton of good features, including code-completion, a feature that I've discovered is disappointingly rare in other (commercial) game makers.
Personally, I'm interested in the AGS whether it's completely open source, or completely commercial ($40-60), or maybe even some in between like a free non-commercial-use edition for hobbyists. While open source is nice, I've come across too many dead projects for me to love the idea. And while it's nice to get something for free, I totally think AGS is worth paying for, if that's what it takes to continue it's development. Not only that but I'd agree with Joseph DiPerla in that paying for something can be motivating. Not that making it commercial was an original option/suggestion but... I just like AGS and look forward to it's future.
Ultimately, though, I agree with ProgZmax, and am cool with whatever CJ feels good about.
visionmind
PS thanks for all your work CJ.
minor comment: open-source and commercial are not opposites. An application can be open-source while you still have to pay for - for example - the compiled version and/or support (and even the source-code doesn't have to be freely available to everyone). While it's not a route taken often for obvious reasons (which is why open-source is often synonymous to freeware) it's fully allowed within all open-source licenses (that I know of).
Anyway...would I pay for AGS? - If I were new here probably not. After lurking around here for several years quite possibly. On the other hand, there are a few thing that I would wish that might keep me from doing so. Would I buy it if this meant that I - as a registered user - could also download the source-code? - Quite likely. Was this a useful post? - Probably not.
I wouldnt buy AGS unless the source was made available or the plugin interface was improved manifold. I needs me some customisation!
Again, academic. I very much doubt CJ would make the engine commercial in any sense.
I would buy AGS. If it goes commercial, I'll buy it.
Just gotta say that I'd also be more than willing to pay for AGS updates, regardless of whether it'd be a once-off payment, or an ongoing subscription fee for each new version released.
In consideration of all the great free work CJ has done on AGS over the years, I'd actually feel better about reciprocating in a financial sense if this would enable him to keep working on engine improvements in a timely fashion as well as keeping it "closed source", if that's his preference.
But again, I'm good with whatever decision is made.
Even though I agree with Calin that this is purely academical, I would pay for it, despite very limited funds, as I believe this is a project that is worth supporting wherever it may go.
From the faqs:
Q: Why don't you want people to register?
A: I'm not in this to make money, I'm in this to do my bit to help revive the 2D adventure genre.
Q: Won't you at least accept a donation?
A: If a future situation was to leave me in financial hardship, I would consider accepting donations. However, for now, I have a full-time job and it's not an issue.
I'm sure time is a bigger issue than money here, so please start a poll for deciding whether to pay or not :P
Quote from: Dualnames on Thu 21/10/2010 01:22:00
Are we yet on the war that was caused by AGS topic?
Why is everyone constantly saying random things expressing their fears and doubts, when CJ has actually told on his first post, exactly the direction he'll be somewhat taking?
We're all concerned about the course of actions CJ will take, but suggesting over imaginary things without actual actions happening is just really silly. Calm down, and take a walk on the wild side.
We're all here to support him and his actions. So for once let the man step down and do something that at this point we all rather agree is a positive step in AGS development.
Ahem.
Can we stay on topic. Really.
This started from open-source to panels to commercial. So I'm starting the next part. Akira and AGS. Yes, akira the movie. The anime one.
Quote from: Dualnames on Thu 21/10/2010 13:24:24
Quote from: Dualnames on Thu 21/10/2010 01:22:00
Are we yet on the war that was caused by AGS topic?
Why is everyone constantly saying random things expressing their fears and doubts, when CJ has actually told on his first post, exactly the direction he'll be somewhat taking?
We're all concerned about the course of actions CJ will take, but suggesting over imaginary things without actual actions happening is just really silly. Calm down, and take a walk on the wild side.
We're all here to support him and his actions. So for once let the man step down and do something that at this point we all rather agree is a positive step in AGS development.
Ahem.
Can we stay on topic. Really.
This started from open-source to panels to commercial. So I'm starting the next part. Akira and AGS. Yes, akira the movie. The anime one.
The topic is the future of AGS. Discussion about what form AGS's development should take in the future - from open source to commercial - is therefore valid. This thread doesn't look like it's gone off-topic from here.
The topic isn't that. If you say the first topic Chris asks feedback on the course of action he's thinking. I mean yeah its fun to stray off, but we're missing a point.
I'm changing my opinion from "I would buy AGS. If it goes commercial, I'll buy it." to "I WANT AGS to go commercial. I'll buy it.".
I don't want AGS to go commercial, but I'd still buy it.
I don't want AGS to go commercial, and I won't buy it.
CJ: "So, over the last year or so it has been becoming increasingly clear that I no longer have the time to maintain and improve AGS"
The time is the problem... and when the time is a problem.. it's a real problem. In some cases the time problem can be solved with "giong commercial"...
Quote from: Harg on Thu 21/10/2010 14:53:52
CJ: "So, over the last year or so it has been becoming increasingly clear that I no longer have the time to maintain and improve AGS"
The time is the problem... and when the time is a problem.. it's a real problem. In some cases the time problem can be solved with "giong commercial"...
Unless you already have a fulltime job your satisfied with, and which pays more, which seems to be the case here.
Edit: I´d like to suggest a middle-road alternative. Appoint a panel and get them accustomed to the engine. Once Chris feels the engine is in good hands, then release the source code and invite others to contribute.
Quote from: Dux Bellorum on Thu 21/10/2010 15:22:04
Quote from: Harg on Thu 21/10/2010 14:53:52
CJ: "So, over the last year or so it has been becoming increasingly clear that I no longer have the time to maintain and improve AGS"
The time is the problem... and when the time is a problem.. it's a real problem. In some cases the time problem can be solved with "giong commercial"...
Unless you already have a fulltime job your satisfied with, and which pays more, which seems to be the case here.
I'm saying "in some cases"... cause I don't know the financial state of CJ...
Needs of the developer versus the needs of the community.
The developer is lacking time and motivation to continue to develop AGS as it is. Whatever course of action he wants to take has to take into consideration the existing community and the effects his decision will ultimately have upon it.
Assuming that AGS development as-was can no longer continue.
"AGS is cancelled" - one person (at least) appears to support this. While NWN1 and Morrowind have not been commercially sold or supported for several years now, they still have reasonably active communities. But the games are aging, and compatibility is increasingly an issue - Windows 7, for example, has known issues with both games. An AGS that is no longer developed or supported might not necessarily have the community to ensure its survival. And even if it does, eventually it will begin to hit the same issues older games are having with modern operating systems (as indeed it already has with the old DOS versions). Unlike AGS, Morrowind's file formats are at least well documented enough to allow at least one open source project to exist with the aim of allowing the game to be playable on modern/future OSes (and perhaps more). An OpenAGS on this basis could still be created though, but it would take more time to reverse-engineer the existing file formats. Either that, or (more likely) something else would take its place.
AGS as open-development (not open source) - Inform 7 broadly follows this model. It is still, ultimately, under the control of Graham Nelson (and the code for the compiler is closed source), but there are also a team of developers, working on the UIs (which are open source), standard libraries etc. This might be the best compromise concerning Chris's mistrust of open source licenses and loss of control. This would allow the community to be more broadly involved with the project. It might require decoupling of the compiler from the editor (to help allay Chris's concerns regarding file formats) if open-sourcing the editor was to be considered - this would have the side-effect of making the editor more cross-platform (with the proviso that Chris could or would supply (or allow to be supplied) compilers for those platforms).
AGS as open source - this would require careful planning with regards to licensing. It would have to be fairly conservative with regards to permissions granted, in order for Chris to retain overall control. A copyright assignment agreement might help allay any fears here. The file format issue would have to be addressed as well, perhaps even more importantly from Chris's perspective. The GPL might be considered by Chris to be too liberal in this regard - the LGPL might be acceptable. Any licensing along open source lines would have to take into account the licensing agreements for any third-party software or libraries used by AGS, and issues caused if they would need to be replaced. As with open development, this would allow the community to be more actively involved in AGS's development - perhaps more than Chris would like, as the issue of code forking would exist (although code forks are not necessarily bad, viz EGCS-versus-GCC, XFree-versus-XOrg etc).
AGS as commercial - this, along with AGS as open-development, appears to have the broadest support (at least in this thread). It also has the potential to damage the community the most - at least one person has indicated they would not use AGS if they had to pay for it. There may be a feeling of "second class citizen" if there are (older/more restricted) free versus (certain platforms available only via/newest version) commercial edition issues - certainly, any commercial issues would get the lions share of support/development. Depending on Chris's circumstances, this still may not fix the time issue (even if it would fix the motivation issue), although it might allow Chris the opportunity to hire paid developers - on the (very important) proviso that it would be financially viable to do so (or indeed, any of this).
After rereading Chris' original post, the most preferred option would be to have an assistant, which I'd agree probably isn't very feasible unless financial incentives were involved.
But in the spirit of that, as has already been suggested, I'd say the next best thing would be to release the code to a panel/group of dedicated programmers who are all motivated to move AGS forward. I'm not sure how realistic/feasible this is either, but spreading out the load in a controlled environment sounds like it would be the most similar to having a single assistant, without involving money. IE instead of recruiting one assistant with limited amount of time, recruiting multiple assistants with limited amounts of time.
In my opinion, I'd say that is the best way to go to best progress AGS with Chris' vision.
If it goes commercial, I can not buy it.because my country is boycott economic(Iran).
and we can't buy anything from internet.
CJ.please dont commerical for AGS.I Love AGS and this community.
AGS is excellent free software for me.I really dont want leave it..... :'(
@Visionmind: I have also went back and read the original post and agree with much of what you say.
To expand upon the "panel" and "controlled environment" a bit... I would characterize the panel as being made up of community volunteers rather than an elite selected group. The controlled environment would mean that CJ remains our fearless leader and mentor and that there is an orderly process by which contributions are included in the official release.
I would think the challenge is to bring enough people up to speed so that they would be able to help each other rather than depending upon CJ to answer everyone's questions. Someone asked "What negative is there with going whole hog open source?" and perhaps the answer is that if widely announced it would attract multitudes of developers with multitudes of questions, ideas, etc. A good problem to have in the long run but hardly a solution to CJ's current time problem.
A good question to ask is "Is the editor source code sufficently modular and organized so as to facillitate parallel development by multiple developers or would some refactoring be helpful and a good first step in this process?". How can AGS be seperated into relatively independent parts? For example, just to get an idea of what I'm talkling about, something along the lines of ...
- User Interface
- Language/Compiler
- Resource Handling
- File/Project management
- Runtime/Target Selection
IMHO, there would be no point to recruit mulitple developers if they are not able to work in parallel. At one point in time DemoQuest used a serial development model where one developer took the files, added their contribution, and then passed them on to the next developer. It's my understanding this didn't work out as well as hoped. So I think this ought to be the first order of business should this prcess go forward. This could be the first task taken on by the volunteer staff?
Hope this is helpful.
Whoah I just found out about this! I blame SSH's vacation and not updating the blog til know! (j/k <3 SSH)
Anyway, my two cents:
Well, you definitely have a few options out there. I'm certainly impressed that you've worked on this for 10 years on your own, with the help of quite a few running the community. There is an amount of great things from AGS that would benefit a community. I think one of the strongest points has been the very full-featured editor that comes with it. Opening up those tools would not only help them stay fresh, but it might help others with their game creation process too, beyond making adventure games (making tools is tedious for the rest of us... I'd be about borrowing them. :)
Fully opening up the engine could definitely lead to some great things:
- Current Mac runtime support
- New devices (pads, pods, phones... you know, that wave of the future stuff)
- More robust editors
- Better, faster, stronger
This could be an interesting phase for AGS, although a dangerous start, too. I'd say... have a simple plan. You could open up some of the portions of the engine as you mentioned and then keep the compilation of the scripts and assets your trade secret (similar to the Webkit project). You should also scout for some people you'd trust to help you keep AGS awesome or to a good vision. Maybe early development is slow, like just getting a flow for people just fixing bugs rather than adding features to the engine until you find the right people for the job, then the road for 4.0 can continue. Luckily I feel the engine for what it needs to do is pretty robust as it is, so you should take your time for the next step.
I would suggest you get some dedicated programmers to help you fix bugs and add features...and if you need money to get that done, start charging...or atleast accept donations to help pay for programmers? Id pay for AGS + updates...I love this program, and the community!
Just dont let it die :P
I have to agree with well all of you. I'd totally pay for AGS, and I'm sure that even donations would work great. Perhaps something bonus for people donating? Anyhow, what knox and Edmundito said.
Take AGS and make it:
Harder, Better, Faster, Stronger.
Quote from: general_knox on Fri 22/10/2010 05:42:55
or atleast accept donations to help pay for programmers?
You don't even need to charge for that. A lot of programmer are willing to help out for free; I know I would. Surely many of them don't have a lot of spare time, but then they could still do bug fixes or adding small features, or when the engine can be divided into modules: even that. That is exactly where rainy Sundays are good for. ;D
But back on topic, I guess Sslaxx summed it up quite good. Those are the possibilities and it is really up to CJ to decide what he thinks is best.
When opening the code: have a look at the PHP license (http://www.php.net/license/3_01.txt) or when opening it up completely the MIT license (http://www.opensource.org/licenses/mit-license.php).
As a hippie (or hipster?), I'm all about fully openness... that is the MIT license and Git SCM/GitHub the project. I know. Crazy. Not really suggesting that route, but I'd dig it if it went that way.
Does this mean Linux in the future? Dum Dum Duuuuuuuum. ;)
I would also like to go along and point to the really important aspect of native editors for the top three platforms:
For once, rather than just trying to write code to replace Windows plugins, we could end up using native libraries of each platform to create plugins that extend the functionality of the game itself. Hypothetically, what do I mean?
Let's take a look at the Gnome Zeitgeist project. It's a file-logging daemon that, when applied to an app such as Gnome-Activity-Journal, will list what you did and when. A hypothetical AGS plugin that pipes into Zeitgeist APIs could set flags throughout a game that would count as achievements of some sort. This isn't in and of itself important to the game itself, but functionality could be extended across platforms to enhance what a native AGS game could do using API's already present in the desktop itself.
Of course, porting would take a little longer, but think about what else could be done. Rather than waiting for Chris to put in OpenGL support to be on par with AGS' DirectX video acceleration, suppose a Mac version of the game could plug into the CoreVideo suite to manage Coca-native 3D app acceleration.
If AGS were to go open source, many, many things could be achieved provided that a dedicated community could get behind it. I think if the engine itself were kept fairly stable and slow in development, and the rapid-development stuff would be mainly plugins that could be swapped in and out, you would nicely sidestep a fragmentation issue overall. After all, once you include a major feature change in the master repository, what would anyone that tries to fork the engine be able to do to get your features? If the break were big enough, they couldn't contribute upstream enough to break the overall implementation of AGS in and of itself, but perhaps their meddling might have at least turned up an unexpected bug.
Those are just some of my thoughts. It's really your engine, but really the FOSS community could use these kinds of tools, and the oncoming wave of many of the very ambitious game developers here.
Whoa. This is big news.
I personally would love to see the Editor opened. Mainly because Linux + Mac could do with a good Adventure Game tool, even though a port would probably take a while before showing up...
The engine being opened would also be cool (Do both of them use C#?)
If people are concerned about the ability to obtain content, then you could have that section of AGS still closed. I think the GPL is the only license that disallows that. Licenses like LGPL/ZLIB/MIT/BSD would allow for it.
I think some people here are thinking that it being open means that any random can make their own contribution and it has to show up in the official version on the main website. Which it doesn't.
But anyway. I look forward to seeing some Editor code sometime soon! If you decide to go for a small team of programmers instead, cool too!
To be honest, when I look at the changes I hope for, or even consider more or less necessary for AGS' continual growth as a tool and the engine's expansion onto other platforms, I'm beginning to wonder if that product would still be AGS in anything but name. The core design of the program is so firmly grounded in the adventure games of a certain era with rooms, characters, objects, hotspots, walkbehinds and so on, each with (sometimes arbitrary) limitations specific to their type. Of course stuff like this can be kept part of the default declarations to make transition easier, much like the current default GUI setup, but it would be shortsighted to treat them as anything but genre specific abstractions of a much more generalized system, and more importantly, to not allow user access to that base system.
My main reason for hanging on to a (hypothetical) future AGS rather than Wintermute 2.0 (whenever that comes out), or switching to a non-adventure specific engine, would be that I already know the scripting language. Yet thinking objectively, if the whole engine was rewritten wouldn't it make more sense to switch to an existing language like Lua or Python? Not only would it be easier for new user who already knew that language, but the skills learned while working in AGS could be transferred to professional game scripting. That kind of "universality" would also make it more attractive to use AGS in an education environment.
So I'm really on the fence here - on one hand I'm truly excited about the future of AGS as a community developed engine, and yet I'm in favor of changing pretty much every feature of it. At the same time can't help I wonder if there's any real consensus on a "vision", and I'mcurious what directions of development people have in mind.
In short, what do you perceive as the core of what makes AGS what it is? And how elastic are the boundaries of that identity?
I do understand what you mean here and I have thought something similar.
However there is alot of room to expand AGS, whilst keeping it an adventure game engine.
Let's think about this. The 'Adventure Game' hasn't changed that much in format over the years.
Monkey Island is not that much different to Vampyre Story or The Longest Journey.
They all have rooms, characters, objects, guis generated in much the same fashion but I'm sure we can agree that the feature sets of the SCUMM engine and the... modern ones, whatever they are.. are completely different.
so here is my list of things that could be improved.
2.5D support - this is a realistic way for indie games to be produced. You get the advantages of 3d lighting on characters without the need to model a full world
A Gui overhaul - The GUI system is *very* dated. I would suggest a more modular system which allows users (via the plugin system) to create their own user controls in the same way that WPF or WinForms works.
An updated sound system - The new audio system is a good start but there is so much more you could do. DSP on channels for instance
A pixel shader system - This could be implemented almost overnight if the source was open.
Updated font support - unicode support has been a long time coming.
More complete scripting language - Alot of things are missing which irk me on a daily basis. Classes, accessor functions, template classes, ternary statements, for loops, events.
Blending modes damnit: Alpha and Additiveplease
Dynamic Classes - What i mean here is being able to create characters and objects on the fly. The new object would then be added to the room's collection. something like:
Object obj = new Object([constructor values])
Polymorphism: This really fits in with a more complete scripting function but how cool would it be if you could make your own classes that derive from other classes like this:
Class Monster : Character
{
public Monster()
{
//constructor stuff
base();
}
public override Say(String what){
base.Say("ROOOARR!");
}
}
Being able to override functions like this would turn AGS in something really powerful.
Now I know what your thinking. All this sounds super complicated for the less techy users but its not really.
You could still maintain the current features of AGS with some kind of main entry point 'Game' class. So besides a few format changes everything should be basically the same if you didnt want to use all this advanced stuff.
Meh, theres probably more but i'm bored of writing now.
I have to agree with Calin, with a few augmentations on the existing scripting language it should stand to time without problems (I know that these augmentation require the lexer to be completely rewritten; add testing and implementation; they are HUGE tasks.)
I don't think AGS would ever need a functional programming (http://en.wikipedia.org/wiki/Functional_programming) language. Simple polymorphism like Calin proposes will do just as good. I would also add: passing structs as function parameters. (I can only assume this means big rewrites for the engine too) I'm just throwing it out there.
As for the other features: it would be really great if we could do stuff like that with just the plugin interface. Well, the sound system proposed by Calin and unicode support can already be done with plugins right now. So chop chop! ;)
About the cross platform thing: I want to state for any plugins I've made so far and all I will make in the future: I will guarantee they can be available for each platform AGS gets ported to if that were to happen. I will either port them myself or open it up to people so they can port it. If other plugin developers will make this guarantee I hope this takes away some of the worries people have about using plugins.
I really don't have much to add here, since I'm just a user and I am not much of a programmer per se. I've used AGS for almost 10 years now (!) and I've grown so used to it that I always hesitate before using something else. But, if I ever *do* use something else, the lack of portability would be the biggest one. The ability to natively run an AGS game on a Mac, or any other platform for that matter, would be a huge boon.
That said, I owe my livelihood to this little engine and no matter what happens I'm eternally grateful to CJ and the community here that made it happen. As someone in this thread said, AGS is currently near perfection already and I'll continue to use it for the time being.
-Dave
As another random, unrelated-but-sort-of-related snippet:
PyGame was ported to AmigaOS4 recently (http://amigaworld.net/modules/news/article.php?storyid=5593). Yes, the operating system still exists (http://en.wikipedia.org/wiki/AmigaOS_4) and is in active development. A recent computer (http://en.wikipedia.org/wiki/AmigaOne_X1000) with comparatively powerful specs is almost on the edge of coming to market.
This is all purely hypothetical, but the Amiga at one point was the hub for some of the best indie games around. Think about it. AGS games on the Amiga. :=
Quote from: Calin Leafshade on Sat 23/10/2010 12:02:22A pixel shader system - This could be implemented almost overnight if the source was open.
Yes, so long as it isn't
required. It might sound ridiculous, but my computer which was given to me by my old roommate does not have a graphics card that supports pixel shader 2.0. I don't know if it even supports such a graphics card as I..haven't really done anything enough that would force me to try and upgrade it.
Quote from: Calin Leafshade on Sat 23/10/2010 12:02:22More complete scripting language - Alot of things are missing which irk me on a daily basis. Classes, accessor functions, template classes, ternary statements, for loops, events.
I never really understood why there necessarily needed to be a distinction between a class and a struct. If structs were limited to POD types then that might be a different case, but AGS's struct type is a bit more flexible than that (I am completely disregarding the
supported functionality here in favor of what it can actually do..:D). I do agree that template classes would be AWESOME. I actually started to write an editor plugin to iterate the scripts in a pre-compile state and replace template definitions with appropriate struct types based on implementation..which..clearly, never got released.
For loops are nice as they allow their iterators to have their own scope. Ternary statements too can be very useful. These are fairly simple implementations which would make scripting a bit easier.
Events already exist within AGS though. AGS doesn't offer any form of delegates for dynamic linking of events (in that fashion) which is what I assume you mean, but we have events like game_start, on_event (the events therein), on_mouse_click, etc., as well as character-, object-, inventory-, hotspot-, GUI-, etc.-based events which can be used to call the functions you'd want to call at that time. Perhaps not as
elegant as a delegate, but still the same end result ultimately.
As far as accessor functions go (WARNING: More disregard of what is supported as possible in favor of what is possible), they're entirely possible in AGS. Using this example that I hijacked from Wikipedia:
// C#
public class Student
{
private string name;
public string Name
{
get
{
return name;
}
set
{
name = value;
}
}
}Translates in AGS to:
// AGS
struct Student {
protected String name; // field
import attribute String Name; // property
};
// NOTE: The following can appear in any script you want, however, the Name property cannot be used before these are defined
// AND the Name property cannot be used in THIS script
String get_Name(this Student*) { // getter
return this.name;
}
void set_Name(this Student*, String name) { // setter
this.name = name;
}
// NOTE: The getter and setter functions can be called in this script in lieu of accessing the property directlyFor indexers (arrays) the syntax is a bit different:
struct Student {
protected String name;
protected int classIDs[10]; // unique ID number for the student's registered classes; max 10 classes per student
import attribute String Name;
import attribute int ClassIDs[]; // note we CANNOT set a static size here, though AGS does not yet support dynamic arrays within structs
};
// ...
int geti_ClassIDs(this Student*, int index) { // getter with an array index
if ((index < 0) || (index >= 10)) AbortGame("Student.ClassIDs: specified index %d out of range, valid range 0..9", index);
return this.classIDs[index];
}
void seti_ClassIDs(this Student*, int index, int classID) { // setter with an array index; index comes before classID in parameter list
if ((index < 0) || (index >= 10)) AbortGame("Student.ClassIDs: specified index %d out of range, valid range 0..9", index);
this.classIDs[index] = classID;
}Of course this is not in any way
supported but due to its excessive internal use (every single property of every single built-in type is defined as an attribute), I'd say it's probably safe for use..for those who know what they're doing with it (though of course CJ would probably have to say to stop giving away trade secrets..:=).
Quote from: Calin Leafshade on Sat 23/10/2010 12:02:22Blending modes damnit: Alpha and Additiveplease
Dynamic Classes - What i mean here is being able to create characters and objects on the fly. The new object would then be added to the room's collection. something like:
Object obj = new Object([constructor values])
I can appreciate these two, though dynamic object creation is actually pretty complicated when you consider how much actually goes into an object's definition. In particular, for this we would
need some type of delegate in order to be able to create event functions for dynamically created objects.
Quote from: Calin Leafshade on Sat 23/10/2010 12:02:22Polymorphism: This really fits in with a more complete scripting function but how cool would it be if you could make your own classes that derive from other classes like this:
Class Monster : Character
{
public Monster()
{
//constructor stuff
base();
}
public override Say(String what){
base.Say("ROOOARR!");
}
}
Being able to override functions like this would turn AGS in something really powerful.
Which is also completely unsupported yet completely and totally possible! ::)
struct Monster extends Character {};
function Say(this Monster*, String what) {
Character *c = this;
c.Say("ROOOARR!");
}The problem with this is simply that none of the existing Character objects (cEgo, etc.) are defined as instances of the Monster type, and AGS does not provide a way to cast between types..except..as I showed when casting a derived type into a pointer of a base type. Since AGS doesn't allow pointers to custom struct types, this means that short of writing some sort of serialization and deserialization functions for your struct (I'm thinking along the lines of the Stack and List modules here), it is impossible to create polymorphic types derived from a custom type (that reference the base type's functions). (
Edit: By the way, this above example would actually cause "object not in managed pool" errors (derivate of "pointer cast failure" errors) if you ever called Monster::Say due to the fact that the internal Character object is not a managed character. You'd actually have to add the AsCharacter pointer I talk about below and use it in the polymorphically overridden function instead of casting a new pointer..and it would of course have to be initialized at some point or else you'd get a "null pointer reference".)
However, if you included some sort of AsCharacter pointer as part of your Monster struct definition then you could create an array (sadly due to AGS's limitations it must be statically sized :() of Monsters and use those instances anywhere you would use a Character (using the AsCharacter property when necessary).
Quote from: Calin Leafshade on Sat 23/10/2010 12:02:22Now I know what your thinking. All this sounds super complicated for the less techy users but its not really.
You could still maintain the current features of AGS with some kind of main entry point 'Game' class. So besides a few format changes everything should be basically the same if you didnt want to use all this advanced stuff.
Meh, theres probably more but i'm bored of writing now.
I wasn't planning on critiquing your entire post..ah well. 8) Anyway, this final point sounds to me like you're suggesting to move the AGScript language more toward a full OO language, which I'm fine with..though I know others find it more intuitive to state what they're doing before what they're doing it to.
In closing..don't any of you ever read the wiki (http://americangirlscouts.org/agswiki/Category:Advanced_Tutorials)? ::)
Enough talking though..more arguing how bad open source is. It makes me laugh.
Well I also have to agree with that, if only AGS had dynamic allocation of structs and arrays, and the ability to pass structs to functions then I could do everything I want for OO. Add ternary operators, for statement, switch statement and I'm a happy coder.
But let's continue making monkey laugh. ;)
I just want to say that CJ has done a great job with AGS, obviously. If he can't devote the same time and energy to it any more, that's unfortunate, but I think his proposal is a good one to ensure it continues to exist and move forward. I'd be in favor of ideally open-sourcing both the editor, compiler and engine, but that doesn't need to happen all at once, and the most important thing is to find a solution CJ and the community are comfortable with.
Keeping it all closed-source and handing it over to some new person/group doesn't sound like such a good idea to me, since it's impossible to guarantee in advance that whoever takes over will have what it takes (including spare time) to successfully maintain and develop the system. I would worry that some of the most talented candidates might be tempted to aim for a really ambitious update (viz. some of the suggestions in this thread) that takes years to develop -- like e.g. AGX and XAGE -- and eventually peters out without ever being delivered. This is the only scenario where I can realistically imagine AGS ceasing to exist.
Of the "big tasks" that handing over some of the AGS development to others might make easier to achieve, cross-platform support is obviously the most important one, and one I think is pretty realistic to hope for. To Calin's list of other desirables, I'd add better translation support (which relies on Unicode support to ever be particularly useful), and perhaps the resurrection of the "zero coding" point-and-click event creation system.
I would have bet diamonds on a response to my post from Monkey.
I was fully aware that some of what I said is technically possible but rather inelegant.
The implementation of accessor functions for example is, while functional, a code dump.
But yea, you summed it up in that I'd like AGS to be a full OO language.
It's already kind of halfway there and observes alot of the conventions of OO programming.
And like I said if you basically changed the GlobalScript to an entry point class then most average users would be none the wiser.
The main reason I think these changes would be beneficial is not due to what could be done for ones own game but rather due to the way it would make AGS much more expandable.
I think AGS should be more like a framework rather than just a program.
The editor then simply converts all the stuff defined there (characters, guis and stuff) into the necessary code to generate the classes. In fact I imagine this is already how its done.
And dynamic events could be simulated pretty effectively by essentially allowing the scripter to tie an event to an extender function like this:
Character C = new Character("Bob");
C.OnInteract += CharInteract;
void CharInteract(this Character*){
}
;D IMO the accessor functions aren't really that different than the C# variants with the exception that they're actually defined outside of the function. If you cut the commentation out altogether it's actually fewer lines than the C# example..if you don't count the braces then it's pretty comparable. But that's really semantics.
As for your ideas on dynamic event linking, I wouldn't mind using extenders as event functions, but like I said, it would require some type of delegate to be defined, which AGS doesn't currently have.
I didn't mean to contest what you were saying, but rather I was just providing examples of existing methodology in AGS that could be utilized to make the transition easier. Basically, why reinvent the wheel? Just create ties to the existing methods (i.e., adding formal support for custom attributes) and then we're good to go. I don't think AGS strictly needs C#-style encapsulation if attribute-encapsulation were formally supported.
I also think that perhaps a base keyword would improve the functionality of polymorphism on custom types (were it to become officially supported).
Beyond that, casting methods would not necessarily be a bad thing. For most non-basic types the cast would just return null anyway. The only point at which I can think of that it wouldn't return null is if you're casting, for example, a Character* back into a Monster instance where the Character* is in fact pointing to the Character object defined within a Monster instance.
Given those two things I think we'd have fully functional polymorphism. It would be very loosely defined in the sense that all functions would be essentially overrideable, but that could be addressed once polymorphism was fully implemented I think.
There's also a million other things that could be done to improve AGS on the scripting side that CJ simply hasn't had the time or resources to do himself. This is why I believe OS would be so beneficial. Even if it wasn't formally adopted into the official version, if I needed a specific functionality (say just for one particular game project) I could just write a custom engine for that game.
Doing this via the plugin API is something I also support, but I think that both the engine and editor APIs could be improved a lot by the move to OS, for exactly the same reasons.
The more I read this thread the more I hope it DOES go open source...people like Khris, Monkey, Calin, GarageGothic, Wyz, Tzachs, Abstauber, RyanTimothy (and many others) etc...could reaaally make AGS even more pwerful, which, in turn, would make better, more awesomer* games!
*awesome + awesome = awesomer:
http://www.youtube.com/watch?v=w355PoLomwE (http://www.youtube.com/watch?v=w355PoLomwE)
Quote from: Snarky on Sat 23/10/2010 17:07:32
I would worry that some of the most talented candidates might be tempted to aim for a really ambitious update (viz. some of the suggestions in this thread) that takes years to develop -- like e.g. AGX and XAGE -- and eventually peters out without ever being delivered.
Consider me sufficiently shamed into updating the neglected XAGE development blog (http://clarvalon.blogspot.com/2010/10/bumper-update.html). Progress is slower than I'd like, due to work and family commitments, but I'm still ploughing most of my free time into it.
From a purely selfish perspective, pure ports of the AGS engine to new platforms doesn't help me at all. But for the AGS userbase it would likely be the best possible outcome from opening up the source. Exciting times, regardless.
That's great clarvalon! I didn't mean to imply that XAGE (or AGX) will never be released, just that they're the kind of ambitious undertaking that will unavoidably take a pretty long time to complete.
Thanks for all your feedback, guys!
Just to be clear, AGS will
NOT be going commercial; the target market for a tool such as AGS is simply too small to make it a profitable business -- which is probably why there is no equivalent commercial product.
Based on the anonymous usage stats, I can tell you that AGS currently has 2260 active users. If AGS went commercial and charged $30, if we work with a generous assumption that 10% of people would buy it, that would bring in $6780. As a lump sum that would be enough to fund development for a few months, but the number of new registrations each month would be nowhere near enough to fund it as a business.
So let's just say, if I went on Dragon's Den and pitched BigBlueCup LTD, there would be only one response -- "I'm out"!!
So, what
are we going to do? Well, from your feedback it sounds like people are generally in favour of opening up the source code in some way, so I will prepare a release of the AGS Editor Source Code.
QuoteAGS as open-development (not open source) - Inform 7 broadly follows this model. It is still, ultimately, under the control of Graham Nelson (and the code for the compiler is closed source), but there are also a team of developers, working on the UIs (which are open source), standard libraries etc. This might be the best compromise concerning Chris's mistrust of open source licenses and loss of control. This would allow the community to be more broadly involved with the project.
Yes, this sounds good and is probably the license model I will choose.
Quote from: Pumaman on Sun 24/10/2010 20:26:06
Quote from: Sslaxx on Thu 21/10/2010 15:39:40AGS as open-development (not open source) - Inform 7 broadly follows this model. It is still, ultimately, under the control of Graham Nelson (and the code for the compiler is closed source), but there are also a team of developers, working on the UIs (which are open source), standard libraries etc. This might be the best compromise concerning Chris's mistrust of open source licenses and loss of control. This would allow the community to be more broadly involved with the project.
Yes, this sounds good and is probably the license model I will choose.
Would you decouple the compiler from the editor, in this case?
Quote from: Sslaxx on Sun 24/10/2010 20:34:22
Would you decouple the compiler from the editor, in this case?
Well, initially I'm planning to release the C# editor code, but not the source for the Native C++ DLL which the editor uses; and since the compiler is part of the native DLL, the source code to that won't be released, to start with anyway.
Quote from: Pumaman on Sun 24/10/2010 20:41:40
Well, initially I'm planning to release the C# editor code, but not the source for the Native C++ DLL which the editor uses; and since the compiler is part of the native DLL, the source code to that won't be released, to start with anyway.
I'm happy with whatever decision is made, so long as it assures the continued existence of AGS.
But if AGS becomes (semi) open source, will CJ hide his true middle name somewhere amidst those gazillion lines of code? Learning his true name may be the only thing that can avert the Mayan Apocalypse of 2012! ;)
- Ponch
I'm a little confused.
What use is the editor code if the compiler code is still closed?
because surely we cant actually change anything since the compiler still needs to understand what the editor does.
So we could rearrange editor controls and spruce up the editor but ultimately it wouldn't really improve AGS games in any way because the engine still needs to interpret the information in the same way.
Is that correct or am I misunderstanding the way the editor works?
The use of the editor code is pretty much the same as the editor plugin API..just with a lot..lot..lot more to it. It won't allow you to modify the way the engine (runtime) works, but there's a lot of functionality that could be added to the editor.
Even things in the script could potentially be handled by an editor code change. For example, you mentioned scripting templates. Just add a hook into the pre-compile game event to look through the scripts for defined templates and actual implications thereof, and create (on-the-fly) actual structures. So long as you could update the script in-memory after it is saved to disk during the compilation then you could make this viable.
Clearly this isn't as efficient for compile-time as actual scripting templates, but the point is that even the editor has the ability to change a lot of things. Take for example the fact that even with the new audio system, the speech system hasn't really changed at all. That too could be (to an extent) managed by modifications to the editor. In-editor displays of existing speech files, folder views for grouping, etc. could all be presented to the user, whilst ultimately providing the same end result for the compiled game as what already exists.
Quote from: Pumaman on Sun 24/10/2010 20:41:40
Quote from: Sslaxx on Sun 24/10/2010 20:34:22
Would you decouple the compiler from the editor, in this case?
Well, initially I'm planning to release the C# editor code, but not the source for the Native C++ DLL which the editor uses; and since the compiler is part of the native DLL, the source code to that won't be released, to start with anyway.
If you close source the native DLL wouldn't this be detrimental to using the editor on any other platform?
Quote from: Pumaman on Sun 24/10/2010 20:41:40
Well, initially I'm planning to release the C# editor code, but not the source for the Native C++ DLL which the editor uses; and since the compiler is part of the native DLL, the source code to that won't be released, to start with anyway.
I'm happy with whatever decision is made, so long as it assures the continued existence of AGS, and therefore Ponch can release his Barn Runner games (sorry I watched the awesome trailer again. And it was AWESOME!!)
EDIT: Man that trailer really makes it hard for me to keep me from drooling. :P
Quote from: Xenogia on Sun 24/10/2010 23:42:55If you close source the native DLL wouldn't this be detrimental to using the editor on any other platform?
I think the fact that in 10 years CJ has not once put forward an effort to making the editor portable to Mac/Linux stands to show that portability of the editor is not something he considers priority. It was designated as an available option for others if the whole thing were to go fully OS, but again, this was other people saying it, not CJ.
I'm not against portability, I think it's great. But the majority of end-users are ultimately on Windows PCs, so I think if a better, more powerful AGS can be produced in favor of a more portable AGS..I'd take the power. :=
Saying that..I for some reason just really want to post this picture right now:
(http://www.ultimatedisney.com/images/a-c/cdrrv1-04.jpg)
What picture?
It didn't appear for me first time either.
http://www.ultimatedisney.com/images/a-c/cdrrv1-04.jpg
But all in all realistically for the engine to improve you have to either open source it. Or give the code to a highly capable and motivated team of people.
Otherwise the whole thing would become more convulated than it needs to be.
Or worst case scenario the whole engine will cease to exist.
I dunno, I think even your modest 10% (6900?) figure is a great start for covering a full version number, but ultimately it's your choice. Personally, I'd see any money coming in as pure profit considering all the work you've put in so far, but if that doesn't make it worth it to you then that's that.
Opening up the editor is a good start, though. I reckon it wouldn't be difficult for me to alter room edit to display characters visually in the rooms and a few other tweaks I've been gunning for for awhile that I think would greatly improve the utility of the interface. We'll just have to wait and see as far as direct engine improvements go; hopefully at some point you'll at least open it up to a group of people you trust.
Fantastic decision Chris! The possibilities here stir great excitement in me.
I basically feel like I'm unmarried again, back in the garage eating chicken pretzels and watching pron! Yeaah! :=
Sparks.
I think totally opening the code would make AGS and the forums a mess. Now the step-by-step opening of the code, will get us all the cool things. I mean look at some modules and plugins that were created throughout the years and imagine what kind of plugins or modules were abandoned because of some parts of the editor that were prohibited to public use. I think this is a bold step for AGS
"One left-click for man, an executable application for humanity"
Quote from: Dualnames on Mon 25/10/2010 14:12:42
I think totally opening the code would make AGS and the forums a mess.
Gitirious (http://gitorious.org/). Problem solved. :=
But seriously, this is really cool. Lucky me, I'm learning C# and Mono bindings to GTK+, perhaps I could make use of a GTK# or Qt# AGS Editor some time in the future. :D
I don't see how open-sourcing an application will make it a mess. The GPLv3 license is as good as anything out there. And there non-profit legal firms for open source projects that specifically protect the programmers of said application from GPL violations.
gahgahgahgahgahgahgah GIT is a nightmare to use for Windows users.
All that crazy baffling nonsense about keys and putty and SSH.
:) I think going open source would help AGS grow. The alternative is gloomy!
I would like to see an easier interface for AGS
For example, the way it handles visuals right now can be time consuming.
(Is there a way AGS can utilize a directory(folder) with all the visual elements of the game while in production mode? Right now it keeps all sprites inside one file and are inaccessible outside of AGS for editing.)
I hope this game engine will one day be able to create games like this (easily) too:
(http://img408.imageshack.us/img408/3025/jissen.jpg)
Quote from: BatWitch on Mon 25/10/2010 23:25:52For example, the way it handles visuals right now can be time consuming. (Is there a way AGS can utilize a directory(folder) with all the visual elements of the game while in production mode? Right now it keeps all sprites inside one file and are inaccessible outside of AGS for editing.)
Seconded to the Nth degree - would also make it much easier to provide plugin support for other file formats (e.g. lossy image compression). Associations between Views, sprite numbers and relative image paths could be kept in an xml file or similar.
Quote from: BatWitch on Mon 25/10/2010 23:25:52
gahgahgahgahgahgahgah GIT is a nightmare to use for Windows users.
All that crazy baffling nonsense about keys and putty and SSH.
:) I think going open source would help AGS grow. The alternative is gloomy!
I would like to see an easier interface for AGS
For example, the way it handles visuals right now can be time consuming.
(Is there a way AGS can utilize a directory(folder) with all the visual elements of the game while in production mode? Right now it keeps all sprites inside one file and are inaccessible outside of AGS for editing.)
I hope this game engine will one day be able to create games like this (easily) too:
(http://img408.imageshack.us/img408/3025/jissen.jpg)
Is that Ren'Py BatWitch?
On a side note even the Wintermute source code can be downloaded and modified. And if it is good enough the creator forks it into the main engine. You just really need a project leader that looks over all the changes.
Quote from: GarageGothic on Mon 25/10/2010 23:39:35Seconded to the Nth degree - would also make it much easier to provide plugin support for other file formats (e.g. lossy image compression). Associations between Views, sprite numbers and relative image paths could be kept in an xml file or similar.
The associations you're talking about actually are already kept in XML in the Game.agf file. IIRC even the relative paths from the import are stored in place of what CJ described as a future "update sprite from source" option (I believe).
That was made in Visual Novelty (http://visualnovelty.com/). It is only in Beta right now, so it is a little unstable/crashy at times.
I wish that the scripting for AGS would become less programming-like too.
Maybe something a bit more English (newbie) friendly, such as:
AT inside_house
APPEAR from LEFT john_sad
John says "I wish I could go outside!"
REPLACE rainy_window sunny_window
John says "Hurray, it stopped raining!"
AT outside_house
Something like this would allow for longer games to be made too.
If you can make a list of commands and ways a visual novel coding works, I can make the equivalents in AGS. Trust me it can do anything. It now is programmed to wake me up and dress me.
I'm serious on the first part. ;)
Quote from: monkey_05_06 on Tue 26/10/2010 00:35:09The associations you're talking about actually are already kept in XML in the Game.agf file. IIRC even the relative paths from the import are stored in place of what CJ described as a future "update sprite from source" option (I believe).
Oh, I didn't realize this. I thought view, loop, frame assignations were part of the sprite .dat file for some reason. Then a custom resource file plugin along with an editor plugin to circumvent the sprite importer (and decode unsupported file formats to thumbnails) should do the job. Thanks for clarifying.
It would ultimately have to end up in the same place anyway, in the same format, for the compiler to be able to make use of it. However, if the editor source were opened up then it would presumably be possible to write functions to handle that.
Quote from: monkey_05_06 on Tue 26/10/2010 03:26:12
It would ultimately have to end up in the same place anyway, in the same format, for the compiler to be able to make use of it. However, if the editor source were opened up then it would presumably be possible to write functions to handle that.
Not necessarily the same format (and certainly not the same place if you by that mean the default sprite .dat file). A plugin can easily draw images in different formats to the viewport from a virtual folder structure in a resource file. Possibly it would be necessary to use custom animation functions, though - I haven't looked that far into the plugin API.
The huge benefit that comes from accessing images from individual files stems not just for the ability to use different formats (e.g. photographic backgrounds in PGF and cartoon characters in PNG or even vector formats like SVG) to limit file size, or make editing of imported files easier, but also can help portability to other platforms. E.g. store your art in a very high resolution and zero compression and have it resized and compressed upon compile - a lower res version for iPhone and Flash, a medium resolution/quality for free download, and a printed DVD collector's edition with super-high resolution for fans with the hardware to run it. Or if you prefer having full control of scaling filters and touch-ups, store alternate versions in subfolders or using an amended file name which will then be prioritized upon compile for that resolution.
I should explain that what I wanted to do with my plugin was to make AGS totally resolution independent by replacing AGS' screen rendering and use a virtual resolution property instead of fixed pixel width/heights. So in the above examples, whatever the image size they would all stretch to the allocated screen space and placed on screen coordinates scaled accordingly. At the moment there's no way to intercept viewport initialization from a plugin, so we're stuck with the limited resolutions AGS currently offers, but as soon as that's possible it will all make sense - at least for the non-pixel-artists :).
The reason I said that it would have to end up in the same place is because I'm assuming that the editor doesn't read back raw byte streams for the images at compile-time but that the compile step actually directly makes use of the built-in sprite storage, which is encoded differently than the regular image formats.
The editor can do whatever it wants, but at compile time if the resources aren't where the compiler expects them to be, in the format in which it expects it to be in..then it can't very well make use of the resources.
I'm not sure what methods might be exposed that might be able to avert this situation altogether, but short of the compiler feeding decoded image streams into the native C++ code I don't see how it's going to work.
True, the compiler would fail if I messed with the game.agf - so the editor would have to write image location and properties to a custom file instead. There'd still be an empty sprite file in the distribution folder, but that's pretty much it as far as compiler compatibility. Personally I don't really care about supporting the view editor if I have to write custom animation routines anyway (which would be for the better to avoid double caching), but of course some kind of integration with existing editor features would be necessary for a publicly released plugin.
Quote from: BatWitch on Tue 26/10/2010 00:45:42
I wish that the scripting for AGS would become less programming-like too.
Maybe something a bit more English (newbie) friendly,
INTERACTION EDITOR! :(
There was someone creating a plug-in, and then they basically just....left it. Who knows if it will be fixed up again now that the editor may possibly be opened up. Shouldn't the current OOPness make it EASIER? Like someone would select from CHARACTERS, OBJECTS, ROOMS, HOTSPOTS, etc. and then further select which instance of that thing they want, then they'd select a function (walk, changeroom, addinventory, etc, depending on what functionality is available for what they chose)... it could possibly even be completely automated!
People underestimate the greatness of the Interaction Editor...it REALLY made everything very simple for average AGS users (perhaps not the code-gods in here). BRING IT BACK! :(
I confess, I cant stand non-code programming, like that in Game Maker, it always seems so limiting and irritating at the same time. :-\
Part of the reason that plugin was abandoned is due to limitations in the editor plugin API which made things difficult at best to really get working properly. If the editor were opened up, that's one of the many things that could be added in more fully.
If the editor code is opened up, does this mean that 256 colour mode could be made a little easier to work with (More remapping options, like when importing GIF animations [they can't be imported exact palette, if I recall], viewing the room palette rather than having only one pane for a global palette, exporting backgrounds as indexed etc)? I know I'm probably the only person left on the planet who uses 256 colour mode, but still, it would be nice to have the workflow a little easier. I don't like having to wrestle with AGS for 8bit mode. :P
QuoteIf the editor were opened up, that's one of the many things that could be added in more fully.
Monkey's right. A refresh on the interaction editor could be assembled so that most of the current scripting language could have a click and drag front-end.
For example you might have a scene where you need your character to play an animation while he is speaking as the room scrolls to the left. This is relatively basic to set up in the script already, but I imagine this sort of thing (and more) would become quite trivial to the most basic user. 8)
Sparky.
QuoteWhat use is the editor code if the compiler code is still closed?
because surely we cant actually change anything since the compiler still needs to understand what the editor does.
What use would the compiler code be if the engine code is still closed? There's no point being able to change the compiler if you don't have the engine source code, since it wouldn't understand what your new compiler had produced.
As monkey_05_06 says, having the editor source code effectively extends the editor plugin API to allow you to do whatever you want within the editor.
QuoteIf you close source the native DLL wouldn't this be detrimental to using the editor on any other platform?
Personally I have no interest in seeing the editor on other platforms. The Mac/Linux voice always shouts very loud, but it is such a tiny proportion of real world users that in terms of the editor it's not something I think it's worth spending time on.
The engine is a different matter, and having Mac/Linux ports of the engine is a good thing so that the maximum number of people possible can play games that are created with AGS.
QuoteBut all in all realistically for the engine to improve you have to either open source it. Or give the code to a highly capable and motivated team of people.
As I have said, opening this editor code is a first step. It's an experiment to see if opening up AGS will lead to productive results, or just stagnate or make a mess.
If things go well, then I'll consider opening up the rest of the code too.
Quote from: Pumaman on Tue 26/10/2010 19:19:47
QuoteWhat use is the editor code if the compiler code is still closed?
because surely we cant actually change anything since the compiler still needs to understand what the editor does.
What use would the compiler code be if the engine code is still closed? There's no point being able to change the compiler if you don't have the engine source code, since it wouldn't understand what your new compiler had produced.
Fair point,
I actually look forward to sprucing up the gui editor! ^_^
Woohoo!
Exciting times ahead for sure=) Coders start up your engines and show Chris what a dedicated community can do!
Quote
Personally I have no interest in seeing the editor on other platforms. The Mac/Linux voice always shouts very loud, but it is such a tiny proportion of real world users that in terms of the editor it's not something I think it's worth spending time on.
The engine is a different matter, and having Mac/Linux ports of the engine is a good thing so that the maximum number of people possible can play games that are created with AGS.
I disagree. Do you think that Mac/Linux users only want to play AGS games and not create them themselves?
There're still methods to run the Windows Editor, like Wine and Parallels (or whatever solutions that I don't dare learn about), though whether the Editor could be run without any problems is another matter. Given the amount of work that may be involved in making native versions of the Editor to these platforms it's arguable on whether this is needed considering the user base of such platforms.
Also, as this is only the first step in open sourcing the AGS stuff it may still be possible to do such porting later, just not at the moment.
QuotePersonally I have no interest in seeing the editor on other platforms. The Mac/Linux voice always shouts very loud, but it is such a tiny proportion of real world users that in terms of the editor it's not something I think it's worth spending time on.
I think your underestimating the adoption value of would-be handheld developers. It's the chicken or the egg. If there's no chicken, there's no egg. CJ, sorry buddy, but your the chicken. :=
Sparky.
Quote from: Dualnames on Tue 26/10/2010 00:52:50
If you can make a list of commands and ways a visual novel coding works, I can make the equivalents in AGS. Trust me it can do anything. It now is programmed to wake me up and dress me.
I'm serious on the first part. ;)
;D I'll definitely hold you for that statement in the future when I am a bit more clear on what I need to get the job done. Right now I'm at a stage where I'm a little disorganized/tough to collaborate with.
Quote from: BatWitch on Thu 28/10/2010 01:04:05
Quote from: Dualnames on Tue 26/10/2010 00:52:50
If you can make a list of commands and ways a visual novel coding works, I can make the equivalents in AGS. Trust me it can do anything. It now is programmed to wake me up and dress me.
I'm serious on the first part. ;)
;D I'll definitely hold you for that statement in the future when I am a bit more clear on what I need to get the job done. Right now I'm at a stage where I'm a little disorganized/tough to collaborate with.
Why not just use Ren'py to create a visual novel??
Creating a imagemap (or any kind of interactive visual element) in renpy is quite dreadful.
I think that the way adventure games have things you can point and click is the way to go, rather than having everything as a menu choice. Having a main character who can walk around on a map (even if it's low resolution) is also a huge plus.
Quote from: Xenogia on Thu 28/10/2010 01:08:43
Why not just use Ren'py to create a visual novel??
Some people don't want to learn a new programming language to do that if they can just do it in AGS?
It's not a big fuss to create a "visual novel" module. In fact if getting AGS to work like a visual module, that means MORE CROWD, more JAPANESE, more chances I meet a Satsuki damn you!! ;)
Excellent work these past years, Chris.
I'm a fan of open source on principle, but I'm not much of a coder, so I don't have anything to add that hasn't already been said.
At any rate, I can't wait to see what sort of new functionality people are able to add using whatever code you end up releasing. It's rare I've found myself even theoretically limited by the current feature set, but I always get excited when I see lists of new functions.
This may be a bit "doom and gloom"ish, and I don't really think this shall become of AGS in particular buuutttttttt.
In my 5 years of Linux usage, hundreds of hours playing FOSS games. Joining Opensource communities and getting involved. Meeting the devs, and making friends with some. I've seen a few projects in their starting days.
And so far, the huge majority of opensource projects that ignore portability and being cross-platform, ESPECIALLY Linux support, have been failures. Due to lack of interest and support. AGS already has it's own interested and enthusiastic fan base, so it could easily not meet the same fate. But with most projects, the majority or entirety of the developer base are Linux users. Because many Linux users look for and take notice of opensource projects and support them because they emphasize and believe in the Copyleft movement. And most Linux users are extremely technical and proficient in programming. Every Linux user I know knows at least one programming language. But most know around 3-5. I use C/C++ and Python and Lua myself.
You can talk about total usage figures and how "Linux and Mac are an insignificant minority." How about considering maybe not how many computer users out there use Mac/Linux/BSD. Try thinking about how many of them would be likely to contribute and work on a highly technical project, for free, compared to Windows users.
EDIT:
Adding this because I feel I may have come across the wrong way. I'm not trying to say Linux is superior. Nor that it turns it's users into a race of superhumans. It's just people who like to program, like Linux's focus towards developers, and people who like the opensource movement and process, are drawn towards projects that follow it, like Linux and BSD.
QuoteI disagree. Do you think that Mac/Linux users only want to play AGS games and not create them themselves?
Of course there are some people that do want to do that. All I'm saying is that, with AGS having a user base of 2260 people, considering that 1% of desktops run Linux and 5% are Macs, a Linux port would only cater for 22 people and a Mac port for 113 people.
Therefore personally, I don't think it's worth spending time on (for example) a Linux port of the editor that only 22 people will use. You may well disagree.
QuoteI think your underestimating the adoption value of would-be handheld developers. It's the chicken or the egg.
I don't think handheld devices are really related to this debate -- nobody is going to try and run the AGS Editor on a handheld device. The actual games themselves, are another matter -- porting the engine is a worthy goal.
QuoteBut with most projects, the majority or entirety of the developer base are Linux users. Because many Linux users look for and take notice of opensource projects and support them because they emphasize and believe in the Copyleft movement. And most Linux users are extremely technical and proficient in programming. Every Linux user I know knows at least one programming language. But most know around 3-5. I use C/C++ and Python and Lua myself.
This is probably true.
I should just point out that I'm not opposed to somebody porting the editor code to Linux if they want to, I'm just trying to explain why it's not a big factor in my decisions surrounding the AGS source code releases.
Quote
This is probably true.
I should just point out that I'm not opposed to somebody porting the editor code to Linux if they want to, I'm just trying to explain why it's not a big factor in my decisions surrounding the AGS source code releases.
But wouldn't this be difficult with the fact the dll is closed off?
Quote from: Xenogia on Thu 28/10/2010 23:23:00
But wouldn't this be difficult with the fact the dll is closed off?
My understanding is that in theory one could swap in a new compiler for it if you absolutely had to. It's a shame that the Clang/LLVM compiler is currently a bit weak with C++, but it is a well-supported backend to compiling C# at the very least. So perhaps those would provide for a good starting point.
Quoteporting the engine is a worthy goal.
Oh dear, so sorry. I thought you were referring to the
whole kit and kaboodle.
Of course, I see no use for an editor on anything other than a PC(win/linux)/Mac but I am convinced that surely runtime support would be of some interest to us.
Cheers,
Sparky.
Quote from: Pumaman on Tue 26/10/2010 19:19:47
Personally I have no interest in seeing the editor on other platforms. The Mac/Linux voice always shouts very loud, but it is such a tiny proportion of real world users that in terms of the editor it's not something I think it's worth spending time on.
The engine is a different matter, and having Mac/Linux ports of the engine is a good thing so that the maximum number of people possible can play games that are created with AGS.
As a (switched to)Mac user, this is disheartening but understandable. While I would
love to see a Mac version of the Editor, I can appreciate it would be a massive undertaking. Anyway, it hasn't put me off AGS so far: It is THE choice for adventure game development IMO, both as a software package, and as a community.
I still have to use Windows for gaming anyway. At the very least though, I hope the Engine can be made cross platform so that the games themselves can be played easily on Mac/Linux. This is more than just an OS preference for me, it's an accessibility issue. I strongly believe games are for everyone, and I don't think OS/Hardware choices should get in the way of that.
Open sourcing some of the code is probably a positive move in this respect, but I would hope that any steps towards portability would be incorporated into the 'standard' version without being met by any kind of platform bias.
Again, I appreciate that portability is a big ask and, while I consider myself something of a coder, this is way out of my depth. I'm willing to wait for it and help out however I can. Anyway, thank you, Chris, for the huge amount of work you've put into AGS. I hope, with the community's efforts, it will continue to grow for a long time.
I don't think CJ is saying he doesn't ever want the editor to run on other platforms so much as he just doesn't think that it's as high of a priority as other things.
Quote from: monkey_05_06 on Fri 29/10/2010 18:49:59
I don't think CJ is saying he doesn't ever want the editor to run on other platforms so much as he just doesn't think that it's as high of a priority as other things.
Indeed so.
Quote from: Pumaman on Thu 28/10/2010 23:17:01I should just point out that I'm not opposed to somebody porting the editor code to Linux if they want to, I'm just trying to explain why it's not a big factor in my decisions surrounding the AGS source code releases.
Quote from: Pumaman on Thu 28/10/2010 23:17:01
QuoteI disagree. Do you think that Mac/Linux users only want to play AGS games and not create them themselves?
Of course there are some people that do want to do that. All I'm saying is that, with AGS having a user base of 2260 people, considering that 1% of desktops run Linux and 5% are Macs, a Linux port would only cater for 22 people and a Mac port for 113 people.
I think those figures might be slightly off due to business computers primarily being Windows XP or 7. And there are a lot of business computers in the world. I'm very doubtful people willingly buy Dell computers for personal use.
Also, with the Mac App store, there will be a lot of developer interest in making cross platform Windows/Mac games. If with opening the runtime code someone is able to produce a stable Mac release, you might find a lot more interest in AGS. And with that, someone will properly port to iPhone and Android. With that you have the potential to have a large number of sales of a commercial game.
I'd like to add that I am in agreement with Eric over the 'proprietary' format issues and the possibility of having a decompiler. This really hasn't been an issue for a long time in the games industry, what with most developers releasing their own tools.
I have to agree with Layabout. If I was able to compile a stable Mac executable (or a Linux executable, even) in AGS, I'd never bother using another engine ever again.
Yeah I agree with everything Dave Gilbert says. ¬¬
Actually I think it's fine the way it's done now to setup the mac/linux builds out of the windows build... no need for a specific mac or linux editor. I've done it with a few old 2.71-built games as a test and it isn't too much of a hassle. I think the bigger problem we've got in finding the right guy to make the mac version of the runtime... that's been the biggest issue all along. :\
I will say that the Mac community is very supportive of indie developers, game devs and otherwise. As someone who uses Windows, Mac, and Linux and who know several Mac users, my desires for stable executables for these other operating systems aligns with Layabout and Dave's.
Hello everyone,
This is my first post on these forums, please forgive me if this isn't the best place to post this. Here's my story:
I'm both an adventure games fan and a software developer. My main area of interest in game development is on the engine side, not that much on scripting. So, being a GNU/Linux user it was discouraging to see this great software piece (AGS) being closed source, which limited the platforms where I could play the games (I'm not that interested in the editor myself). I read a long time ago that Chris didn't want to open source AGS, so I thought the only option would be to write an engine reimplementation myself, and that's what I started to do a few weeks ago. Of course I haven't made lots of progress (AGS is really large), but I keep progressing every day.
But now I've read Chris' first post on this thread and it seems there's some possibility things are going to change:
Quote from: Pumaman on Sun 17/10/2010 19:17:16Another option is to open-source all the code, and hope that some sort of open source community takes over. But then I would completely lose control of it, and it's not certain that any open-source developers would want to continue developing it or taking it in the right direction anyway.
Quote from: Pumaman on Sun 17/10/2010 19:17:16If this works out well, then go on and open up the majority of the AGS Engine source code. I'm still not sure what to do about the code that handles the AGS file formats, because opening that up would make decompilers very easy to write. But that's a small amount of code in the grand scheme of things, and something we can discuss later on.
Things are starting to get interesting here. I support what Sslaxx said:
Quote from: Sslaxx on Sun 17/10/2010 19:34:19I'm surprised decompilers do not already exist for the file formats. Nothing's going to stop a committed cracker. Consider the effort it took, for example, to reverse-engineer the Z Machine (the Zip interpreter), or Ultima VII (or any of the others - projects like Exult and Pentagram). Frankly, you're probably just lucky.
I don't consider myself a cracker since I don't want to do anything wrong with the game data: I just want to be able to play those games wherever I want :)
Just to give you a rough idea:
- I decoded/decrypted CLIB volumes versions 0xA to 0x15 and extracted their contents. (I haven't looked into .VOX files yet, but I think they are pretty similar)
- I have decoded the sprite sets (versions 4 to 6, including the compressed sprites) and the sprite index (versions 1 and 2).
- Right now I'm working on the room formats, hotspots, interactions and soon I'll have to start with scripts, since these parts are very dependent on each other.
- I have decoded some simpler things like the .WFN fonts and .TRA translations.
All of this has been done in about 3 weeks looking exclusively freeware games using AGS versions 2.3 to 3.1.2.
So the only reasons for keeping this code closed is to "protect" the game assets and disallow script decompilers? Why? Just so people can't reuse the assets on a new game and players can't find the puzzles' solutions? I think common sense should tell anyone not to use someone else's work without permission (and the copyright laws say so), and looking at the disassembled scripts just to solve puzzles is like using walkthroughs... it takes the fun away from the game.
Here's my suggestion: Remove those artificial complications from the base file formats and define a plugin API to create custom encryption/decryption methods (an alternative could be plugins for custom input/output wrapping of data, so one could use password-protected standard ZIP files or whatever he wants).
With that, there would be no more reasons to keep any part of the engine closed and it could be ported to every platform (not depending on one person having access to that platform), by default every game would be available on every platform (and I think that's what most fans want), and companies selling their games or people just not caring about others being able to play their game on "strange" platforms could add any obscure system to make the data unreadable.
In fact, if the engine and the editor were completely open-sourced, everyone could modify it to their needs, adding their custom encryption as deep as they want into the engine, or even changing the file formats. It would remove the need for the additional "encryption plugins".
All in all, my point is that open-sourcing the whole engine wouldn't necessarily be bad for any type of user, and keeping any part of the engine closed prevents the main advantage (for users, players) of it being open source: portability.
I think I'm talking about a different matter here, though. I'm talking about maintainability of already made releases, not about development of new releases, new features, etc. I wouldn't mind about a small team being the only ones with access to the development code until a release is made if you want to keep control over the engine direction.
I'd like to get an answer about this, because my work would be a waste of time if you later decide to open everything. I hope we can collaborate from now on ;)
See you!
PS: Oh, and I'd REALLY love to see all possible versions open-sourced, not just the last one :D It would even be fun if the first release you open-source is 1.0 ;)
Well, VOX aren't even encrypted or I wouldn't have stripped out a mp3 from them, I guess the other formats aren't that hard to figure out. Heh.
- Alan
Ooh ohh! Here's something that would be very useful for those using voice speech.
Speex format integration! (http://www.myformatfactory.com/SPX)
Seriously, this stuff is like magic. It's an audio format specifically geared for voice speech. We used it for ECC and it turned 800mb of raw .wav files into about 30mb when we converted it to .spx format.
The downloadable for Blackwell Legacy was about 180MB, and only 30 of that was for the game. Being able to shrink the size of the audio would be a huge boon.
Quote from: Dave Gilbert on Tue 23/11/2010 21:56:44
Ooh ohh! Here's something that would be very useful for those using voice speech.
Speex format integration! (http://www.myformatfactory.com/SPX)
Seriously, this stuff is like magic. It's an audio format specifically geared for voice speech. We used it for ECC and it turned 800mb of raw .wav files into about 30mb when we converted it to .spx format.
The downloadable for Blackwell Legacy was about 180MB, and only 30 of that was for the game. Being able to shrink the size of the audio would be a huge boon.
What bitrate are you putting your speech at?
Looks to me like speex just applies a couple filters for noise/empty space reduction and then encodes the audio as a single VBR ogg, I'm guessing it saves a file somewhere that has the positions and names of each individual file as well. If so, AGS should be able to support this format with a plugin?
Quote from: ReAgs on Mon 22/11/2010 21:08:26
Quote from: Sslaxx on Sun 17/10/2010 19:34:19I'm surprised decompilers do not already exist for the file formats. Nothing's going to stop a committed cracker. Consider the effort it took, for example, to reverse-engineer the Z Machine (the Zip interpreter), or Ultima VII (or any of the others - projects like Exult and Pentagram). Frankly, you're probably just lucky.
I don't consider myself a cracker since I don't want to do anything wrong with the game data: I just want to be able to play those games wherever I want :)
Just to give you a rough idea:
- I decoded/decrypted CLIB volumes versions 0xA to 0x15 and extracted their contents. (I haven't looked into .VOX files yet, but I think they are pretty similar)
Actually after the feedback in this thread, the overwhelming opinion seems to be that it's better to be open-source and cross-platform than to protect the file formats, so I've now been persuaded that releasing the code wouldn't be a problem.
Quote from: Pumaman on Mon 03/01/2011 17:22:49
Actually after the feedback in this thread, the overwhelming opinion seems to be that it's better to be open-source and cross-platform than to protect the file formats, so I've now been persuaded that releasing the code wouldn't be a problem.
:D
(not the most useful comment, but it fits my feelings...love to see where things will go from here)
Wow, thats awesome CJ! This opens up many opportunities to improve AGS, port it and even give us c++ aspiring programmers something to learn from. Awesome. Thanks CJ!
I know I haven't yet played a role in adding any of these new features to the editor (although I have looked into it)..but I have mixed feelings about the engine becoming open-sourced now simply because I have been banned from using my development computer for as long as I am living with my parents..who are helping me get out of debt.
Bah, so it's selfish..but I have so many things I'd like to get my hands all over inside of AGS. ;D
Quotereleasing the code wouldn't be a problem
Dear CJ, I believe I speak on behalf of the AGS community to offer our
biggest thanks for taking such disciplinary care in reaching this decision.
Such a generally valuable piece of software could only be fractionally as valuable to its users than as to it's creator, so again the decision was an informed one with plenty of plan-ahead.
So congratulations! This is fantastic news on a shift in, I suppose the collective understanding of trust, that was years in the making. :)
Thanks, mate.
Quote from: Pumaman on Mon 03/01/2011 17:22:49
...I've now been persuaded that releasing the code wouldn't be a problem.
Wow, awesome to hear! I'm still knee-deep in writing the script for my game (progress!), but I look forward to someday being able to release it on many different platforms, and I'm personally much more concerned about that than about the game files being cracked. These are exciting times for AGS and adventure games. Good on you CJ!
Huzzah, that means eventually someone would be able to make a port to Amiga OS 4, and I could port all my games over to a seemingly mythical platform with ease. :=
That is amazing news, well and a bit scary, but that is always my first reaction to new things. ;)
Well, we still have to live up the test if we are worthy enough to mingle with the source, but the guys that worked on the editor source left a good impression. I haven't worked on the editor myself (I'm not very comfortable coding .net or editors in general), but I'd love to stick my head and hands in the engine source, first stop: checking how much work it would be to port it to different platforms. (did you know there is an allegro port for Amiga OS 4? ;)!)
Now the real beauty would be that the .ags files could go unchanged and only the engine binary needs to be specified for each platform. If people fear for decompression of these files you could still go for a static linked library that handles these files, but ohwell.
Anyway I second subspark's words!
Quote from: DeadSuperHero on Tue 04/01/2011 12:48:50
Huzzah, that means eventually someone would be able to make a port to Amiga OS 4, and I could port all my games over to a seemingly mythical platform with ease. :=
OMG! I'm not the only one!
I'm not a major open source proponent because I know how it feels to design things and want to protect them, but I also don't see a problem with going in that direction when you have a nice product and don't have the time to continue improving it. It's a great alternative to stagnation, especially if you get a good group of steady contributors making (even incremental) improvements. I've seen programs go from just mild functionality to being feature-rich in weeks with a good team and good source control.
I had been wondering what was going on with this. I was looking at the release history, and it's very regular, until about 2 years ago when it just stops.
I used to use a good old game development program called Megazeux. After the source code was released, the community took it, and really ran with it, developing it well beyond anything that was ever imagined. Today, it's still popular and in use (Despite the primitive ASCII graphics.), though there has been some drama with it's development. The centralized program fragmented into several development branches, and one particular developer got a little miffed when someone created a development branch based on the branch HE started.
Going open source can only be a good thing though, from what I have seen of this sort of thing. You've raised this little guy from a little DOS based program on a dream and a lot of elbow grease, and now it's all grown up and you are setting it free. I'm confident that you are doing the right thing. You'll be proud of what AGS becomes after this. Cracked game files will have a very minor negative impact compared to what the community is going to do with this thing.
/////
to be honest I dont think any of that will be a problem.
The whole FOSS thing is awesome and all but I really dont think that open sourcing the engine will result in a massive in flux of serious developers hoping to revolutionise the platform regardless of the technology it employs.
Open sourcing the engine will allow a very small number of developers (most of whom are probably already in the AGS community) to fix bugs and maybe add a few small new features. The plugin interface has been available for years and it hasn't been jumped upon to add new features really with a few exceptions.
It might seem pessimistic but I really don't think that open sourcing the engine will even result in ports. The amount of expertise and time it takes to create a full port of an engine that is heavily entrenched in windows is just too great for people to bother with. They may as well make their own engine for those platforms with cross-platform compatibility in mind to begin with (namely SLUDGE). The most likely outcome in that regard is that the scummVM people get hold of it and make an interpreter.
All that doesn't mean i dont want AGS open sourced. I definitely do even if it's just for educational purposes and the odd new feature but i think we have to be realistic about the likelihood of developers with the same level of skill as CJ getting involved en masse.
The irony of all that is is that so far, Microsoft has only made vague threats - it's Oracle (who own Java) that've been the aggressors. Patent issues regarding .NET (in particular Mono) might still well be an issue at the moment, but I say (as someone who has little love of Microsoft) that it seems the safer bet over Java right now.
As for the code:
There is a site for the SVN code for AGS, and people have already been contributing.
In short: look over recent postings and use the search function. This sort of thing has been asked about - and answered - several times over.
I think AGS is a very good adventure game editor, but it has one lack... It only runs on Windows: the AGS Editor needs .NET framework (Windows) and the games produced with AGS Editor are win32 specific (they use directly the Windows API).
So, there is a prime question for the AGS future... Which libraries should ags EDITOR and ags GAMES use?
AGS EDITOR: Qt4? GTK+? wxWidgets?
AGS GAMES produced with AGS EDITOR: I think SDL will be the best thing
The ags editor is built from the ground up in .NET. The chances of anyone taking the time to *completely rebuild it* are slim.
The engine itself uses allegro so porting it would be perfectly reasonable if someone was willing to do so since allegro is cross platform.
The D3D mode obviously uses directx but changing that to SDL would probably be (relatively) trivial.
////
If you want to protect your AGS files from being reverse engineered, why not use some sort of encryption where the editor allows you to assign a key to the game and encrypt the data files when the game executable is created? That way anyone can create a key that is unique to their game but only protects the end game files and not the editor files.
///
Quote from: timofonic on Tue 01/03/2011 00:59:53
Well, that's just an obfuscation way and also avoids using the games in a portable way. It could be better for users to find a multiplatform solution, based on encrypting the game files. It's a problem to the user, similar to other kinds of DRM
I wasn't talking about DRM which is meant to deal more with deterring theft of the game/media. I was talking about encryption of the data which would deter the average joe from reverse engineering your game. CJ had said in his original post that he didn't want to give out the file formats of the data files. I was just making a suggestions on how to allow the file format too be public but have a small amount of protection similar to using a proprietary file format.
An end user wouldn't even notice that the encryption is there. I'm also not sure what you are talking about when you said something about interfering with Multi-platform solutions. Perhaps I misunderstood but there are encryption algorithms that are platform independent and should work the same on all platforms. This isn't the same as DRM type algorithms which are more involved and can be platform specific depending on implementation.
[/////
It's like FLOSS only less useful for dental hygiene.
Tim, it seems to me that you seem to believe that if AGS were made to be full F/OSS-compliant that the entirety of the Linux/open-source community will suddenly flood to make AGS the single most powerful game development engine of all time ever.
The fallacy in this seems to me that they have not thus far shown strong interest in the engine (such as porting the engine to Linux, which has been done but has been maintained by dedicated individuals and not a huge community of developers), and that if that was really the end-goal of the open-source community as a whole, then why haven't they just written their own anyway?
Something you need to keep in mind is that for more than a decade this program has been exclusively programmed and maintained by Chris Jones. The only reason it is now being opened at all is because he has a life outside of the program, but does not want to see it be held back by his own inability to dedicate time to it due to other obligations. In essence, he is allowing us to get our grubby hands into his lovechild's life as an act of kindness, rather than having a strong inner desire to see AGS become a F/OSS-compliant project.
CJ understands well enough what open-sourcing means, but he wants to maintain a level of control over his project that certain licenses would not necessarily allow. His goal is to keep the project alive. The number of people who have already contributed to the editor, along with the number of script modules, templates, plugins, etc., and those who contribute freely of their own time to helping others in learning to use and make games with AGS, and so forth, should all go to show how AGS can be maintained by the community, while allowing CJ to have the final authoritative control that he deserves and expects after more than a decade of selflessly developing the program for anyone to use.
Well, too be fair, ScummVM have said they would definitely consider supporting AGS games if the file format was made open source.
Which certainly wouldn't be a bad thing, but historically speaking it's never been a priority of CJ's, and considering the number of people who have, and are currently still developing with AGS, I don't think that not having it is a real deterrent from the engine.
I'm not against F/OSS, I was just trying to explain that for the time being it's not the priority.
What ScummVM support gives you is instant cross-platform compatibility, which at least in my opinion would be a major bonus for AGS.
QuoteWell, too be fair, ScummVM have said they would definitely consider supporting AGS games if the file format was made open source.
This matters to me more than anything about the editor itself belonging to some particular license. Whatever is comfortable for CJ and whatever keeps the engine alive is good enough for me.
I left AGS after creating Keptosh and have never seriously approached another project with it. I love AGS, but I feel that with 10 years of no true cross platform support for games, I will never again use AGS. Of course, this breaks my heart, I love the community here. After 8 years of lurking around these forums with no intention of using the editor, I think it says a lot about the strength of the community. I want that back. I want to make games with AGS again. The one thing that would bring me back faster than anything would be ScummVM support (not that anyone wants me back :)).
I feel that the editor being cross platform or having a specific license outside of what Chris has already done is just silly. If you are a game developer and you are too lazy to run wine or VirtualBox, or better yet, just run it in Windows natively, then you are not serious about developing games with AGS.
Thanks,
-junc
///
Well herein lies the problem.
the whole reason that AGS is going open source is that CJ doesn't have the time anymore to maintain the engine to the level that he would like but running an open source community takes far more time than the current situation. So that would be counter-productive for his purposes.
Secondly the AGS engine is 10 years old. CJ knows it like the back of his hand i'm sure but *no one* else knows anything about the source AFAIK so no one else could effectively lead an FOSS community.
The fact of the matter is that it will take a while for people to get up to speed with the engine source code to a level that they could effectively manage a FOSS dev community.
I was essentially trying to point out what Calin just said with my prior post. I am not in any way against F/OSS. I'm a fan of it really.
That being said though, it's not like AGS could be converted into a F/OSS project overnight anyway. As you've already pointed out, both the editor and the engine alike have been engineered with Windows in mind. The number of users who have ever come here asking for support for other systems has always been relatively low.
That's not to say that there haven't been any, or that there might be some who simply haven't bothered since they knew of the low level of support for it. That being said though, CJ has always tried very valiantly to prioritize his efforts in developing AGS. If nobody says anything, or if at least he can't get a significant number of people to show genuine support, then why would he spend his time focusing on cross-platform compatibility in favour of improving the editor and engine as they currently stand with new features and bug fixes? It's simply not a practical endeavour.
CJ is not "hostile" toward open-source, he simply started developing the program himself and he enjoyed keeping it that way. Just because you create something doesn't mean you have to run around telling everyone exactly how you did it or else you're a greedy, selfish prat. For over a decade CJ willingly gave this program completely free of charge to the world. Wanting to have control over the source seems a reasonable trade-off to me.
As has been pointed out CJ is opening the source slowly because he wants to see AGS continue to develop rather than stagnate as his personal availability to commit time to the project has lessened in recent years.
Seeing as you're so committed to seeing AGS go fully F/OSS-compliant, my suggestion to you then would be to start making changes yourself. We here are not against the idea, again, it is only a matter of priority. If making AGS F/OSS is your primary priority in being here, then do so. As for the rest of us, we will put forward the effort that we deem necessary to helping AGS progress.
I wish you the best of luck in your efforts, and although I'm not likely going to commit myself to helping you rewrite the entire editor and engine from scratch, you do have my support in doing so. :=
Quote from: monkey_05_06 on Thu 03/03/2011 16:57:51That being said though, it's not like AGS could be converted into a F/OSS project overnight anyway. As you've already pointed out, both the editor and the engine alike have been engineered with Windows in mind. The number of users who have ever come here asking for support for other systems has always been relatively low.
You're conflating "open source" with "cross platform". The editor
was converted to open source overnight. Making it cross-platform, though, would be a much longer and very involved task. As for the engine, that we shall have to wait (and see) for.
Actually I'm not. I said "F/OSS" which actually implies quite a lot of things above and beyond simply having opened the source code.
/
Quote from: timofonic on Thu 03/03/2011 23:19:05But there are other options, like merging to a an already successful project with compatible or similar goals.
An example is ScummVM...
The problem with this line of thinking is that as soon as a project like AGS were to "merge" with another project, it immediately stops being AGS. The AGS community has developed into what it is because it is AGS. The AGS community is not the ScummVM community, and vice versa. That's not to say that we couldn't play nicely with them, but this community has their own unique history that is based around AGS, not some other project.
If AGS were merged into another project, then that history would be lost. I've not been a big part in the community myself outside of contributions here (modules, a couple templates, helping others, largely staying out of religious debates 8), etc.), but the AGS community actually extends beyond the realms of the Internet in the way of Mittens, Brittens, and all the other -ittens where AGS members actually meet up in real life for hang-outs and such.
Beyond that there's things like MAGS, OROW, RON, and others that all go to making this community what it is.
Compatibility with ScummVM would be great, I never intended to even suggest that it wasn't, but directly merging the projects would be detrimental to the AGS community.
In any case though, none of this is going anywhere until CJ decides to open the engine's source. From there we might be able to better consider what could be reasonably done to further the cross-platformability of the engine. As someone said, with regard to the editor itself, emulation options would be a reasonable route for those on other operating systems to take, IMO anyway.
Hi. I'm a linux user who just found out about the AGS being open-sourced, and I'm incredibly excited about the whole idea. I have in the past kept multiple outdated computers boxed up in my basement just so that I could play favorite games that are no longer natively supported. I realize that emulators can take care of almost all of that nowadays, but for the guarantee that a game will always be playable, nothing can beat running on an open-source engine (or virtual machine).
I've heard the possibility that the file format won't be open-sourced to make it harder to decompile people's games, and I've got some questions and an idea about that. Assuming that the rest of the engine gets open-sourced, how hard would it be for someone to write a program that simply grabs the data from in-memory, and writes it out in any format they want? I suppose only CJ knows the answer. Even without the engine being open-sourced, if no AGS decompiler currently exists, it seems like that's mostly because no determined hacker has decided to make one.
However, I do understand that people have put a lot of effort into games that they have released for AGS, and some are undoubtably worried about their game data becoming suddenly so easy to steal. So, here's a thought on a solution. Let AGS have a brand new open file format, but also allow AGS to read in the file through a binary plugin, or a binary callout program. Then AGS could provide a binary plugin to load files from the existing file format. This way, everyone who has written a game for AGS already will not have to worry about their game data being trivially accessible. And going forward people have a choice. They can distribute their game in a format that will be guaranteed to be playable everywhere, or they can distribute their game in a format that isn't so easy to decompile. Paranoid developers could even write their own encrypted file formats and binary plugins to read them, but if the API to read files changed in a future version of AGS, their games may become unplayable. Additionally, if there was a conversion program, the the creators of existing games could be contacted for their permission to convert their game to the new open format. If they agreed, then their game would be converted. If not, then it would remain only playable via the binary plugin.
I realize that I'm suggesting a bunch of development work that I don't plan to do myself, but I had the idea, and thought it would be worth sharing. In the end, I'm grateful that AGS exists at all, and also that it's going open-source.
QuoteIf you are a game developer and you are too lazy to run wine or VirtualBox, or better yet, just run it in Windows natively, then you are not serious about developing games with AGS.
Holy condemnations, Batman! I guess I'd better stop making games straightaway since I have no use for Wine or Linux! Better yet, I should go back in time to 2002 and stop myself from making my first ags game in windows since I couldn't have been serious about it back then, either.
Seriously, do you re-read what you write before you post?
Quoteor better yet, just run it in Windows natively,
Do *YOU* re-read the stuff you are replying to?
I think that the view might have been embellished a bit when that was first written, but to a degree I do agree with it. For the time being the editor is built on the .NET Framework, and it would be no simple task to remove that while maintaining the current editor as it is. I'm just being realistic when I say that.
Porting the engine and porting the editor do not have to be seen as mutually inclusive endeavours. Once the source for the engine is released (which is already written in native C++), then those who truly wish to do so can work on porting the engine to other systems and so forth. The editor being written in C# doesn't mean they can't port the engine successfully. If anyone ever does want to port the editor, the source for that is already out there, but in the mean-time, there's no practical reason that I can think of that would make running some form of emulation software out of the question. Sure, it may not be considered "optimal" or as user-friendly as a native editor port, but if you want to use AGS for making your game, then why would it be so bad to have to take an extra step to reaching that goal?
Quote from: timofonic on Thu 03/03/2011 23:19:05
/
Another weirdo who removes all his posts? Some people need to chill about being wrong.
Tim wasn't even wrong as such, he was just very very insistent on The Right Way To Do Open-Source (in his opinion). And ProgZ apparently misread or misunderstood the comment he responded to. To blank your own posts is such an annoying and immature way to react, though, it quite literally erases any merit your argument might have had in the first place.
I was talking about his dismissal of the value of porting it to other platforms, my comment about windows was just a--to borrow a user--snarky way of suggesting I shouldn't bother making games at all under such a draconian concept since someone could just as easily say 'well developing on anything other than Linux is a waste of time, or dos, etc'. Bear in mind that these 'emulated' ports tend to have compatibility issues as well so there's clearly merit in making actual cross-platform builds . Hell, I'd love being able to use the ags editor on a portable device and be able to test and share quick builds of a game, and I'm sure I'm not the only one. Also, I'm sure mac users would love regular, up-to-date builds of the editor. Sure it's work, but to call it silly?
Also, Calintroll is trolling.
Quote from: ProgZmax on Thu 10/03/2011 05:34:01
[Porting the Editor to other platforms]. Sure it's work, but to call it silly?
Well simply write a long list of correspondance between Java and .NET classes, and good luck to you! ;-)
(this is not a troll, this is not a critics, this is not an apology for Java, etc.)
Quote from: ProgZmax on Thu 10/03/2011 05:34:01
I was talking about his dismissal of the value of porting it to other platforms, my comment about windows was just a--to borrow a user--snarky way of suggesting I shouldn't bother making games at all under such a draconian concept since someone could just as easily say 'well developing on anything other than Linux is a waste of time, or dos, etc'.
OK; it came across as nonsensical though, since you were using your experience creating your games on Windows to refute his argument that people who are serious about making games can run Windows.
Sure, having the editor on multiple platforms would be nice, but I think (and seem to remember from earlier discussions that it was generally agreed) that it's a lower priority than getting the engine running on different platforms.
Quote from: Snarky on Thu 10/03/2011 11:25:51
having the editor on multiple platforms would be nice, but (...) that it's a lower priority than getting the engine running on different platforms.
+1
Maybe AGS would benefit from a true visual style editor.
Like for a particular room you could drag and drop the characters where they should start.
Maybe it could do a dry-run of what the character is to do.
Adventure Maker style highly modified still using scripting.
Just throwing out an idea here.
Maybe plan movements right in the editor with points in the room for the character to hit.
In AGS 3.2.1 you can visually position the characters' starting positions via the editor.
I noticed that there is no place to store videos in the editor.
I had to put them in the compiled sub-directory.
Maybe put it next right after sound on the right side of the editor.
I don't know if this has been mentioned before, but I would really like if AGS had better support for high resolution graphics. I sure understand the majority of people here make games in low res, and there is nothing wrong with that- as many great games have proved- but I think as developers we shouldn't have to compromise as it's often the case with anything 800x600 and above. I suppose it might be also a major turn-off for anyone wanting to use AGS to make commercial games.
My point is, that i REALLY love AGS and I think I finally managed to get my head around the scripting to do it on a decent level and I think it is a fantastic platform. But the way the sprites are handled is causing massive slowdowns and I often find myself cutting down on stuff because I simply can't expect everyone who plays my games to own a very powerful pc....
Is there no way to improve that? How is Wintermute dealing with this problem? I am no expert at these things but surely a better hardware acceleration would make everything run faster....
If it wasn't for the performance issues, I couldn't imagine myself ever needing another engine. But as it stands now... it's just so painfully slow sometimes it breaks my heart when I have to remove all those alpha channeled lights and cut out frames of animation....
Quote from: nimh on Mon 07/03/2011 23:16:39
I've heard the possibility that the file format won't be open-sourced to make it harder to decompile people's games, and I've got some questions and an idea about that.
I've already said that this is no longer an issue, I'm happy to release the full source code. I will do this once 3.2.1 has been formally released so that there is a stable code version to base the first release on.
Quote from: Grim on Sun 20/03/2011 21:06:32
My point is, that i REALLY love AGS and I think I finally managed to get my head around the scripting to do it on a decent level and I think it is a fantastic platform. But the way the sprites are handled is causing massive slowdowns and I often find myself cutting down on stuff because I simply can't expect everyone who plays my games to own a very powerful pc....
Is there no way to improve that? How is Wintermute dealing with this problem? I am no expert at these things but surely a better hardware acceleration would make everything run faster....
Is AGS significantly slower than any other engine at the same resolution with the same quantity of graphics, when running in D3D mode? I've seen occasional posts from people commenting on how slow AGS is, but is this actually a fact or are people just making assumptions?
If there is a significant performance problem then this is something that should be investigated and improved, but this has never been formally reported as a problem, as far as I know.
Quote from: Pumaman on Sun 20/03/2011 22:15:44
Quote from: Grim on Sun 20/03/2011 21:06:32
My point is, that i REALLY love AGS and I think I finally managed to get my head around the scripting to do it on a decent level and I think it is a fantastic platform. But the way the sprites are handled is causing massive slowdowns and I often find myself cutting down on stuff because I simply can't expect everyone who plays my games to own a very powerful pc....
Is there no way to improve that? How is Wintermute dealing with this problem? I am no expert at these things but surely a better hardware acceleration would make everything run faster....
Is AGS significantly slower than any other engine at the same resolution with the same quantity of graphics, when running in D3D mode? I've seen occasional posts from people commenting on how slow AGS is, but is this actually a fact or are people just making assumptions?
If there is a significant performance problem then this is something that should be investigated and improved, but this has never been formally reported as a problem, as far as I know.
I've only heard that other engines are faster and never really tried them myself... Perhaps I'm being unreasonable, but recently testing my game on my girlfriend's laptop (in D3D mode) some rooms that work great on my desktop were really choppy and slow. These were of course rooms with a large number of animated sprites in them. It's quite a good laptop, too- not top of the range maybe but not old crap either.
Anyway, it seems that a room a size of 2000x600 pixels with one large parallax object in the background, a same size layer of alpha channel light/shadow object, a rain animated object sized 1000x600 px, 2 characters, each 21 frames walking animation, and flopping curtains sized 200x500, and few small other objects caused a massive slowdown.
..
And now, that I've typed all that, I think I realize I'd probably gone beyond a reasonable amount of stuff that can be placed in one room........
But another issue is that D3D doesn't work on some computers. I remember Calin explaining it to me once... but I forgot what he said. Still, it would be great if it worked on 100% of machines.
Well the drawing surfaces are inherently slow because you are drawing on DD surfaces and then those surfaces are drawn into video memory.
AGS does draw regular sprites (characters, objects, etc) natively in D3D though so it shouldn't be particularly slow.
It would be nice if there was some way to kinda queue sprites on a surface for rendering via D3D. Things like particles and stuff which are currently essentially impossible at high resolutions.
Not sure how that would work logistically though.
Quote from: ProgZmax on Thu 10/03/2011 05:34:01
Also, I'm sure mac users would love regular, up-to-date builds of the editor. Sure it's work, but to call it silly?
I would love this! But as was already said by others, I would be happy even with a runtime engine for Mac. Just as long as either option is kept up-to-date with the main editor.
Does AGS support multiple cpu's?
Performance wouldn't be an issue if AGS was multitheaded.
Maybe someone could make the DirectX driver better, or add opengl support.
Or, improve the caching scheme...
Well, what AGS needs is to reduce the cross-compatibility stuff...
Maybe the too much crossing would make you drop dead at the other side of the road.
Almost majority of the people today are running their comps on the infamous Windows XP, Vista and 7. And some use macs, linux and ubuntu. Maybe there would be some kind of "Publish to..." menu that chooses what build of AGS would be compiled.
And it would be nice if it supports integrated graphics well too! I'm happy to beta test! I use the most infamous Vaio VGN-N320E with that infamous Intel 945GM. So if it works on mine, it might work on others. How bout that?
EDIT: On second thought maybe it's still nice to have crossing to older systems, but just to be safe, more on Win XP up.
Quote from: CRxTRDude on Mon 21/03/2011 14:10:48Well, what AGS needs is to reduce the cross-compatibility stuff...
Maybe the too much crossing would make you drop dead at the other side of the road.
I'm not sure if you're trying to be sarcastic here..but the rest of what you said seems to be very much in opposition to this. By "cross-compatibility" I guess you mean "cross-platform compatibility" which is directly indicative of the Mac/Linux ports of the engine. The engine ports are not fully up-to-date with the latest AGS, but Windows 98 has not been officially supported (by AGS) for quite a while (only XP and up are officially supported for running AGS).
And I'm not sure what you mean by "support[ing] integrated graphics".."integrated graphics" just means that your graphics card uses RAM for processing graphics data instead of using its own dedicated memory (such as an on-board graphics chip might do). This wouldn't affect whether or not AGS can run..it would just mean that AGS would probably be more resource-heavy on your system (because of your hardware). This isn't really something that can be dealt with very simply from a software aspect (if indeed at all).
Well, there are 2 things here, there is the editor and there is the engine..
for crossplatforming the editor you need to make sure the .NET code isn't going beyond what's possible with Mono OR you should change the code so it's silverlight based and doesn't go beyong what's possible with moonlight (which current builds already supports a lot of Silverlight 4 and already has multiplaform support (MacOS/Linux/iOS/Android), which would be enough to create a multiplatform editor).
On the engine side I would suggest at least incorperating it into ScummVM (which already has a very good reputation on commitment), and let them first get the old/current engines running multiplatform which will continue into the newer engines. I guess the ScummVM team won't mind having CJ as an overseeer for changes to new versions of the engine.. porting AGS to ScummVM will almost be the only way to keep AGS really multiplatform. Only problem with ScummVM for me is their unwillingness to even consider adding 2.5D type of games if other developers are willing to add it, so that might halter the advancement of AGS in that direction if it was something AGS was looking at.. But then again, look at some of the marvelous stuff people do here with 2D looking like real disney animation, so I personally don't care if 2.5D games aren't on the map.. LOL..
Personally I love AGS and it's my favorite place to look for games to play when I have hollidays, also I would love to play older dosbased ags games, but these days I can't be bothered anymore with all the hassle of setting up dosbox and trying to run the old games (yes I'm getting older and lazier too), also the new games that are created are very good, and the AGS community seems to be growing..
Personally I can't be bothered with playing AGS or any adventure on mobile phones, they're too small anyway for me, but with the advancement of tablets and sizes of 10" and larger I'm looking at more in that direction for playing adventures..
QuoteBy "cross-compatibility" I guess you mean "cross-platform compatibility"
Nope. He means backwards compatibility, Monkey.
From the entire rest of his post I have absolutely no idea where you're getting that idea from, unless you know something that I don't.
And other than the fact that part of the reason the engine source is somewhat unorganized is in part due to backwards compatibility efforts, I don't see why backwards compatibility would be considered a bad thing. As a matter of fact, in the ScummVM forums they were specifically arguing that an AGS->ScummVM port wouldn't work because AGS doesn't have backwards compatibility, which is largely untrue.
I'm not really aware of anyone arguing against backwards compatibility other than those trying to clean up the source code. And then it's just because it would be simpler than maintaining it. Of course, that's sort of like saying it's simpler to amputate a broken arm.
QuoteFrom the entire rest of his post I have absolutely no idea where you're getting that idea from, unless you know something that I don't.
Nah. I'm just good at reading between the lines. Also he metioned the following clues which I keyed off.
QuoteAlmost majority of the people today are running their comps on the infamous Windows XP, Vista and 7
QuoteI don't see why backwards compatibility would be considered a bad thing
Yeah beats me too. I'm just the voluntary translator for these kinds of things. :=
QuoteOf course, that's sort of like saying it's simpler to amputate a broken arm.
Well... that would depend on who's arm it is. :D Sorry.
[Proper hat back on] :)
The "clues" which tipped you off would really to me be indicative more of a desire to drop cross-platform compatibility instead of backwards compatibility of the engine..but in any case, I've responded to both interpretations with my opinion on the matter, so let's not get off topic here.
Quote from: monkey_05_06 on Wed 08/06/2011 16:42:08
The "clues" which tipped you off would really to me be indicative more of a desire to drop cross-platform compatibility instead of backwards compatibility of the engine..but in any case, I've responded to both interpretations with my opinion on the matter, so let's not get off topic here.
Personally I think crossplatform compatibility is much more important than backward compatibility.. If it was a seperate engine and data/bytecode set I might agree, but for using a newer engine as a agsdeveloper you still have to load the old project and tweak it. Compare it to say visual studio 2008 and visualstudio 2010, a lot of times you still need to make tweaks just to get your 'older' project running in the new enviroment, same goes for when you switch .NET frameworks..
but then again, I haven't got a clue to the extent of BC in the AGS-engine is.. I would say cleanup/refactoring the code is much more important as keeping FULL BC, and mind you, if cleanup/refactoring is done properly it should even be possible to keep the BC..
Maybe putting all characters and objects that belong in a room show up in the editor.
Even the main character.
What do you mean?? Like the "Characters" and "Objects" selections in the drop-down for what to display in the room?
Quote from: SuperDre on Wed 08/06/2011 17:50:18I would say cleanup/refactoring the code is much more important as keeping FULL BC...
I couldn't agree more. The gigantic patchwork that is AGS could do with a nice enema - flushing out old obsolete thinking with a new, modern framework, built for what AGS (and the market) is now and not what it was ten years ago. Contrary to your opinion though, I think Backwards compatibility can go screw itself. I (having worked on the same AGS project for over 5 years now) certainly appreciate the backwards compatibility of all new versions of AGS that I have updated to during its production. But from a broader perspective, is it worth the bogging down that the code as a whole suffers from now? I sincerely doubt ut.
That said, I have full understanding for why the AGS code base is what it is at this stage, and I fully respect the choices CJ has done during the project as a whole. That it now is a huge patchwork, was inevitable. I'm merely pushing for a flush now, rather than keeping on patching stuff simply in order to open up ancient AGS projects. Look forward, friends!
I kind of agree with Theo there. Here is what the best-case scenario is in my opinion:
I like the idea of an AGS 4.0 which does not need to be truly backwards compatible so can have a modern codebase.
I like the older version of AGS to be ported to ScummVM so older games can be played on modern systems.
As for the 3.x branch, well I'm not sure but I think we might just keep on patching on that version while AGS 4.0 is under development. This is how a lot of projects work nowadays, and it has some sense in it. As soon as AGS 4.0 is stable either 3.x and 4.x can be made compatible or 3.x can be ported to ScummVM too.
As for now, well, I waiting for someone to take on one of these projects, or another one, at least has some sense of direction. I'll love to join in but I have no time to start these projects myself at the time.
Agreed.
Now that the engine is open source it would make sense to stop feature development on the 3.x branch and just bug fix until we have a stable 4.0.
However, no one who has the required skills is likely to volunteer to spearhead the next iteration. Coders that have the time, inclination and talent to lead such a project are, shall we say, thin on the ground.
Something I don't understand is why people keep saying that they want backwards compatibility dropped, but then turn around and say that they want a ScummVM port all in the same breath.
The single foremost reason why the ScummVM team has said they do not want to spend their efforts developing a ScummVM port of AGS is the lack of backwards compatibility between engine revisions.
If we dropped backwards compatibility for all prior versions in favor of an entirely new codebase, the proposed AGS 4.0, we would have to guarantee that AGS 4.1, 4.2, 4.3, etc. were backwards compatible at least to AGS 4.0 or the ScummVM team is going to look at it the same as they do the existing branch.
I wouldn't necessarily be against the idea of a fresh AGS 4.0 so long as the 4.0+ versions were backwards compatible with the 4.0 engine.
Quote from: monkE3y_05_06 on Sun 19/06/2011 21:33:05
I wouldn't necessarily be against the idea of a fresh AGS 4.0 so long as the 4.0+ versions were backwards compatible with the 4.0 engine.
But of course, that's the whole idea. Also not to rush things so that we don't have huge revisions after the 4.x branch goes stable. That way keeping that branch itself backwards compatible would be much easier.
Isn't the 2.x branch pretty compatible with itself? Then the ScummVM team should not have much trouble with it.
I don't know whether there's a suggestion thread anymore, apologies if I missed it.. but one thing I've always missed and I probably speak for others is the allowance to wrap text in a list box. At the moment if the string is too long it just carries on over the bounds of the box, meaning you can't put long phrases or such without using workarounds.