(Mod note: This discussion was split from this thread (http://www.adventuregamestudio.co.uk/forums/index.php?topic=50090.0). â€" Snarky)
Quote from: Crimson Wizard on Wed 26/02/2014 19:32:08
As I learnt the existing code better and about problems that were required to be fixed, I was coming to the thought that AGS is simply not suited for upgrade that everyone wanted. It appears to me that although it reached certain state with existing features and capabilities, it took more than 10 years to evolve into what you have now with the work of one man (Chris Jones), and it will take too much time to evolve further to the next "level" to keep up with the demands of the modern day game developers and game players.
Perhaps it could be better to start a new engine, back couple of years ago, built with completely different design in mind, to replace AGS, but it's too late for me to try that now, especially not alone, especially while other engines and frameworks appear - this makes me feel that my work is getting useless in the perspective.
I know my opinions on this stuff are rarely popular but I agree with CW on the matter of AGSs updateability.
I believe AGS is not suitable in it's current state to be brought into the 21st century for two main reasons.
1) the graphics stack is designed primarily to be software based. This is a consequence of it's reliance on allegro. The hardware accelerated support is very much tacked on the end and that's just not realistic for a modern engine and it's only going to get worse. It would be difficult to fix this because a lot of the API relies on direct access to the surfaces (DrawingSurface support for instance simply cannot be moved to a hardware accelerated system without breaking backwards compatibility)
2) The scripting language is slow and archaic and it would require a huge overhaul to fix. *I know, I know* I've been on and on about this for a long time so I will leave it at that.
However, I see no reason why we can't begin AGS 4. The work CW and his team did on 3.3 was outstanding and it fixes most of the trivial issues people were having like alpha support and other resolutions (in the other branch) so I think it would be perfectly reasonable to leave AGS 3 behind at this point and consider it as done as it can be in it's current incarnation.
In a lot of ways that's kinda sad but I think it's also optimistic to draw a line under something and start again as a community.
I know I speak for everyone when I say that I hope CW would consider being a part of that.
As several people said, sadness is the first feeling here. Thanks a lot for everything you did. I understand what you said about feeling that the task is too big for some unreachable result. But that makes your achievement even bigger: as someone else said, without you we'd still be waiting for AGS 3.3
thanks a lot to the other contributors too -- we don't forget you just because CW is taking a well deserved break. Contributors to the Editor, to the engine, as wel as legendary module and plugins writers.
An idea: couldn't we initiate a transition to a more modern architecture by developing Editor and Engine plugins that would fake AGS' current features, but using the new architecture behind the scenes? Those plugins could be enabled or disabled, in the fashion of hardware-acceleration: "I want to use the old AGS code" or "I want to use the new code". This way, the transition could be done little by little, in 5 to 10 years (let's look far ahead) :) the code would slowly become less relevant as more and more people switch to the new one.
Quote from: Monsieur OUXX on Thu 27/02/2014 18:40:42
An idea: couldn't we initiate a transition to a more modern architecture by developing Editor and Engine plugins that would fake AGS' current features, but using the new architecture behind the scenes? Those plugins could be enabled or disabled, in the fashion of hardware-acceleration: "I want to use the old AGS code" or "I want to use the new code". This way, the transition could be done little by little, in 5 to 10 years (let's look far ahead) :) the code would slowly become less relevant as more and more people switch to the new one.
Recently I had a small discussion with Alyssa Milburn, the author of ScummVM AGS port, and she expressed a thought, somewhat similar to the one which occasionally came to me once: would not that be better if the ScummVM version would become the leading interpreter for running original AGS games, while interested AGSers could make a completely new engine, free of old ties, not needing to be backwards compatible?
Who knows, maybe that's what we should have considered to do a while ago...
Quote from: Crimson Wizard on Thu 27/02/2014 22:13:18
Recently I had a small discussion with Alyssa Milburn, the author of ScummVM AGS port, and she expressed a thought, somewhat similar to the one which occasionally came to me once: would not that be better if the ScummVM version would become the leading interpreter for running original AGS games, while interested AGSers could make a completely new engine, free of old ties, not needing to be backwards compatible?
Who knows, maybe that's what we should have considered to do a while ago...
As an outsider to the community looking in from time to time, I like the idea of a complete recode, dropping backward compatibility. It has become painfully obvious even to end users on Steam forums etc. that this is needed, and SkyGoblin's blog (http://www.skygoblin.com/2011/meet-gobby/) is inspiring, even if a full suite replacing AGS would require considerably more effort. Also, many big projects (Apache (http://www.apache.org/) comes to mind?) have done total rewrites without splitting their communities.
As for the renewed interest from the SCUMMVM project, I see this as a big win for end users in terms of retaining (and creating) accessibility to all our beloved AGS games. I had read some rather long threads here which disappointingly concluded with "not possible while still the active branch under the AGS project", so this could be really exciting. It is the future of AGS 3.x, I'm almost certain.
Lastly I want to thank you for your efforts, and I'm sorry it has been such a large source of distress. I'm sure any reasonable person here would happily encourage you to "do what you need to do". I feel that even just by giving your blessing to ideas such as the quote above, you are still contributing far into the future.
Personally, I don't think a complete rewrite is a good idea. Slapping together a simple engine may not be too difficult, but AGS is a huge beast, built to support a variety of game types and configurations, with thousands of little tweaks, settings and special-case fixes, and a fairly sophisticated editor/project management app. It took some 15 years of development (plus a couple of years in hiatus) to reach its current state. Think about it: just writing a new manual would be a big undertaking!
Also, while a project like Apache may be able to get the community to go along with a total rewrite, they have a rather healthier dev community to behind the project. As it's currently looking, total AGS rewrite would realistically be a project by two-three people (if that), and I'm not sure there are any potential candidates who have the stature within the community to convince game devs that something with a completely new API, stack, IDE and so on is still AGS.
Finally, while a complete rewrite is not always a bad idea, it usually is: it's a direction developers are often tempted to take even when it's not the smartest approach. The code you have is a mess, but the code you intend to write is pristine, perfect... However, then when it comes down to actually putting it down in text, you're back to the imperfections of the real world. Most of the time, an existing codebase can be fixed bit by bit, with some refactoring here, replacing a library there, rewriting a few individual components there. (As explained in this classic article (http://www.joelonsoftware.com/articles/fog0000000069.html).)
So if the graphics stack is a weakness of AGS and you know how it should be done, tackle that! You break some aspects of backwards compatibility, so be it. (If the biggest thing that breaks is DrawingSurfaces, and the new version provides a different way to achieve the things people use those for, it's probably not going to be too difficult for people who want to update to rewrite those parts of their game.) You don't need to throw away all the other parts of the engine or editor, and force game makers, players and community members to adopt an entirely new "AGS" to do that. Other changes (such as a new scripting language) can come later.
All that said, it's a do-ocracracy, and since I'm not the person to either do a rewrite or make major improvements to the current codebase, all this is just talk. Maybe I can convince some people, but it's what people who have the inclination, skills and time to get their hands dirty choose to do that matters in the end.
I do not have much intent to participate in such discussion, not at the moment at least, but I want to say this all depends on the aim. If the aim is to save as much from old AGS as possible, then you replace what you must and leave the rest.
But, you see, you keep using the word "rewrite" which presumes new implementation of old ideas. I have different opinion; I think many of the concept that AGS uses: scripting language, data format, localization mechanism, game entities and their relations to each other - should be reviewed and designed in a different way.
See RickJ's opinion, for example: http://img28.imageshack.us/img28/9957/entityconcept.pdf
I am not speaking about "realistic" aim now, "realistic" is usually subjective thing, what may be realistic in one condition and with one team will be unrealistic in other case; I just express my honest opinion.
The big flaw of my own work was that I didn't really make up a global aim... There should be one. Are you aiming on improving existing program? Or rewriting existing one which would do the same just better? Are you going to keep backwards compatibility?
Or do you want to write a completely new program that, optionally, may support old behavior?
That's the real question.
EDIT: Also, I am not sure I understand why anyone would need to persuade game devs that new thing "is still AGS". Is there a real need to keep ties to the old program? Original AGS won't go anywhere, it will stay and people may use it if they want. It may even be improved separately (by adding some features).
The reason to keep the ties to the old program is... well, this is the AGS forums, right? If someone wants to go off and build a new engine that's not AGS, fair deuce to them, but that's really not our concern here. This is about how to develop AGS further.
AGS is not just an engine; it is, perhaps more importantly, a community. That means the engine is not set in stone, but it also means that you have to get the community to buy into any new thing you want to call AGS. What we have is in many ways a proven success: one can criticize aspects of the design, but this is the engine that has become so popular and that has been used to make so many great games. If you were to change everything, for example to a compiler that just takes lua scripts (written in some arbitrary editor, using some completely different API) and a bunch of resource folders (e.g. organized according to RickJ's proposed structure), would you be able to convince the community that this was AGS and that they should make the switch? I doubt it.
I agree that many of the things you mention need an update (I have no opinion on data format), but I would use AGS as it currently is as a starting point, and evolve it from there. I don't think "rewrite" excludes the possibility of redesigning these elements, one by one. Personally I'm not persuaded by RickJ's proposal for entity relations or your idea for localization: both seem to me too abstract, trying to be totally generalizable rather than maximally pragmatic and efficient (in the case of localization, I think you get more usefulness with 10% of the complexity just by adding in Unicode support; you can use existing ability to check the current translation from the script to switch out graphics and voice packs). Similarly, rather than RickJ's deep hierarchy of entities and stuff, I'd be more inclined to just rethink views and loops. In any case, if someone believes in these ideas, nothing's stopping them from trying them out in an experimental branch. Like I said: it's a do-ocracy.
As for backwards compatibility, we've talked about this before. There's a big range between "you load your project in the new version of the editor and it just works" (or even "you can run old games with the new engine") and "you have to throw away your game-in-development and start again". I don't think it's a big deal if a new version deprecates a few API methods, or changes the scripting language syntax slightly. Obviously, if it required you to recreate a bunch of game resources (for example because it no longer had a notion of a "room"), that would be a higher hurdle, but still nowhere near as high as switching to a completely different engine.
Just something to think about:
What happend to all those other new engines (looking at Dage and XAGE for example). They also had dedicated and talented programmers.
Why did Wintermute 2.0 never happen (yet)?
Those big OSS projects have paid software engineers, coders etc.
I highly doubt that anyone here can invest the time and energy to create a new engine with even 10% of AGS's current features.
Just try to calculate, how many hours we would need to at least get the most basic adventure engine.
AGS is great (community aside), because it came such a long way. Because somebody kept it going for such a long time added features after features.
I completely agree with Snarky here.
Quote from: Snarky on Tue 04/03/2014 12:18:06both seem to me too abstract, trying to be totally generalizable rather than maximally pragmatic and efficient
Generic base makes things flexible, you can then shape it into many kinds of presets. It also allows people to find their own ways to do stuff. It also makes it easier to extend (which in many cases may not require adding new things, but rather reusing existing ones in the new way).
Quote from: abstauber on Tue 04/03/2014 15:04:57
Just try to calculate, how many hours we would need to at least get the most basic adventure engine.
Maybe not so much. Depends on which codebase do you use (existing libraries). Did not Calin wrote his preliminary Lua framework in two weeks?
(I am not making any far going assumptions here, just giving an example)
Quote from: abstauber on Tue 04/03/2014 15:04:57
AGS is great (community aside), because it came such a long way. Because somebody kept it going for such a long time added features after features.
And every simple feature takes more and more time to be added, because its like digging through a pile to reach a place where you can hack it in. And then realizing that there are conflicts with other features you did not see before, because they did not seem to have any obvious connection.
Quote from: Crimson Wizard on Tue 04/03/2014 15:27:25
Quote from: Snarky on Tue 04/03/2014 12:18:06both seem to me too abstract, trying to be totally generalizable rather than maximally pragmatic and efficient
Generic base makes things flexible, you can then shape it into many kinds of presets. It also allows people to find their own ways to do stuff. It also makes it easier to extend (which in many cases may not require adding new things, but rather reusing existing ones in the new way).
Yes, but only up to a point. Try to make things too general, and you end up with an enterprisey system where every task is obscured behind layers of abstraction. For example, you could say that the AGS concept of a "room" is not general enough. "Room" isn't the right word to describe an outdoor scene, for example. So maybe call it a "Node" instead. Additionally, you have things like menu screens, closeups, etc. that aren't really nodes in the same sense, so maybe make nodes a particular sub-type of... let's call it a "Scene". Scenes, of course, are a game Entity. Of course, you don't want to limit the room displayed to only where the player is, so make a more general property for that... And really you should be able to construct rooms â€" sorry, nodes â€" on the fly, so let's have a NodeFactory class for that...
Hooray! We've generalized AGS... Of course, in order to use it people have to wrap their heads around a bunch of abstract concepts and not-very-descriptive terms, just in order to solve what wasn't really a big deal in the first place, but pfft! it's about the elegance of the design, not the convenience of the user.
I'm caricaturing, but it's easy to drive yourself crazy by trying to generalize everything. (I'm currently deep in a database design task, and for pretty much every relationship I want to represent â€" say for example "Person A owns Car X" â€" there are edge cases and possible complications that makes it tempting to move up one level of generality: "There is some sort of relationship R between one or more People A, B, C... and one or more vehicles X, Y, Z". At some point you're no longer building a database for a particular task, just a generic database for storing anything.)
I've made my comments about the asset localization specifically in that thread.
QuoteQuote from: abstauber on Tue 04/03/2014 15:04:57
Just try to calculate, how many hours we would need to at least get the most basic adventure engine.
Maybe not so much. Depends on which codebase do you use (existing libraries). Did not Calin wrote his preliminary Lua framework in two weeks?
(I am not making any far going assumptions here, just giving an example)
With all due respect to Calin, I think there's a huge difference between putting together a basic engine for a particular game, and a full-fledged Adventure Game Studio, complete with IDE, documentation and everything (including lots of features the developer has no personal use for, always a bottleneck when it comes to open source development). It might not take 15 years to do, sure, but you'd have a long way to go before it was comparable with AGS. As opposed to the alternative, where each thing you fix or improve makes a good, popular engine better.
QuoteAnd every simple feature takes more and more time to be added, because its like digging through a pile to reach a place where you can hack it in. And then realizing that there are conflicts with other features you did not see before, because they did not seem to have any obvious connection.
Well, I remember that your initial plan was to first focus on refactoring the existing code. Did you make much progress with that, or did we distract you too much with feature requests?
Sorry, I see I am derailing the actual discussion to some hypothetical talk again. I'd rather stop now.
I am pro-rewrite. Or rather pro-drastic-change.
The editor could probably be salvaged but AGS is old not only in terms of its technology but also in its approach.
In a lot of ways it is built from the ground up to make retro games. It was built to emulate sierra and lucas arts games and it shows in terms of its architecture and its technology.
However, I do agree with Snarky that AGS is AGS and it's conventions are there because the people in this community like them and for someone to say "let's make AGS 4 completely different" does somewhat miss the point of a community.
With that in mind I think it might be best to make a competing engine. Something that attempts to emulate AGS but in a modern way. Essentially what AGS was to the old Sierra tools or SCUMM. Not a rewrite but rather a homage to the original. It would stray from AGS's vision in a lot of ways just as AGS improved upon SCUMM and its contemporaries.
I'll have something to announce soon on this, depending on rate of progress.
EDIT: On snarky's comment that AGS is a "huge beast". I disagree. It's huge in some ways because CJ doesn't use a lot of off-the-shelf technology and so maintaining the project has become arduous. Adventure games are very simple. It's not that complicated to replicate what AGS does with modern technology.
I agree with a do over in rewriting the engine. But it doesn't need to change what AGS is necessary. For instance, I still think the new editor should work nearly identically to how AGS 3.3 would work. Maybe some small differences would enhance it of course.
My idea would be this:
*Rewrite the engine using SDL as it is far more portable and works on more OS. As much as I hate to say it, Allegro does not seem to be what AGS needs. SCUMMVM itself is a testimony of what SDL can do and its portability.
*Develop it having LLVM in mind(I think that is what the software is called. I am at work and cant look it up now). The reason why I would use this is so that the project can also be compiled into HTML5 and Javascript so that the engine can work in our browsers. The benefit to this would be that we can then use Phonegap to compile the engine to many portable systems such Windows Phone, iOS, Android, WebOS, Symbian and Blackberry.
*For scripting, I would go with Angelscript. It is the closest language that matches AGS' original SeeR language and what it is now. I would go with that primarily. It is also highly portable. Something I thought of with AGS was that it can also include a secondary language, which would be LUA, giving the user more options and more power. I had seen this with another engine and I can't remember which one it was.
The big change for me would be coding the editor. I would like to propose using B4J(http://www.basic4ppc.com). There are a few reasons why I propose this:
1) It has a basic.net style programming language. This makes the language very similar to C# allowing many developers to participate in this, including me.
2) It is portable to Mac, Linux and Windows and basically anything that can run Java without changing any code between OS.
3) It can use Java libraries and plugins.
4) The interface can be far more attractive with less effort than C#
5) It can easily be ported to Android using Basic4PPC.
6) With small effort and libraries, it can handle all the things the original editor could and more.
If you would like me to do a mock up using B4J, I will.
This is where I think we should go with AGS personally.
If something new emerges it could find its place in this forum and community even if it's not called AGS right? I think that a new engine could maybe attract more developers than AGS. AGS was open source for years now and most people who looked at the code didn't work on it for long. That's not a coincidence.
Quote from: Calin Leafshade on Tue 04/03/2014 17:44:49
I am pro-rewrite. Or rather pro-drastic-change.
The editor could probably be salvaged but AGS is old not only in terms of its technology but also in its approach.
In a lot of ways it is built from the ground up to make retro games. It was built to emulate sierra and lucas arts games and it shows in terms of its architecture and its technology.
However, I do agree with Snarky that AGS is AGS and it's conventions are there because the people in this community like them and for someone to say "let's make AGS 4 completely different" does somewhat miss the point of a community.
I'm curious about what AGS conventions you think are so out of date and only suitable for retro games, or why the idea of emulating Sierra/LEC games ties you to particularly outmoded technology or architecture. (Ummm... maybe that sounds more confrontational than it's intended. I'm genuinely curious about what parts of the AGS design/architecture/codebase you think should be ditched.)
By the way, I'm not opposed to improving or changing a lot of elements of the engine and editor: replace the graphics stack, ditch globalscript, add support for vector masks... I'm all for it, and I don't think it fundamentally goes against the AGS design principles or conventions. I just think, as a pragmatic matter, that it's better to apply these changes, even architectural changes, to the existing AGS codebase rather than build something new from scratch. (Though it's all academic unless someone's willing to actually do it.)
In other words, how do you (all of you who favor a new start) respond to the Joel on Software (http://www.joelonsoftware.com/articles/fog0000000069.html) article?
QuoteEDIT: On snarky's comment that AGS is a "huge beast". I disagree. It's huge in some ways because CJ doesn't use a lot of off-the-shelf technology and so maintaining the project has become arduous. Adventure games are very simple. It's not that complicated to replicate what AGS does with modern technology.
Well, if that's true, couldn't you just do it? When you announced Adore (http://www.adventuregamestudio.co.uk/forums/index.php?topic=48624.0), you described some of the things it couldn't do as well as AGS, but if replicating AGS is so simple, why not put in some extra effort into replicating the user-friendliness and pixel-art support? Base it off the existing AGS editor, maybe add in a more C-like scripting language for people who hate and fear change, and you'd have AGS 4.0, right? It'd come with a built-in community.
Of course if someone can in, let's say, four months go off and rebuild AGS from the ground up with all modern libraries and technology, with all the existing features and a familiar API, taking care of all the driver problems, platform issues, internationalization limitations, future-proofing... fucking go for it!
Quote from: BigMc on Tue 04/03/2014 18:51:51
AGS was open source for years now and most people who looked at the code didn't work on it for long. That's not a coincidence.
By that same logic, if recreating everything AGS does well is so easy, why hasn't anyone done it already? At least we have an AGS 3.3 release; we don't have a competitive release of any of the "AGS Killer" engines.
Personally, I'll believe it when I see it.
I want to say that, in my opinion, the choice of existing libraries and or framework is essential. If I learnt something from past few years is that one should stay focused on one level of development at a time. You should not develop utility libraries when your task is to make game engine: this distracts you, steals your time and leaves you hugely dissapointed. Besides, every level requires certain thinking. Low-level routines must be super-efficient, but when you write higher layer of abstraction you want to forget about internal details and just write an engine logic, and if you work on two levels at once you get confused, pay too much attention to unimportant details and miss important ones.
So, don't spend too much time on things that are already done by other people. If you are not 100% sure, keep project modular, so that you can switch some parts in the future years if they prove to be not good enough.
Quote from: Snarky on Tue 04/03/2014 18:59:14
In other words, how do you (all of you who favor a new start) respond to the Joel on Software (http://www.joelonsoftware.com/articles/fog0000000069.html) article?
Aahhh. I remember this article. And I disagree :). I've seen too much bad code, I think.
I think every program has a certain lifespan, a limit when it is no longer fun (in general meaning) to maintain, support and improve. The better it is written, the longer lifespan is. But when you reached the limit - you reached the limit. And it is silly to pretend that you will be able to change it further. You might need a different approach, a different inner structure.
It's like building a house. If you have a 2-level house in a suburbs you maybe will build another storey on top, maybe add a shed and garage, but you'll never make a multi-storeyed condominium of it.
Quote
It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. First of all, you probably don't even have the same programming team that worked on version one, so you don't actually have "more experience".
I actually LOLed at this. The company I am currently working in we have a HUGE software which was developed since mid-90-ies. It was started when some of the developers were students and basically began to learn C++. Now they plan on creating a "next-gen" software version, writing a program base from scracth, and since I work with their old code all the time I can only agree :).
I'll underline, it is not really about writing
better code (although if you have more experience now, you may evade some mistakes), but about
better architecture, better
design solutions.
And, well, I've seen examples when rewriting software from scratch made things better :). One of them is AGS Editor :).
It's sad to see AGS coming to a kind of 'end point', but at the same time I think the editor is at it's peak now, able to support high resolution stuff, and it's extensible should the user so desire. It's not a bad time to draw the line, I mean it will still be useful for a while to come.
On the note of starting something new, I wouldn't nescessarily recommend building an engine from scratch. I wouldn't stop anyone if that's what they would enjoy doing, but looking at what ChrisIcebox is doing with his Adventure Creator plugin (http://www.iceboxstudios.co.uk/adventure-creator) for Unity, I'd almost say the smart move would be to support him in that project (if he wants that). That plugin is almost at a point where it can do everything AGS can do (albeit with bugs and caveats) plus Unity is free and compiles fine to a bunch of platforms. It's that AGS is still easier for me to use rght now otherwise I would have already switched. An argument can probably be made for building an engine that doesn't have the infinite bulk of all of Unity's features, but as for getting average Joe to jump on the adventure game bandwagon, I think you could do a lot worse than Unity + Adventure Creator.
Quote from: hedgefield on Wed 05/03/2014 12:59:48
[..] plus Unity is free and compiles fine to a bunch of platforms.
I think I recall Unity is proprietary and moreover
gratis only for certain users (noncommercial + lone devs maybe?).
Plus the plugin itself appears to be $70.
Being free is one of the key draws of AGS. To say we should not only rewrite the program from scratch, but give up on the whole idea of a free adventure game studio app... Speechless, I am.
Also, 8-bit mode...! :=
Quote from: Snarky on Wed 05/03/2014 13:30:07
Plus the plugin itself appears to be $70.
Oh, yeah that's right, I forgot about that... but maybe that price could go down if it was more than just one man putting his free time into it. But anyway I can't speak for what Chris wants to do with the plugin, just a suggestion. The feature set there is so robust that it almost seems like double the effort to redo it once again. But I also think the free aspect is important yeah, anything above a few dollars might scare away amateur devs.
To the point of Unity being free, the official FAQ says "you can create and sell a game with the free version of Unity, without paying royalties or any revenue share. However, the free version of Unity may not be licensed by a commercial entity with annual gross revenues (based on fiscal year) in excess of US$100,000, or by an educational, non-profit or government entity with an annual budget of over US$100,000." Which I think most of us are not in danger of.
Quote from: hedgefield on Thu 06/03/2014 14:04:28
To the point of Unity being free, the official FAQ says "you can create and sell a game with the free version of Unity, without paying royalties or any revenue share. However, the free version of Unity may not be licensed by a commercial entity with annual gross revenues (based on fiscal year) in excess of US$100,000, or by an educational, non-profit or government entity with an annual budget of over US$100,000." Which I think most of us are not in danger of.
Wikipedia states (about Unity free) "...but limited in features and watermarked for web". Is that correct? The FAQ is unclear about it: "Please also be aware that the feature set of the free version is not intended for the production of professional games and interactive content.". Are those limitation really that limiting?
To be honest I think proprietary licences can lead to big problems (especially when the copyright holder is not 'part' of the community). I guess many devs see those as trumped by easiness and rapidness of development, etc.
And since we are on topic: Calin, are you still planning to release your engine under a liberal/OS licence?
The technical limitations in Unity Free are there but they aren't massive. You can't use your own custom shaders for example - but it doesn't limit the amount of assets you can have, the texture sizes or anything like that. It's perfectly usable to make a game with.
Quote from: Crimson Wizard on Thu 27/02/2014 22:13:18
would not that be better if the ScummVM version would become the leading interpreter for running original AGS games, while interested AGSers could make a completely new engine, free of old ties, not needing to be backwards compatible?
That's the most clever thing I've heard regarding AGS and ScummVM getting closer to each other.
If ScummVM is going to make existing AGS games easily playable on a wide range of platforms, that's fabulous, and takes care of one of the big feature requests for AGS.
The big questions, as I see them, are still:
- Should future work on an AGS engine (defined as "an engine for the AGS community") be based on the existing code base, or is it better to start fresh?
- To what extent should a future AGS engine be compatible with or follow the same design as the current engine? Which aspects should be preserved, and which should be changed?
These questions are intertwined, but distinct: you could do a complete rewrite of the engine that was 100% compatible with AGS 3.3, and you could work from the existing code base but make enough radical changes that the new engine followed a completely different design.
And then finally, of course:
- So who is going to do it?
Quote from: Snarky on Fri 07/03/2014 17:32:52
- To what extent should a future AGS engine be compatible with or follow the same design as the current engine? Which aspects should be preserved, and which should be changed?
These questions are intertwined, but distinct: you could do a complete rewrite of the engine that was 100% compatible with AGS 3.3, and you could work from the existing code base but make enough radical changes that the new engine followed a completely different design.
One of the really bad things about AGS is the format of the compiled games so the answer to this question is quite obvious to me.
I only wanted to check what's the progress of ScummVM AGS port. I was surprised to see that, in fact, the port is not finished yet, missing many important features, one of which is save/load functionality. At first I thought I could help them copying new 3.3.0 features, but it appears there's still much work to get it complete. Also, since the code is rewritten from scratch, it will require lots of testing.
Alyssa Milburn also sais she has doubts if they will be able to get students working on it (for Google Summer of Code event), because the work requires "transcribing" original engine code, which may be bit tough.
Also, there's one important thing: ScummVM does not provide hardware graphics support. I heard they have hardware support in future plans, but before it happens, their AGS port cannot be considered "final".
Also, I have no idea about plugin support, I did not yet learnt if their system supports such thing. And I am afraid that the rewritten engine was made in a way that could break plugin compatibility (someone needs to check how optimistic/pessimistic things are).
So, frankly, I now think maintaining original AGS engine may still be essential for some time (well, for a year at least).
Quote from: Crimson Wizard on Tue 04/03/2014 19:24:06
Quote from: Snarky on Tue 04/03/2014 18:59:14
In other words, how do you (all of you who favor a new start) respond to the Joel on Software (http://www.joelonsoftware.com/articles/fog0000000069.html) article?
Aahhh. I remember this article. And I disagree :). I've seen too much bad code, I think.
The thing is that this article doesn't apply here :
- we don't want to do the code from scratch, because we'd use some widespread libraries (graphical routines, etc.)
- we don't switch entirely from the "old" ags to the "new" ags. There would be a period of transition, with the two of them being developed at the same time.
Quote from: Crimson Wizard on Tue 04/03/2014 19:24:06
I want to say that, in my opinion, the choice of existing libraries and or framework is essential.
That's where the discussion stalls every time.
I think we must take a strong decision: a forum thread with several candidate libraries for each key part of the Editor and Engine (RAD, script parser, graphical routines, etc.). Like, one table per component, with serveral entries in each table, one for each candidate library.
Then we discuss. Then we vote. And then the people who volunteer for rewrite stick to that.
Quote from: BigMc on Fri 07/03/2014 18:20:05
One of the really bad things about AGS is the format of the compiled games so the answer to this question is quite obvious to me.
The format of compiled games is a problem? How?
And how does that imply a decision one way or the other any more than any other AGS shortcoming does?
Quote from: Monsieur OUXX on Fri 07/03/2014 21:07:24
The thing is that this article doesn't apply here :
- we don't want to do the code from scratch, because we'd use some widespread libraries (graphical routines, etc.)
- we don't switch entirely from the "old" ags to the "new" ags. There would be a period of transition, with the two of them being developed at the same time.
Just because you're using libraries doesn't mean you're not rewriting from scratch. (Which is to say: using libraries is such a standard part of development that it's taken for granted, just like the assumption that you're probably not writing your own hardware drivers. The work discussed is what you have to do on top of that.) AFAIK there's no "Make your own AGS" library: you'd still have to stitch together a bunch of separate libraries and build a fair amount on top of that. Plus integrate it all into a nice package with the editor, plug-in system, manual and all that. As much as some keep saying it's not a lot of work, I remain unconvinced. (CW's observations about the ScummVM port seems to me to demonstrate the significant gap between "proof of concept engine" and "fully working system".)
I think the central points of the article still hold: (1) All the existing code represents a bunch of knowledge about the domain, with thousands of specific features and fixes for particular situations. (2) By starting over, you're pretty much guaranteed that you'll have a looong period of development before the next version is even close to feature-complete and you're able to address new feature requests, while by refactoring current code and rewriting components of it piece by piece, throughout development you'll have a version with more or less the features that have already been implemented, which you can bugfix or add to at any time. The philosophy has something in common with Agile programming: don't try to tackle a huge thing all in one go, but break it up into smaller, more tractable tasks, and have something you can run (in this case, a usable adventure game engine) after every step.
Of course you could always â€" in principle â€" keep developing the old version in parallel (same thing applied to Netscape back in the day), but since coders are our most limited resource, that's not a very efficient use of effort.
Now, I don't think Joel's advice should be followed as an absolute rule, but I think it's something to think very carefully about.
QuoteQuote from: Crimson Wizard on Tue 04/03/2014 19:24:06
I want to say that, in my opinion, the choice of existing libraries and or framework is essential.
That's where the discussion stalls every time. I think we must take a strong decision: a forum thread with several candidate libraries for each key part of the Editor and Engine (RAD, script parser, graphical routines, etc.). Like, one table per component, with serveral entries in each table, one for each candidate library.
Then we discuss. Then we vote. And then the people who volunteer for rewrite stick to that.
No, fuck that. Offering suggestions is one thing, but what the hell is the point of a vote? Most people don't have any clue about the technical intricacies involved, and it's not like there's any way to stop someone from going off and doing what they want just because a vote said it should be done some other way. It's a do-ocracy, not a democracy.
The people who do it get to decide how to do it. If someone is interested in implementing some part but isn't sure what library to pick, they can ask for advice. Meanwhile, discussion is futile unless someone is going to step up and write the code.
If we get into a position where we have multiple different branches with different solutions, and have to decide which one gets to be the official release... well, that's a better position than we're in now, not having any particularly active developers, and we can deal with it if it comes to that.
Quote from: Snarky on Fri 07/03/2014 21:50:02
(1) All the existing code represents a bunch of knowledge about the domain, with thousands of specific features and fixes for particular situations.
I'll put it this way: it were CJ's own words that AGS was made by "hacking" new things into over and over again. This makes it pretty messy, many features are hard-coded, while they could be made customized, there's lots of overcomplications, and many fixes serve only supporting those hacks to work together.
Quote from: Snarky on Fri 07/03/2014 21:50:02
Of course you could always â€" in principle â€" keep developing the old version in parallel (same thing applied to Netscape back in the day), but since coders are our most limited resource, that's not a very efficient use of effort.
To put things really straight, the situation is this:
1. If the developers will stick to current engine, they will have to rewrite parts of engine, and if they must do that by "small steps", this means that with every essential change they will need to take extra effort and time to keep all things working the same. Seriously, I nearly became mad when was trying to follow the "baby steps" strategy while trying to make "removed limits" version: after every change I had to re-test whole thing, check how savedgames work, check several rooms in several games, etc, and making "temporary hacks" to keep things working in the intermediate state.
2. If the developers will be making a new engine, they will be free from constraints of backwards compatibility, but will have to spend more time on planning & developing from scratch.
In summary: whichever path is chosen, it will take much time to make a serious improvement. There will be specific problems on both paths.
In the first case the new features will get implemented faster, but the chances are high that the result will still bear some old problems of AGS.
In the second the result will be more clear, but it will take more time that ALL the features similar to original AGS will work.
The question really is: does everyone needs ALL features, including hard-coded styles&modes, from AGS to use the new engine?
Obviously, only the people who think they know about the topic should vote. Snarky, you're always so negative about everything. Most people won't care at all, or have no idea what it's about, so they won't vote. Why would people give their opinion just to sabotage the debate? And the vote is not so formal and strict. It's just taking the decision now that at some point we stop arguing, and we decide.
We don't know yet who will do it, so there's no point in saying "it's those who do it who decide". the community needs to decide, and stop hitting again and again the glass ceiling of "which libraires should be used".
======
For example, here is a fictional scenario:
Which library should be used for graphical routines?
- Allegro
- Ogre3D
- Unity
- just DirectX or OpenGL
(yes, yes, I do know that they're not on the same level, middleware-wise).
We discuss. Then at some point we call for a decision, and everybody (involved) names his favorite candidate.
If the libraires are decided beforehand, then there's room for someone to make a proof of concept, without the risk of telling him: "sorry, you did something very cool, but on the long run we think the libraries you built it on suck, so your awesome embryo of a new AGS can be immediately thrown to rubbish".
Quote from: Monsieur OUXX on Fri 07/03/2014 22:27:47
Obviously, only the people who think they know about the topic should vote. Snarky, you're always so negative about everything. Most people won't care at all, or have no idea what it's about, so they won't vote. Why would people give their opinion just to sabotage the debate? And the vote is not so formal and strict. It's just taking the decision now that at some point we stop arguing, and we decide.
I'm not negative about everything. I'm positive about people going off and contributing to the engine (or making their own engines, if that's what they want to do), or even just offering ideas and suggestions. But I think a vote is completely pointless, because a "decision" is not a decision unless there's some capacity to act on it. We might as well have a vote on world peace.
Is there anyone who's standing around, ready to rewrite/write a new graphics stack but just waiting for a group decision on which library should be used? Because if not, a "decision" isn't going to lead to action any more than more arguing will.
The choice of library is an implementation detail, better left to the developers who are going to do the implementation. (If the choice of a particular library has specific implications for the engine in terms of compatibility, performance, licensing etc., that's a different matter that's certainly worth discussing... once the whole thing is not just hypothetical.)
Or to put it another way: OK, let's have a vote! I vote for "any way you goddamn please, as long as it works!"
Just my 2 cents. The primary purpose of AGS is that it makes it easy to develop Adventure Games and other similar types of games. No need for super hardcore 3d games and other special tasks. So my question is, why not using a low-end open-source backend, like LibGdx or other similar frameworks? No need to reinvent the wheel (developing an engine from scratch), especially for games that don't need much resources.
My proposal is this:
AGS 3.3 is working pretty well as it is. So games will continue to work as they are and game developers can stick to this version to complete or enhance their games.
AGS 4 will be completely new on top of a framework like libGDX.
Why LibGDX you ask?
+ Ok, that's maybe just my personal preference but I think that Java and C# are some of the most readable and understandable programming languages. At least one has an easier time learning Java (or C#) than C or C++ or Obj-C. LibGDX is developed in C, C++ and Java. AGS script is similar to Java and C#, so it wouldn't be too difficult for AGS developers to switch to Java language.
+ It is easily extendible and works well with IDEs like Eclipse and IntelliJ IDEA.
+ It is portable across Windows, Linux, Mac, Solaris, iOS, Android, Blackberry, all major browsers (as applet or HTML5 app).
+ It is extremely performant (using OpenGL 2+) and can run even 3d games on Android without lacks.
+ It is constantly enhanced by a large community which will help with all problems that the AGS development team could come across.
+ Super fancy OpenGL Shaders!
+ Unlimited sprites, animations, rooms, characters, everything! The only limitation is the hardware.
+ The developer can use any code (like the AGS "plugins" and modules) that is available for Java. For example: Facebook integration, in-app purchases, server connection ...
+ Today Java is pre-installed on almost any supported OS and we could also create a default game installer, which automatically installs the JRE if necessary.
+ Super high motivation, because we could have a working full-featured sample of the framework in a matter of months.
First step would be to create the AGS framework on top of LibGDX. We can create similar named classes and methods so AGS developers have an easier time to get into the new framework.
Second step would be to create the AGS editor. This could be done by creating Eclipse/IntelliJ plugins and a custom AGS View. Or a separate application.
The end developer would then develop using the Java language. For example:
public class MyAGSGame extends AdventureGame {
public void start() {
// Game start
Cutscene.begin();
Character cEgo = Character.get("ego");
cEgo.say("This is the beginning...");
cEgo.walkTo(15, 30);
cEgo.wait(2);
cEgo.say("...of something great!");
cEgo.playAnimation("raise arms");
Cutscene.end();
}
public void pause() {
// Game in background.
}
public void resume() {
// Game back from background.
}
public void update(float delta) {
// The old repeatedly execute
}
public void quit() {
// Game quits.
}
}
http://libgdx.badlogicgames.com
https://github.com/libgdx/libgdx/wiki
Quote from: Crimson Wizard on Fri 07/03/2014 21:42:07
Quote from: Monsieur OUXX on Fri 07/03/2014 21:07:24
Then we discuss. Then we vote.
Vote??? ...
I share the same feelings. It is only sensible and just that the people putting in the effort/hours/swearing will be the ones setting the vision of the project; basic do-ocracy tenet. That doesn't mean ousting proposals/discussion/consensus reaching (which is, in a way, what folks contributing to this thread are trying to achieve. Hooray for us!).
Quote from: Crimson Wizard on Fri 07/03/2014 22:22:48
To put things really straight, the situation is this:
[...]
As one of the persons with most hands on experience in AGS hacking (barring CJ himself), your inputs are precious Crimson; the more you write on the matter, the more elements everybody gets to make their own judgement (and you get a "Crimson Wizard tells it all" therapeutic session for free).
I don't know where I am going with this really; I wrote a list-of-question which I subsequently scrapped (too inquisitive/tactless now), but the point I am making is: your experience makes your opinions insightful, even if you won't contribute in the future, so post like there is no tomorrow! :tongue:
edit: a proposal! For the interested reader, libgdx is released under Apache 2 (and apparently hasn't been packed in Debian yet).
Ok for anyone how cares; my two cents.
Should we start over? Or keep working on the existing source? both!
Let me predict the future if we only do one of either:
Stick with the old
If we keep on working on the existing source we will probably get lost in it and face the same problems as CW did. The problem is that it really needs to be refactored because the code is not in the state where it can be worked on simultaneously by a group of developers: it's monolithic and not easily understood. In the meanwhile the world keeps on going and people will request more elaborate things to be added or changed at which the developers can not keep up and eventually grow tired of as it seems to be a loosing race: the project will be abandoned over and over.
Start over
A fresh an clean slate would be very nice since now we can design something that is up to par with modern standards. This will how ever not happen overnight: it is a lot of work and require a lot of coordination. Even if we find a passionate team working well together it would take at least 2 years to get something finished of the same posture of AGS (I reckon it might actually be 5 years). During the period of time to world also keeps on going. People will not stop making games but might not want to use an engine with a most recent version being years old an decide to use other tools. Other tools mean other communities and sooner or later people will start to migrate. In turn this will hit morale and the developers working on the new version and eventually drop out as well leaving the project astray. This sounds grim but I'm completely honest about this; this is what I think will happen.
So what then?
Do both! We can work on a new version that completely breaks with the old version so we don't have to make concessions but also refactor the original so we can still maintain new versions ever so often to keep people interested. More over we should not focus on the details so much as it comes to certain processes: why fuss about a splash screen when we don't even have the framework finished? It is better to zoom out and see the bigger picture. I've seen many many discussions where people promote the things they like and although I get that, it's besides the point. When we make something new it has to be for the community and the community should benefit from it. The problem is how we get there and I feel that's the biggest hurdle to take. I guess a way is to limit the amount of people involved in decision making but still the needs of the community needs to be reflected in the decisions they make. It's almost like governing a country wow to think of it. :D
Refactoring
This is just a lot of work and if it's for anyone the same as for me: you just don't know where to start. I would probably also have a hard time motivating myself for much task knowing there isn't much love; when purely refactoring you work for a year straight ending up with exactly the same product and everyone wonders: what's new? Well it's under the bonnet, it's what makes it susceptible to changes and fixing obscure (which are very much lit after refactoring) bugs. How do we sell it? I don't know but it needs to be done. It needs to be broken up in ever smaller chunks until it is at a point each chunk is easily understood and tested. Gah! Where to start. :D
A new version, how?
This calls for wits other then lots of talking: maybe we can split up the tasks make everything 100% modular. That way everyone can work on things matching their expertise. But this obviously needs some coordination or maybe rather a framework. I'm going to go reaaaally outside of the box here. For instance we have been discussion whether to use allegro or sdl or whatever: we can abstract from that using a wrapper: it's not about which library but rather about "how do we draw a sprite on the screen?". So rather then thinking "how do we do that using lib X and maybe is lib Y beter?" we make a wrapper that has a interface to draw a sprite on the screen and then whoever can write whatever bindings for whichever library they think is suitable.
Another example: instead of arguing about which script language to use we make it really easy to write language bindings with a wrapper. Then whoever wants can write whatever bindings for which ever language they seem fit. See where I'm going with this? So in the end we have a very basic framework that can be extended virtually limitless. The real power will be a flexible and easy to use editor that all stitches it together. Operating systems, platforms, all will be supported if there is someone willing to extend the framework in such way. What we will end up with then is the most powerful engine in the world (although with the editor still very much tailored to the needs of adventure game developers around the globe) and in the distant future even ATM machines will be run on AGS. And not regarding the last comment I'm not shitting you, this is very much a possibility and I'm sure it can be a reality though not over night. But we can do it; I'm in!
I know that opinions are like assholes... everyone has one...but.
AGS was originally designed to create 'old style Point And Click adventure games' right?
I started with 2.72 which done a damn fine job of fulfilling a goal I had wanted to accomplish since the ZX Spectrum, but had no scripting knowledge.
The editor taught me HOW to script, this was sorely missed in 3.0.
Had I started using 3.0. I would probably have given up right then and there, like many other so called 'Game Makers'.
Now everyone wants 3D graphics, better sound, higher res and all of the other shit that makes crap games of today like...
'Oh! can I knock that box over... WOW!... yes I can. (how exciting!).
My point.
Have you all lost sight of CJ's dream of creating Retro games?
I thought it was why we all downloaded AGS in the first place... wasn't it?
I know that my opinion won't matter, just read my avatar.
Creating retro style games will still be possible with AGS 4.0, I hope ;)
Frankly, it shouldn't be any problem to create a retro game and a super high resolution adventure game with the same language and framework. If you can create something super fancy, you can also create something not so fancy, low-res. (I imagine 8-bit color mod, implemented via custom OpenGL shaders which also allow for color cycling, just like in those old days)
And regarding developing without scripting knowledge. I think that code templates would be a good substitute for that feature. There could be an editor plugin which automatically adds code templates to the game code. The developer just has to select a template and fill in the correct data, the plugin does the rest.
Quote from: RetroJay on Sat 08/03/2014 01:46:25
I started with 2.72 which done a damn fine job of fulfilling a goal I had wanted to accomplish since the ZX Spectrum, but had no scripting knowledge.
The editor taught me HOW to script, this was sorely missed in 3.0.
Had I started using 3.0. I would probably have given up right then and there, like many other so called 'Game Makers'.
I know I'm nowhere skilled enough to contribute anything to the future of the AGS engine, but I wholeheartedly second this notion. Without the old editor, I would have given up on making games pretty easily. I'm comfortable with scripting now, but that editor was a lifesaver back in the day. :smiley:
Hi Brother Ponch.;)
Same here.
After making 'The Lost Prince Of Lorden' (Shameless Plug)(laugh)
I went through it again and re-scripted the entire thing again using proper code before uploading it.
I am currently trying to create the second part of my game and am pulling my hair out over the hideous audio system 3 has.>:(
Also I am wondering why I am bothering with 3 at all as colleagues at work and family are playing my first game with no problems on windows 7 and 8 and 8.1.
Why can't we just go back to 2.72 and build on that version? It worked. (please excuse my ignorance on programing matters).
Quote from: BigMc on Fri 07/03/2014 18:20:05
One of the really bad things about AGS is the format of the compiled games so the answer to this question is quite obvious to me.
This is the main thing that bothers me. Having a sort of pseudo, mixed, binary serialization makes it really difficult to make changes to the format.
Adore simply uses zip files, text files and the filesystem. Any data can be added to the format with a guarantee of not disturbing other stuff.
On the libGDX suggestion I disagree with that (although you'll find a post by me a few years ago suggesting pretty much the same thing). Adding a formal class system like that to what is, essentially, a hobbyist tool would be madness.
Quote from: Snarky on Fri 07/03/2014 21:50:02
The format of compiled games is a problem? How?
And how does that imply a decision one way or the other any more than any other AGS shortcoming does?
If you have a nice game format then you can just reimplement the engine in whatever way you want. That's what ScummVM did with many engines/game formats. The format of AGS games is whatever came out of the implementation. It's a chaotic and delicately fine-tuned mess that you have to deal with as long as you want to keep compatibility. Ask fuzzie (who started the ScummVM AGS port).
But I don't think anyone is arguing that the next version needs to preserve binary compatibility (the ability to run games compiled with the old version). Trying to maintain backwards compatibility with every previous AGS version seems like it's been a road to madness.
Quote from: bicilotti on Fri 07/03/2014 23:42:53
As one of the persons with most hands on experience in AGS hacking (barring CJ himself), your inputs are precious Crimson; the more you write on the matter, the more elements everybody gets to make their own judgement (and you get a "Crimson Wizard tells it all" therapeutic session for free).
I don't know where I am going with this really; I wrote a list-of-question which I subsequently scrapped (too inquisitive/tactless now), but the point I am making is: your experience makes your opinions insightful, even if you won't contribute in the future, so post like there is no tomorrow! :tongue:
I'd like to echo that. Much as I'm pushing against some of the conclusions, your insight into the problems with the code base are valuable. Hopefully the discussion does serve as "therapy" rather than as additional stress.
Quote from: RetroJay on Sat 08/03/2014 03:18:55
Why can't we just go back to 2.72 and build on that version? It worked. (please excuse my ignorance on programing matters).
I recently had to use 2.7 to test some code I'd written, and was shocked at how primitive and user-unfriendly it was. The reason not to go back to that version is that v3 (and 3.3 in particular) is much, much better.
That said, I think it would be nice to add back something like the point-and-click event scripting, for users who don't know how to code.
Quote from: Calin Leafshade on Sat 08/03/2014 07:05:13
On the libGDX suggestion I disagree with that (although you'll find a post by me a few years ago suggesting pretty much the same thing). Adding a formal class system like that to what is, essentially, a hobbyist tool would be madness.
Could you explain that a bit? Is the only reason you oppose libGdx that "scripting" would be in Java? AGS script already has structs, and a proper class system has been requested for a long time. I think there are pros and cons to Java as a language, but can't really think of any major code-writing complications it would introduce compared to what we have.
One appealing thing about libGdx for me is that it comes with a fully-fledged, skinnable UI library (com.badlogic.gdx.scenes.scene2d.ui). I've often come up against the limitations of AGS's hardcoded GUI controls.
Quote from: Wyz on Sat 08/03/2014 01:03:47But we can do it; I'm in!
Great! Knock yourself out.
Quote from: Snarky on Sat 08/03/2014 09:04:45
Could you explain that a bit? Is the only reason you oppose libGdx that "scripting" would be in Java? AGS script already has structs, and a proper class system has been requested for a long time. I think there are pros and cons to Java as a language, but can't really think of any major code-writing complications it would introduce compared to what we have.
Sorry yes, I wasn't clear.
When you introduce a language (like java and c#) that has a mandatory OOP structure (*everything* is an object) you introduce all kinds of more advanced programming concepts and I think those concepts should be an addition or an option rather than something that one need know to use AGS.
I might be overstating the issue but I think a more conventional scripting language would be a better idea (Angelscript, Lua, something similar)
Also, Java is a huge language which might be a bit much for making a little fellow walk around saying things.
EDIT: I wasn't particularly averse to LibGDX. Only the class structure posted. We could use any number of scripting languages with libGDX as the host.
Normally, I'd side with Snarky on using an existing code base and not rewriting everything from scratch. By careful refactoring (using something similar to the Mikado method (http://www.agical.com/mikmeth/mikadomethod_old_hidden_76213ge.pdf)), you can bring the software from state A to state B and it can then be a completely different animal. Btw, a couple of years back I used to belong to the other side of the fence, but since I then saw my work's ugly legacy software becoming something much more maintainable I've been made into a believer.
However, there's one legitimate reason to do a rewrite, and that is switching to a more relevant and appropriate underlying technology, making refactoring not so relevant. And this why, I think we should do a rewrite:
UNITY
I don't mean supporting Adventure Creator like was suggested before, since it's a commercial project, I mean developing our own AGS for Unity plugin which would be free and open source.
Why I think we should switch to unity?
1. Unity is by far the best game development framework existing today, and it's far ahead than anything else I've seen (and Wyz, if you honestly believe we can build a better engine than Unity in 5 years, than let me say I highly admire your optimism, but with that, please send me the contact details to your dealer :P ).
2. Unity has a huge community behind it, which could result in a lot more adventure games being made, and also recruiting much more developers than we could have dreamed of. I mean, just look at the number of posts in the Adventure Creator thread, to understand the potential.
3. The free unity version (and bicilotty, I didn't really understand your comment about unity you made before) has more than enough to build a top quality adventure framework (it is highly customizable and extendable), and there is no problem releasing commercial games using it (unless it earns more than 100K, and in that case surely you can afford unity pro), with the only caveat of the free version is showing the unity logo at the beginning.
4. Unity does so much for you already: portability, choosing between 3 different and recognised languages, a highly sophisticated IDE with the most beautiful debugging system I've ever seen, hardware acceleration, shaders, and they also recently released 2d tools (http://learnunity2d.com/2d-game-development-walkthrough/). I see no reason to believe they won't get even better and further increase the gap between them and the competitors.
In short, switching to Unity is the only feasible way I see for AGS to remain relevant in tomorrow's world.
The big misconception in this discussion is that some people believe we want to ditch AGS to make 3D games bullshit. Nope.
We still want to make mostly [at least] old school point-n-clicks with AGS. "At least" means there must be room for more advanced stuff, but that's up to the community. The primary target is to make the code maintainable and expandable, which it is not anymore [or at huge costs].
=====
I think the perfect library to build upon for a proof of concept is Ogre3D (http://www.ogre3d.org/), because:
- unlike Unity, it's free and open source. It's the heavyweight "graphics and more" engine in the opensource world.
- it's very much alive and keeps evolving quite cleanly along with new technologies. We can get all the support we need from their community. In 10 years it's still here.
- it's multiplatform
- it's just the right level of middleware: graphics, BUT ALSO input, sound, etc. Just like DirectX or OpenGL, but several layers higher.
- Perfect for AGS: it allows scripting : C#, Lua I believe, etc.
- Perfect for AGS #2: it's object-based, configurations-based, tree-based. It means we can mimic the tree-structure of an AGS project very naturally into the Ogre3D code.
- several people have developed RAD interfaces or Editors (http://www.ogitor.org/) upon it. It's pretty much the AGS Editor already ready for you.
====
I find Unity very cool but I really don't like the idea of big commercial engines that can change their licensing policy overnight.
Lots of good arguments in different directions here. To me the main appeal of Unity would be the extensive platform support. Ogre3D's support for Android and iOS seems to be fairly rudimentary (from a quick glance around their webiste). However, I agree with Monsieur OUXX that tying ourselves to a commercial engine feels (a) risky and (b) not really in the AGS spirit.
Quote from: Calin Leafshade on Sat 08/03/2014 09:50:02
Sorry yes, I wasn't clear.
When you introduce a language (like java and c#) that has a mandatory OOP structure (*everything* is an object) you introduce all kinds of more advanced programming concepts and I think those concepts should be an addition or an option rather than something that one need know to use AGS.
I might be overstating the issue but I think a more conventional scripting language would be a better idea (Angelscript, Lua, something similar)
Almost everything in AGS is already an object, and the things that aren't probably ought to be. The only immediate difference thrown at users I can think of is that GlobalScript (if still around) and each of the room scripts would probably be an object, but it seems like a pretty trivial change, and it might even be possible to hide this in the editor.
While Java is not typically used as a scripting language, it's probably closer to what we have - for better or worse - than either Angelscript or Lua. (Angelscript uses C-style &memory-address and pointer->object notation, surely a bigger mindfuck than Java objects.)
I'm not saying you're wrong (Java is one of the first programming languages I learned, so I might not notice the difficulties), but I just don't really see what "more advanced programming concepts" it would force a coder to learn.
If we were to adopt a standard scripting language, I've been leaning towards Javascript: it's widely known, there are a number of highly-optimized compilers, and it looks superficially similar to AGS script (even though it's really very different).
QuoteAlso, Java is a huge language which might be a bit much for making a little fellow walk around saying things.
Are you talking about the language, or the standard Java libraries (many of which, AFAICT, are not included in/used by ligGdx)? I don't see how the different language features (many introduced only in recent versions) would be a problem: they're not essential, you don't have to use them or even learn about them.
I'm way out of my league here regarding technical stuff about the engine but I'd like to say some words.
To me it's pretty clear that AGS is all about the community. Not saying that AGS isn't a marvellous program but it's capabilities and fixtures aren't its main strength. The people that populate AGS are indeed special and devoted and very well capable of doing amazing games with AGS.
The best AGS titles are great because the projects were great with talented people working on them.
So, why change something that is capable of doing good commercial games?
We want more fixtures and cool stuff, that's great and I like new things as well. But I ask:
-who among all the devs around here are really capable of producing good solid and polished games?
-is the quality of a game related to the engine or instead to the amount of work and dedication regardless of the engine?
I say that only a small percentage of (ANY engine, unity, game maker, etc) users are capable of releasing good games. And add to that saying that IT IS NOT the engine that makes good games but the people and their work.
The engine graphical limitations have cornered AGS into a niche place in game developing for years now. That is a fact and understandable if people want or need better fixtures.
I think that we are rushing things that really don't have to be rushed. So, CW burned a fuse or two working on 3.3, well any mortal would. Let's praise CW and thank him. His knowledge is now something invaluable for the community.
Is the AGS engine stretched to its limits a reality?
If so, let's not stress about it. I'm sure that as it is, the engine is capable of releasing great PC games.
I even consider this (the totality of AGS capabilities reached) a good thing. AGS is all about retro gaming, right? Let's keep it that way.
One one hand we know that the engine code needs some major and time consuming refractoring just to be able to keep on working on it.
Solution: pay somebody to do it. Can be somebody in the community, sometimes money is a pretty good boost for working. But just sometimes. If we are a community of several thousands we could gather the money.
On the other hand we have a stable, beautiful engine that allows us to make old-style adventure games. And it's free.
It's also limited to the PC.
Solution: don't ruin the thing, let's keep on being awesome as we have been.
On the third hand: we don't have to be ultra conservative and stick to things just because. Yes, do something "like" AGS using Unity or similar, but, again, consider paying somebody.
Quote from: Snarky on Sat 08/03/2014 11:32:40
[...] If we were to adopt a standard scripting language, I've been leaning towards Javascript: it's widely known, there are a number of highly-optimized compilers, and it looks superficially similar to AGS script (even though it's really very different).[...]
I wholeheartedly agree with this paragraph. AGScript and JavaScript are indeed superficially similar to AGS script. I don't know about others but when I started learning JavaScript: the AGScript just 'came' to me naturally. Like there's some sort of incomprehensible and undiscovered connection in-between them.
Quote from: miguel on Sat 08/03/2014 11:56:29
Solution: pay somebody to do it. Can be somebody in the community, sometimes money is a pretty good boost for working. But just sometimes. If we are a community of several thousands we could gather the money.
That's exactly what was being discussed on IRC few days ago. We've a fairly large dedicated community, hence it seems feasible. Now we just need a coder to do it for little money... qptain_Nemo, your dream is about to come true! ;)
The reason why I was proposing libgdx was because it is a low-end backend. Meaning we can build solutions to certain parts of AGS (room hierarchy, dialog engine, template system or the editor, just to name a few) just the way we want. On the other hand Unity is a high-level event based 3d development tool which has already lots of features and editors for things that probably no adventure game creator ever needs. LibGDX is not bloated, it's really light-weight. One of the great things I like that much about libgdx, is that it's targeted towards 2D development (still it also allows for 2.5D or 3D) and has an excellent expandable UI system.
Also Java already has a solution to almost anything, like javax.sound.midi for Midi sound support. And we can use JNI to add certain C or C++ modules, like PCX support.
We could even use a Java JavaScript interpreter and then allow people to develop in JavaScript, though I don't think that there is any benefit in using JavaScript over Java for developing. The syntax of both really much is the same and both are object oriented (JavaScript having the DOM).
But that's really much just an idea. In the end it is the decision of the community on how we go about AGS 4.0. One thing I have to say though, AGS has now reached the end of it's glory times in Antiquity. Now we must decide if we let AGS drift into the Middle Ages and everyone forgets about it or we directly lead it into Modern times. And a rewrite is the only option for this to happen.
Regarding development and hiring a coder.
I would propose to first create a new public Github project for AGS. This way everyone can contribute and help (via pull requests and issue posting). It's also motivating for others to see how it is coming along.
For those who don't know github, check the libgdx project out here: https://github.com/libgdx/libgdx
Especially take a look at the commits page, as you can see how it is actively developed: https://github.com/libgdx/libgdx/commits/master
I think that this would be a first step in thriving more motivation onto the AGS project.
Then we should form a team of willing developers, who would have the time and interest in developing AGS. One coder won't be able to do all the work. Though it could be motivating if the ones would get a little wage for their work.
You realize that AGS is already on Github? https://github.com/adventuregamestudio/ags/
Quote from: tzachs on Sat 08/03/2014 09:52:41
3. The free unity version (and bicilotti, I didn't really understand your comment about unity you made before) has more than enough to build a top quality adventure framework (it is highly customizable and extendable), and there is no problem releasing commercial games using it (unless it earns more than 100K, and in that case surely you can afford unity pro), with the only caveat of the free version is showing the unity logo at the beginning.
What I meant was that I know very little about Unity (apart from the fact DoorKnobHandle is developing some fine stuff with it) but am generally wary of proprietary stuff, as they can change ToS overnight leaving you in the cold (ask lemmy101 about wave (http://www.adventuregamestudio.co.uk/forums/index.php?topic=38984.msg512981#msg512981) and XNA (http://www.adventuregamestudio.co.uk/forums/index.php?topic=37567.msg493864#msg493864)).
I want to restate I am ignorant on this particular tool, but an "exit strategy" plan is needed if we are to embrace a software which is not OSS/we have no control over, or we could get burned!
Quote from: Wyz on Sat 08/03/2014 01:03:47
But we can do it; I'm in!
Am I the only one to have noted this? It seems (after a three pages long discussion) a wild coder appeared! We shouldn't waste the opportunity and tame him
now!
Quote from: Snarky on Sat 08/03/2014 12:56:08
You realize that AGS is already on Github? https://github.com/adventuregamestudio/ags/
Ah my bad! Must have overslept that ;) Thanks for the update!
In Portugal, expensive coders have their testicles removed.
Quote from: miguel on Sat 08/03/2014 13:06:20
In Portugal, expensive coders have their testicles removed.
As a Windows programmer, I can vouch that this is pretty common. I am often asked if I'm comfortable working in a eunuchs environment.
Hello to everyone!
Many years have passed since my last post on the forum, actually I never left the community of AGS, in fact I've enjoyed your great adventures, but, for various reasons, I decided to stay to observe the development of the project from behind a curtain without taking part.
If you remember my plugins with which I tried (without much success) to bring the third dimension within AGS you can understand that for me the inadequacy of the engine was obvious for a long time.
Since CJ has released the sources I began to analyze the code and try to modify it to use Irrlicht library as graphics engine. In this long process I dealt (more or less in depth) with most of the themes that I see now in this post.
My conclusion was:
create a new engine able to "run†the current games but at the same time that offers the opportunity to create something modern with 3D graphics, ecc...
Also, I believe that in parallel to this discussion / brainstorming, which is necessary and I hope conclusive, we must necessarily complete the work begun by Crimson (thank you for your efforts):
make the source code completely modular, separating the logic fron the implementation
This activity will not be a waste of time because, whatever the road that will be taken, in thousands of lines of code behind AGS there are many discussions on how and why that will be useful for future programmers to avoid to commit again the same mistakes.
However, since I got tired of watching from behind the curtains, I put at the disposal of this new adventure a bit of my free time.
As I see that there is a little bit of interest in an AGS built with Java and maybe LibGDX, I have just crafted out this raw todo list that would be involved in creating the new AGS when taking this route:
Quote
1. Milestone:
Developing the base classes to create a standard adventure game with rooms and walking/talking characters.
1.1. Creating a model for an expandable class hierarchy that will be exposed to the end developer.
AGS.rooms
AGS.characters
AGS.objects
…
1.2. Implementing rooms.
At this state the developer will be able to only create new rooms via code. Like:
Room rIntro = new Room(„intro“);
rIntro.setBackground(„intro_background“);
rIntro.setWalkableAreas(„intro_walkables“);
rIntro.setWalkbehindAreas(„intro_walkbehinds“);
AGS.rooms.add(rIntro);
AGS.rooms.fadeTo(„intro“, FadeType.SLIDE_LEFT, 0.5f);
1.3. Implementing characters.
At this state the developer will be able to only create new characters via code. Like:
Character cEgo = new Character(„ego“);
Animation aWalk = new Animation(„ego_walk“, 10);
cEgo.setWalkingAnimation(aWalk);
Animation aIdle = new Animation(„ego_idle“, 5);
cEgo.setIdleAnimation(aIdle);
Animation aSpecial = new Animation(„ego_special“, 7);
cEgo.addCustomAnimation(„special_1“, aSpecial);
AGS.characters.add(cEgo);
1.4. Implementing walkable areas and walk behind areas.
Areas can be defined as SVG or pixel graphic files. SVG allowing overlapping areas, pixel graphics will work like in the AGS editor.
1.5. Implementing a search path algorithm like A*.
1.6. Implementing different fullscreen modes.
The developer will be able to use any resolution they want. He should be able to choose a fullscreen mode and if he wants to allow the player to change that. Like „stretch to fit“, „black bars“, „scale up with non-nearest-neighbor filter“.
2. Milestone:
Extending the features with an Action system, objects and inventory items.
2.1. Creating a model for a class hierarchy that allows to make actions like PICKUP or USE.
2.2. Implementing Actions.
2.3. Implementing Objects.
2.4. Implementing Inventory Items.
3. Milestone:
Adding a customizable UI system that is build on top of scene2d, adding a dialog system with custom dialog script files and adding a translation file system.
4. Milestone:
Games should be bundle-able into a installer which automatically installs the JRE if necessary. Also add the remaining features from the old AGS engine, like MIDI and PCX support.
5. Milestone:
Creating the editor to allow for room, character, object... creation via editors. These editors will create xml files for all game elements. These xml files will be read by AGS at launch and then the elements will be automatically created.
Implementing a resource linking system similar to Android. This allows for code auto-completion of game resources and elements.
6. Milestone:
Creating code templates that the developer can use for easier development without much developing knowledge.
Quote from: Besh on Sat 08/03/2014 13:38:21
(...)
However, since I got tired of watching from behind the curtains, I put at the disposal of this new adventure a bit of my free time.
hear hear!
I feel like I start to loose track of the discussion (and being unsure if I want to participate), but I want to make a warning.
I think it will be a mistake to dive into selecting library / start writing a code stage. The first thing that should be done is giving a clear answers on following questions:
- What kind of system/engine do you want to get done?
- What kind of users is it aimed for?
- What kind of general features should it have?
- Do you want it to be extensible, and which way?
E: those answers should NOT include references to technical details or code samples! They should give a general picture from model designer & user perspectives!
Making a design concept is very important. The selection of libraries should rely on your aim, not on random ideas of their usefulness. Writing "raw todos" about which order will you implement classes - is the last thing to be done before starting to write a code.
Quote from: Crimson Wizard on Sat 08/03/2014 14:50:05
- What kind of system/engine do you want to get done?
- What kind of users is it aimed for?
- What kind of general features should it have?
- Do you want it to be extensible, and which way?
That's a nice road map! I think these questions have never been answered, even though there is a distinct and possibly shared idea of the vision/scope of AGS inside the community.
I am not sure people agree with me on this, but I think the allure of AGS lies in its ability to
easily make Adventure Games, requiring
little technical knowledge on the user's side.
Everything else (extensibility, generalisation) is fair game
as long as it does not collide with those two pillars. Call it the '2.72 spirit'.
^-- this is of course to get the ball rolling, I am quite interested in the answers of people who volunteered (Wyz, Besh) plus yourself Crimson.
Quote from: Crimson Wizard on Sat 08/03/2014 14:50:05
- What kind of system/engine do you want to get done?
Like AGS v3, only better.
A free, open-source engine and accompanying dev tools to make traditional (bitmap-based) 2D adventure games in any resolution from 320x200 and up, to run on a variety of platforms (targeting Windows, Mac OSX, Linux, iOS, Android), with enough power and flexibility to accommodate most of the ideas and ambitions found among AGS game developers.
Quote- What kind of users is it aimed for?
-Current AGS users
-Amateur and hobbyist adventure game creators
-Semi-professionals (often working in teams)
-Small commercial indie developer studios
It should be accessible to newbies (e.g. easy to install, run and start working with), and not have too high a learning curve for people without much programming experience.
The players of the produced games would generally fall into two camps:
-Enthusiasts (those familiar with the engine, somewhat computer-savvy)
-General audience (for whom we may assume basic computer and computer game-literacy but no more)
Quote- What kind of general features should it have?
Well, it should generally have the features and capabilities AGS currently has (though not necessarily offered in precisely the same way).
Possible exceptions:
-Hardcoded support for various features (e.g. Sierra-style cursor modes, LucasArts-style dialog option lists, text parser) could be removed and instead offered as script modules/game templates/plugins.
-Support for 8-bit color modes (256 color) could be retired: it's already tricky to get 256-color games to run properly on Windows.
Functional enhancements over the current AGS version (with possible implications for the architecture/library choices) would include:
-More flexible graphics rendering (e.g. resize, switch windowed/full-screen on the fly)
-Improved graphics rendering in general (performance, consistency, compatibility, hardware support)
-Better/more convenient multi-platform support, particularly for porting/deploying games on iOS/Android
-Improvements to the scripting language (or replace it with a different language) and script organization
-Improved compile speed, better efficiency in updating game projects
-A better file format for compiled games (per Calin and BigMc)
-Better support for patching games (without breaking savegame compatibility)
-Unicode support
Stuff like support for shaders, filters, subpixel rendering, etc. are also worth keeping in mind. Support for vector graphics and 2.5D games should be at most a secondary concern, IMO.
Quote- Do you want it to be extensible, and which way?
How do you mean? Like with plugins? In future versions?
With the engine open source, I guess plug-in support is not as important any more. Would still be nice to have, though.
Of course we'd want the system to be extensible in the future, allowing us to add new features and so on.
I think we all agree it would be best if the system was split into separate components communicating through well-defined APIs and data formats, so that individual pieces could be replaced/modified/extended without impacting the whole system too much. So we might have:
-The engine backend (which renders the game on a particular architecture)
-The core engine logic
-The compiled game (scripts and assets)
-The compiler
-The IDE
-The game project with source files, assets and configurations
Well those are the right questions to ask! They give the defining trait; this usually depends on the vision of one or more people. I agree with the two pillars bicilotti has presented; those who have sufficient technical knowledge can make their own framework and the AG in AGS stand for Adventure Game: this must be the key goal of the framework. I guess CJ already answered these questions for himself working on AGS; do we copy his vision or do we form our own?
Personally I like to stay true to the vision of the original author (as far as I can guess this) yet update it to what the game developers of today envision.
That said I agree with most of what Snarky said! (not the plugins part: it would be nice to make the plugin support even more flexible. The reason is you can remove features form the engine and provide them again as plugins to prevent engine bloat. But that still leaves as shitton of points I totally agree with. :D)
I have a fear that I am not well understood again. Maybe that's because I didn't explain very well.
For example, I think that it is a wrong path to take current AGS as a starting point and think of new engine as something that improves it.
"Improved graphics rendering" - what is it? What you are going to improve, if the engine is built over totally different code base, for example?
"Improved compile speed" -again, what are you going to improve? Are you suggesting to keep the project's format anyway?
Not mentioning that is purely technical side of the project.
Would not it better to have a fresh view on design, and then think of how do you apply AGS features there?
Considering "features", what I have in mind is actually this:
- This is engine that lets you to make an adventure game? What does "adventure game" consists of? What should be intrinsic types of elements, and what may be left for user to script? How elements are connected to each other?
- This is IDE that lets you to build an adventure game project? What assets does it work with? How do you organize them? What will you allow to do with them?
- Do you want a generic system that allows to shape more definitive sort of game by attaching data schemas and script modules? Or do you want to have a more strict data system? Where's the line between what is strict and what is generic?
- Do you want a game that could be patched? How should that be organized? How will you make older savedgames be applied to the new version, which rules and algorithms will be applied, how the data conflicts should be resolved?
Such things as graphic modes, are less important because they are not restricting data formats or other concept, therefore they are choices that may be decided last.
Also, I was refering more about writing a concept document (maybe in wiki-like fashion) that would cover those topics. I am wary of quick decisions, they often lead to problems later.
This article (http://www.joelonsoftware.com/articles/fog0000000069.html) by Joel Spolsky strikes me as very relevant to the discussion here. It's not that long, and highly recommended!
Quote from: Radiant on Sat 08/03/2014 19:01:18
This article (http://www.joelonsoftware.com/articles/fog0000000069.html) by Joel Spolsky strikes me as very relevant to the discussion here. It's not that long, and highly recommended!
Quote from: Snarky on Tue 04/03/2014 10:30:21As explained in this classic article (http://www.joelonsoftware.com/articles/fog0000000069.html).
(laugh)
I do agree that AGS is very primitive, not only in scripting but also in capabilities. All XY coordinates are ints. There's no easy way to do a custom approach to anything that's hardcoded, it would be very nice if the underlining scripting language that makes AGS's custom functions were able to be adjusted within the editor via scripting (ie: if you don't like the say function, adjust it yourself). I disagree that the goal should be to make an "adventure game" engine, the goal should be to make an easy to use game engine. The adventure part of it is an extended script of what you could do with a proper game engine.
Edit: Of course though having a nice animation studio would be very beneficial. A much better version of the view editor, but instead of being limited to just one sprite and the only alterations that can be made is flipping it, you could add as many sprites you want, position them where you want, rotate, stretch, skew, etc. Having a center XY 0,0 position in the middle of the canvas and being able to manage the sprites' locations where you choose instead of it centering based on the sprite width when drawn from a character.
Quote from: Crimson Wizard on Sat 08/03/2014 18:09:03
I have a fear that I am not well understood again. Maybe that's because I didn't explain very well.
For example, I think that it is a wrong path to take current AGS as a starting point and think of new engine as something that improves it.
Well then I think we're coming at it from completely different points of view, because IMO the whole point is to take AGS as a starting point! If people want to go off and do something completely unrelated, they're of course welcome to do so, but I think that if we're trying to decide what would be the best direction
for AGS, starting with
what AGS is is sort of mandatory.
Quote"Improved graphics rendering" - what is it? What you are going to improve, if the engine is built over totally different code base, for example?
"Improved compile speed" -again, what are you going to improve? Are you suggesting to keep the project's format anyway?
Not mentioning that is purely technical side of the project.
I thought the point of asking these questions was to inform the decision of which libraries and what architecture to use. Establishing the things that are priorities to improve (with the current version as a baseline) seemed like a good way to get a handle on these things. For example, since Allegro seems to be one of the problems with the current graphics rendering system, that would indicate that we should not pick Allegro again.
QuoteWould not it better to have a fresh view on design, and then think of how do you apply AGS features there?
Considering "features", what I have in mind is actually this:
- This is engine that lets you to make an adventure game? What does "adventure game" consists of? What should be intrinsic types of elements, and what may be left for user to script? How elements are connected to each other?
- This is IDE that lets you to build an adventure game project? What assets does it work with? How do you organize them? What will you allow to do with them?
- Do you want a generic system that allows to shape more definitive sort of game by attaching data schemas and script modules? Or do you want to have a more strict data system? Where's the line between what is strict and what is generic?
This sounds a bit like reinventing the wheel to me. Are these actual problems people have with AGS the way it is now? If not, why mess with it?
I'm much less interested in asking "what is an adventure game?" or "what is the abstract structure of a game in general?" or "what if you could define data schemas?" than with the pragmatic questions of "how can we tweak the current design to help people make games more quickly/easily?"
So I would rephrase your questions:
- Are there built-in AGS features that would be better left for script modules/templates/plug-ins (yes, I already listed some); and are there features that should be incorporated into the engine (personally I'd add Tween and FaceDirection(), for starters)
- Would it help the game creation workflow if AGS assets were organized differently? (Yes, there are probably some changes that would help: e.g. break up GlobalScript and give each character/GUI its own script; let assets live on the file system so they can be edited/reorganized outside of the editor without a ton of reimporting.)
- Some vague notion of schemas? Not sure what you're getting at... (No, game templates and script modules are fine, though there could be improvements in e.g. importing GUIs, fonts, defining module API etc.)
But mostly these are not urgent issues, IMO. They can be worked out along the way, or tinkered with in subsequent versions.
Quote- Do you want a game that could be patched? How should that be organized? How will you make older savedgames be applied to the new version, which rules and algorithms will be applied, how the data conflicts should be resolved?
Sure, that's an interesting problem, and one that needs to be thought through before (re)implementing certain parts of the core engine and the savegame format, but I don't see how it's something that must be resolved before anything else (like choosing graphics libraries or whatever).
QuoteAlso, I was refering more about writing a concept document (maybe in wiki-like fashion) that would cover those topics. I am wary of quick decisions, they often lead to problems later.
I'm not convinced "quick decisions" are our most pressing problem. :-D
Quote from: Ryan Timoothy on Sat 08/03/2014 19:18:00I disagree that the goal should be to make an "adventure game" engine, the goal should be to make an easy to use game engine. The adventure part of it is an extended script of what you could do with a proper game engine.
Hey, we're done (http://libgdx.badlogicgames.com/)! Good work, team!
You could argue that much of the adventure game logic could be coded in scripts just like the game code. For example, stuff like pathfinding, deciding which view should be displayed when a character is heading a certain direction, the notion of characters having "inventories", that a particular character is the "player", how characters should scale at different positions, etc. But whatever level it's implemented at, I think you want most of this stuff to be pretty stable and standardized, even if it's
possible for game makers to modify it. Stuff like "there are characters, there are walkable areas, characters have walkcycles" etc. needs to be integrated quite tightly into the editor, to offer an intuitive and efficient workflow.
.
.
.
It's easy to get sucked into the discussion, but I'd like to reiterate that all the talking and decision-making in the world isn't going to make a difference unless someone sits down and hacks code.
Quote from: Snarky on Sat 08/03/2014 20:08:56
Quote from: Ryan Timoothy on Sat 08/03/2014 19:18:00I disagree that the goal should be to make an "adventure game" engine, the goal should be to make an easy to use game engine. The adventure part of it is an extended script of what you could do with a proper game engine.
Hey, we're done (http://libgdx.badlogicgames.com/)! Good work, team!
Engine != framework.
Quote from: Crimson Wizard on Sat 08/03/2014 14:50:05
- What kind of system/engine do you want to get done?
- What kind of users is it aimed for?
- What kind of general features should it have?
- Do you want it to be extensible, and which way?
Ironically enough, I get the feeling none of these questions are really answered by the proponents of maintaining the existing AGS codebase even though they seem to want to target somebody who they'd call "the existing AGS userbase". Like, I genuinely don't understand what is the intended audience of this endeavour would be. People who want to do
what exactly? What I'm getting at is... people who are content with all the fundamental AGS limitations, already have AGS. People who aren't however, wouldn't really be happy with another half-arsed hack added to the existing pile of hacks and probably would prefer some proper features properly implemented. Are there really that many minor flaws in AGS that can be
just fixed? Like, genuinely minor, as in not actually stemming from major mistakes in its design and implementation? Because I honestly don't know and it certainly doesn't seem that way to me. For instance, the list of "improvements" Snarky posted a few posts above clearly implies pretty much a complete (like >90%) rewrite of everything.
The bottom line is, I've seen virtually no compelling arguments or reasons here for maintaining the existing AGS code as means of achieving a successor engine so far. Not even to mention there doesn't seem to be well, anyone who actually wants to touch it, especially on a long-term basis.
Also keep in mind, that even if the community decides(tm) to go down that route, it doesn't mean other developers wouldn't continue working on their solutions. So it's reasonable to expect you'd still need to compete with freshly cleanly designed solutions in the near future. They may not come tomorrow, it's not clear what Calin's plans with Adore are, when Adventure Creator will mature and how it will turn out, or when I actually will have time to attempt to make a user-friendly devkit based on my own engine etc etc. So sure, AGS seemingly has an advantage
right now. Would it still have it in, say half a year from now, even with continued maintenance? A year? Just make sure you don't have to regret your answer to that question. Because whatever your opinion on what is the best course of action for AGS is, you have to realize that projects with more clean and modern foundations
and connected to actual game development will be moving at a much faster pace than the refactoring & rehacking & maintenance of AGS. Writing stuff "from scratch" takes a lot of time but in my humble opinion spending more time sucks less than spending some lesser time in vain. Don't say I didn't warn you that your own target audience may eventually run away once something more practical presents itself, which can be pretty damn frustrating. Just saying.
So I daresay, if you really really want to have some open source "community engine" as some kind of future-friendly defacto solution, assemble together and make one properly, instead of trying to keep a previously proprietary product afloat indefinitely and at all costs. Because all the talk about the importance of open source is frankly a bit amusing when what is holding us back here is essentially some legacy code that was proprietary the most of its lifecycle.
And with that said, I find tzach's and Monsieur OUXX's proposals very intriguing.
Quote from: Snarky on Sat 08/03/2014 20:08:56
This sounds a bit like reinventing the wheel to me. Are these actual problems people have with AGS the way it is now? If not, why mess with it?
If you're afraid that the relevant people voicing opinions on how they want adventure game development to be structured may turn out to clash with what AGS does now, then yes, it's an actual problem admitted by your own implication, surely?
Quote from: Ryan Timoothy on Sat 08/03/2014 20:20:55
Quote from: Snarky on Sat 08/03/2014 20:08:56
Quote from: Ryan Timoothy on Sat 08/03/2014 19:18:00I disagree that the goal should be to make an "adventure game" engine, the goal should be to make an easy to use game engine. The adventure part of it is an extended script of what you could do with a proper game engine.
Hey, we're done (http://libgdx.badlogicgames.com/)! Good work, team!
Engine != framework.
I don't know Ryan. We both tweaked AGS for our own needs (non-adventurey needs), but really, I guess without a focus on Adventure Games we are just another MMF/GameMaker. Focus of course doesn't mean exclusive, but still, how would we stand in a quite saturated market?
Quote from: Snarky on Sat 08/03/2014 16:41:06
Quote from: Crimson Wizard on Sat 08/03/2014 14:50:05
- What kind of system/engine do you want to get done?
Like AGS v3, only better.
A free, open-source engine and accompanying dev tools to make traditional (bitmap-based) 2D adventure games in any resolution from 320x200 and up, to run on a variety of platforms (targeting Windows, Mac OSX, Linux, iOS, Android), with enough power and flexibility to accommodate most of the ideas and ambitions found among AGS game developers.
Quote- What kind of users is it aimed for?
-Current AGS users
-Amateur and hobbyist adventure game creators
-Semi-professionals (often working in teams)
-Small commercial indie developer studios
It should be accessible to newbies (e.g. easy to install, run and start working with), and not have too high a learning curve for people without much programming experience.
The players of the produced games would generally fall into two camps:
-Enthusiasts (those familiar with the engine, somewhat computer-savvy)
-General audience (for whom we may assume basic computer and computer game-literacy but no more)
Quote- What kind of general features should it have?
Well, it should generally have the features and capabilities AGS currently has (though not necessarily offered in precisely the same way).
Possible exceptions:
DELETED - NOT THE PART I AGREE WITH.
Functional enhancements over the current AGS version (with possible implications for the architecture/library choices) would include:
-More flexible graphics rendering (e.g. resize, switch windowed/full-screen on the fly)
-Improved graphics rendering in general (performance, consistency, compatibility, hardware support)
-Better/more convenient multi-platform support, particularly for porting/deploying games on iOS/Android
-Improvements to the scripting language (or replace it with a different language) and script organization
-Improved compile speed, better efficiency in updating game projects
-A better file format for compiled games (per Calin and BigMc)
-Better support for patching games (without breaking savegame compatibility)
-Unicode support
Stuff like support for shaders, filters, subpixel rendering, etc. are also worth keeping in mind. Support for vector graphics and 2.5D games should be at most a secondary concern, IMO.
ALSO DELETED AS NOT NEEDED FOR MY POINT.
I agree with these answers. I think the question, as CW pointed out, should be that we realize what the final goal is. I think for that, it is important that we do have a vote on what we want out of AGS. As for the development libraries... As end users we may have a preference, but the developers need to decide on that. So the developers alone should vote on that. If it helps get us going in the right general direction, without reading through hundreds of posts, would this link help us at all: http://pub46.bravenet.com/vote/vote.php?usernum=3951325376 ? It is a survey of some basic functionality wanted from AGS and it is directed 90% at game developers/players and 10% towards development. The 10% of that comes with the intent that if someone could help, in which way and with what languages. Take a gander at it and see what you think. Maybe this can start to give us a clearer idea of where to head. If you think other questions should be on there, let me know and I will add it.
@Bici: Everything everyone mentions should be present in a proper game engine.
Quote from: Snarky on Sat 08/03/2014 20:08:56
But whatever level it's implemented at, I think you want most of this stuff to be pretty stable and standardized, even if it's possible for game makers to modify it. Stuff like "there are characters, there are walkable areas, characters have walkcycles" etc. needs to be integrated quite tightly into the editor, to offer an intuitive and efficient workflow.
- Every game engine should have characters.
- Walkcycles, which would be made with the animation editor, would also be required and the direction in which a character moves is indicative of what walkcycle animation they use.
- Walkable areas would also need to be present in a proper game engine, plus scaling to simulate distance, not only just in sprite size, but in distance the character moves vertically != distance moved horizontally.
- GUI. Every game needs the ability to have a GUI.
Now what does the standard adventure game have that a "game" with the above standard elements doesn't? Inventory, Verb interactions, Talking, Dialogs. That's all, am I missing anything? And these elements shouldn't be as hardcoded as AGS already makes them.
Am I saying AGS needs to be completely rewritten into a new engine? It wouldn't hurt. With the amount of libraries out there, it shouldn't be hard to get the fundamentals integrated into the newly made engine (or an opensource equivalent).
Quote from: Snarky on Sat 08/03/2014 20:08:56
Quote from: Crimson Wizard on Sat 08/03/2014 18:09:03
I have a fear that I am not well understood again. Maybe that's because I didn't explain very well.
For example, I think that it is a wrong path to take current AGS as a starting point and think of new engine as something that improves it.
Well then I think we're coming at it from completely different points of view, because IMO the whole point is to take AGS as a starting point!
Well, true, and honestly I think I lost what is being discussed here, whether it is writing new engine, or reimplementing old one, or improving old one. These are so different ideas, each should be approached differently.
Quote from: Snarky on Sat 08/03/2014 20:08:56
I'm much less interested in asking "what is an adventure game?" or "what is the abstract structure of a game in general?" or "what if you could define data schemas?" than with the pragmatic questions of "how can we tweak the current design to help people make games more quickly/easily?"
I am not considering an immediate project, but rather sharing my thoughts on general problem.
Why do you think that "tweaking current design" will "help people make games more quickly/easily" better than creating new design?
Where does this "reinventing of wheel" comes from? What if the wheel we have now is not the best wheel?
We were so inclined to tweak the same old AGS more and more; but I wished we could take time, step back and observe the object from distant perspective.
Quote from: Snarky on Sat 08/03/2014 20:08:56
Some vague notion of schemas? Not sure what you're getting at...
Sorry, I was tinkering with this idea... yes you could say templates, but in more general sense, like a preset for classes and types of game elements, such as speech styles, GUI styles, etc.
Quote from: Snarky on Sat 08/03/2014 20:08:56
It's easy to get sucked into the discussion, but I'd like to reiterate that all the talking and decision-making in the world isn't going to make a difference unless someone sits down and hacks code.
You see,
this exactly what scares me of. I don't want to see AGS project return to tweaking and hacking. I keep trying to urge you to step back and think about approach, but with no avail. Maybe it's just not what people want...
Quote from: qptain Nemo on Sat 08/03/2014 20:26:01
Like, I genuinely don't understand what is the intended audience of this endeavour would be. People who want to do what exactly? What I'm getting at is... people who are content with all the fundamental AGS limitations, already have AGS. People who aren't however, wouldn't really be happy with another half-arsed hack added to the existing pile of hacks and probably would prefer some proper features properly implemented.
I don't usually do this, but... +1 :)
Quote from: qptain Nemo on Sat 08/03/2014 20:26:01
Ironically enough, I get the feeling none of these questions are really answered by the proponents of maintaining the existing AGS codebase even though they seem to want to target somebody who they'd call "the existing AGS userbase". Like, I genuinely don't understand what is the intended audience of this endeavour would be. People who want to do what exactly? What I'm getting at is... people who are content with all the fundamental AGS limitations, already have AGS.
How about people who like the basic way in which AGS lets you make adventure games, but don't like all the limitations of the current version in terms of platform support, relying on DirectDraw and old Direct3D, shortcomings in the scripting language, and all the other things people have been asking for and complaining about for years?
QuotePeople who aren't however, wouldn't really be happy with another half-arsed hack added to the existing pile of hacks and probably would prefer some proper features properly implemented. Are there really that many minor flaws in AGS that can be just fixed? Like, genuinely minor, as in not actually stemming from major mistakes in its design and implementation? Because I honestly don't know and it certainly doesn't seem that way to me. For instance, the list of "improvements" Snarky posted a few posts above clearly implies pretty much a complete (like >90%) rewrite of everything.
You're confusing yourself over two different things. One is where we want AGS to get to, in terms of architecture, design and functionality. The other is how to get there (by gradually rewriting and refactoring the current code, or starting from scratch). We've been over the arguments about the second point (where the idea is certainly not to add "another half-arsed hack", but rather to start fixing the hacks that are currently in there), but CW argued that we first need to decide these other things. Therefore, I was giving my two cents on what the "ideal AGS 4.0" should be like.
QuoteThe bottom line is, I've seen virtually no compelling arguments or reasons here for maintaining the existing AGS code as means of achieving a successor engine so far. Not even to mention there doesn't seem to be well, anyone who actually wants to touch it, especially on a long-term basis.
*shrug* Like I've been saying, it really doesn't matter what any of us think unless someone is going to do something about it. The only vote that counts is voting with code.
QuoteAlso keep in mind, that even if the community decides(tm) to go down that route, it doesn't mean other developers wouldn't continue working on their solutions. So it's reasonable to expect you'd still need to compete with freshly cleanly designed solutions in the near future. They may not come tomorrow, it's not clear what Calin's plans with Adore are, when Adventure Creator will mature and how it will turn out, or when I actually will have time to attempt to make a user-friendly devkit based on my own engine etc etc. So sure, AGS seemingly has an advantage right now. Would it still have it in, say half a year from now, even with continued maintenance? A year? Just make sure you don't have to regret your answer to that question. Because whatever your opinion on what is the best course of action for AGS is, you have to realize that projects with more clean and modern foundations and connected to actual game development will be moving at a much faster pace than the refactoring & rehacking & maintenance of AGS. Writing stuff "from scratch" takes a lot of time but in my humble opinion spending more time sucks less than spending some lesser time in vain. Don't say I didn't warn you that your own target audience may eventually run away once something more practical presents itself, which can be pretty damn frustrating. Just saying.
I find this prospect profoundly un-scary. Indeed, a future where people have all these great engines to choose from sounds great. But if this future is so certain, why bother with this at all? Why not just sit back and wait for a better engine to come along?
And if you don't think AGS is usable as a starting point for a good, competitive modern adventure game studio/engine (even if the actual code is rewritten), why even care about it? Complete that devkit and you have the engine of your dreams, right?
QuoteQuote from: Snarky on Sat 08/03/2014 20:08:56
This sounds a bit like reinventing the wheel to me. Are these actual problems people have with AGS the way it is now? If not, why mess with it?
If you're afraid that the relevant people voicing opinions on how they want adventure game development to be structured may turn out to clash with what AGS does now, then yes, it's an actual problem admitted by your own implication, surely?
Afraid? No, I just think it's mostly besides the point, and certainly not something that should hold up other more pro-active steps.
Quote from: Crimson Wizard on Sat 08/03/2014 21:17:40
Well, true, and honestly I think I lost what is being discussed here, whether it is writing new engine, or reimplementing old one, or improving old one. These are so different ideas, each should be approached differently.
Perhaps. So to keep things straight, what if we postulate that in
this thread, we're talking about "AGS 4.0", an engine that (no matter how it is implemented) bears significant similarity to AGS 3.x in terms of adventure-game-making concepts, and generally follows the design of AGS 3.x in the aspects that people don't consider currently broken? (Part of the discussion can certainly be whether there's any "market" for an AGS 4.0 like that.)
Then if people want to talk about a potential new engines/dev tools that don't really have anything to do with AGS either in design or implementation, maybe that should be broken out into a separate thread?
QuoteI am not considering an immediate project, but rather sharing my thoughts on general problem.
Why do you think that "tweaking current design" will "help people make games more quickly/easily" better than creating new design?
Where does this "reinventing of wheel" comes from? What if the wheel we have now is not the best wheel?
We were so inclined to tweak the same old AGS more and more; but I wished we could take time, step back and observe the object from distant perspective.
Well, my background is in User-Centered Research, and (simplifying somewhat) one of the basic insights of that discipline is that you're more likely to come up with a good design by going out and listening to the problems users are having, than by abstract contemplation. Which is not to say that the best design is always to deal with each little problem in isolation, but that the first question is not "so what should the design be?" but "what are the problems we want to address?" All this "taking a step back to think about the design" feels wrong to me because it's not tied to any particular (identified) problem in the user experience.
I guess another way to look at it is that we have a pretty good idea of what the AGS user experience is like, and what the pain-points are. If you're proposing something entirely different, it's much harder to tell what it would actually be like to use it. Until you have people playing (err... working) with it, it's all hypothetical, and until you've had a handful of people actually make a game with it, it's still experimental. Maybe it would be great, but before we throw away all the design iterations that have led to AGS, I'd like to at least see a proof-of-concept, you know?
QuoteQuote from: Snarky on Sat 08/03/2014 20:08:56
It's easy to get sucked into the discussion, but I'd like to reiterate that all the talking and decision-making in the world isn't going to make a difference unless someone sits down and hacks code.
You see, this exactly what scares me of. I don't want to see AGS project return to tweaking and hacking. I keep trying to urge you to step back and think about approach, but with no avail. Maybe it's just not what people want...
For the record, "hacking code" is not the same as "writing hacky code".
Quote from: Crimson Wizard on Sat 08/03/2014 14:50:05
- What kind of system/engine do you want to get done?
- What kind of users is it aimed for?
- What kind of general features should it have?
- Do you want it to be extensible, and which way?
> System : same as now. An Editor that's easy to install, and distributable games. Easy to use. Not necessarily very optimized, but fun.
> users : same as now: the niche of old-school point n click lovers. the people who used AGS so far should feel comfy with the new one.
> general features: same as now, but with the ability to be pimped up, to, let's say, something like the Runaway series -- (and possibly the Telltale Sam&Max series, but with plugins). Also, make collaborative work easier.
> extensible: like now, with plugins and stuff, but "more naturally". By that I mean: Spend less time coding weird object arrays and half-featured guis. Most of the stuff should be handled internally in a very abstract way (e.g. characters extend entities just like inventory objects do), a serializable way (clean programming and retro-compatibility, with proper data structures), a vectorized manner (e.g. no more obsolete pixel-based pathfinding), a 3D approach, even for 2D (e.g. 2D sprites are a billboard, which immediately enables 2.5D, but the regular user doesn't even know)
Quote from: Snarky on Sat 08/03/2014 21:27:11
How about people who like the basic way in which AGS lets you make adventure games, but don't like all the limitations of the current version in terms of platform support, relying on DirectDraw and old Direct3D, shortcomings in the scripting language, and all the other things people have been asking for and complaining about for years?
You're confusing yourself over two different things. One is where we want AGS to get to, in terms of architecture, design and functionality. The other is how to get there (by gradually rewriting and refactoring the current code, or starting from scratch). We've been over the arguments about the second point (where the idea is certainly not to add "another half-arsed hack", but rather to start fixing the hacks that are currently in there), but CW argued that we first need to decide these other things. Therefore, I was giving my two cents on what the "ideal AGS 4.0" should be like.
Yeah, but I have to reiterate my question: how many of those feature requests are actually minor fixes that don't require such huge long-term reworking that is ultimately equivalent to a full rewrite? That can actually be reasonably done iteratively without major headache over trying to keep it all functional midway somehow and dodging all the nightmarish bugs arising from the process of such transition? E.g. you make "script language improvements" sound like just another relatively painless and trivial task that can be tackled in baby steps. Does AGS actually allow for that?
Quote from: Snarky on Sat 08/03/2014 21:27:11
I find this prospect profoundly un-scary. Indeed, a future where people have all these great engines to choose from sounds great. But if this future is so certain, why bother with this at all? Why not just sit back and wait for a better engine to come along?
Even though clearly sarcastic, that's a perfectly valid question. I'm guessing the primary reasons would be that it's still entirely possible that none of the alternative solutions will appear and the AGS community may end up with nothing. And the fully understandable desire to have a "community engine" that is authored, owned, controlled etc by the community. And so, I wasn't arguing towards cancelling the idea entirely, but rather considering the circumstances of its execution. Which I think is a valuable perspective.
Quote from: Snarky on Sat 08/03/2014 21:27:11
And if you don't think AGS is usable as a starting point for a good, competitive modern adventure game studio/engine (even if the actual code is rewritten), why even care about it? Complete that devkit and you have the engine of your dreams, right?
Please don't get me wrong, I don't have any petty stake in this. Indeed, I already almost have the engine of my dreams and I don't particularly care about AGS. Furthermore, I'd like to share my engine eventually because why not, but it was never a priority, never will be and I still don't care about its adoption by a wider userbase. What I care about here is AGSers and I speak purely out of concern for them. I really like the community, I consider myself a part of it and so I suggest what I think are reasonable arguments to consider, that's all.
Quote from: Snarky on Sat 08/03/2014 22:00:28
my background is in User-Centered Research, and (simplifying somewhat) one of the basic insights of that discipline is that you're more likely to come up with a good design by going out and listening to the problems users are having, than by abstract contemplation.
I understand better where you're coming from, now.
OK then, in that case, the questions asked by CW are a perfect starting point: targetted users and main features offered.
Then maybe we could produce some Editor mockups? Not for eye candy or to be taken as actual specs, but for people to point out what features they think should be there and are obvisouly missing from the mockup.
Quote from: Crimson Wizard on Sat 08/03/2014 14:50:05
- What kind of system/engine do you want to get done?
- What kind of users is it aimed for?
- What kind of general features should it have?
- Do you want it to be extensible, and which way?
For me it's clear that AGS should stay AGS. Even though the new AGS is completely rewritten in a different language, it should still have the same features, target the same people and have the primary purpose on developing adventure games.
What I'm proposing is a AGS that is totally differently implemented than the original AGS to conform to todays development standards but still be substantially similar to the original AGS for the end developer and player.
Quote from: Snarky on Sat 08/03/2014 22:00:28
Well, my background is in User-Centered Research, and (simplifying somewhat) one of the basic insights of that discipline is that you're more likely to come up with a good design by going out and listening to the problems users are having, than by abstract contemplation. Which is not to say that the best design is always to deal with each little problem in isolation, but that the first question is not "so what should the design be?" but "what are the problems we want to address?" All this "taking a step back to think about the design" feels wrong to me because it's not tied to any particular (identified) problem in the user experience.
The project scope versions the product scope, that is stuff they have learned me at university and it is funny to see that going on in practise. :D Basically developers think about the how by default and it is hard for them to see the what. For users this is the other way around: the have functional requirements but do not think about how that should be done. Basically those groups well keep talking different languages until a project manager steps in to link both scopes. There might even be more roles: game develops, game users, editor developers, engine developers, plugin developers, module developers, etc.
For product development it all about trying to solve a problem, so it would first find a problem, then find a solution and then make people aware of that solution. A developer or inventor has a solution but tries to find a problem really. :D
I can see you come form the other perspective since I've thus far only heard "how's" instead of "what's". As for your perspective it is good to know that refactoring code is conceptionally easy (the concept does not change) but is technically very hard (requires skilled developers and costs a lot of time).
Anyhow, carry on!
I was keep thinking in the past few days, and I want to tell that I probably will be able to maintain existing engine some more, just spending less time. The work on 3.3.1 is still going on (Gurok making some additions), and since I know some quirks of AGS better, I will have to help sometimes anyway.
This way you guys will hopefully may focus on new development (if that is really what you are planning to do).
Quote from: Crimson Wizard on Sun 09/03/2014 15:53:57
I was keep thinking in the past few days, and I want to tell that I probably will be able to maintain existing engine some more, just spending less time.
This is extremely welcome news!
edit: and kind of falls into what Wyz was planning
Quote from: Crimson Wizard on Sun 09/03/2014 15:53:57I was keep thinking in the past few days, and I want to tell that I probably will be able to maintain existing engine some more, just spending less time.
Awesome news CW!
Thx again for your past and future work ;)
I'm also glad to read this abondant discussion about the future of AGS in order to make it still attractive and competitive.
Btw, I was wondering: could a (small) Kickstarter campaign be a way to propose a kind of indemnity (not salary) to our courageous coders and our great leader project (CW)?
Without questioning the do-cracy nor the open source side, it could unite and expand the community and motivate coders.
AGS won't become a greedy money whore business, it's just a way to thx coders and speed up the development.
So AGS 4.0 could become true before 2020 ;)
Quote from: Atavismus on Sun 09/03/2014 19:00:09
Btw, I was wondering: could a (small) Kickstarter campaign be a way to propose a kind of indemnity (not salary) to our courageous coders and our great leader project (CW)?
Lol, no, please don't do that (speaking for myself) :). I find myself almost not encouraged by money, quite contrary, I see money as a contract which just adds obligations, which I don't really like :D.
Quote from: Crimson Wizard on Sun 09/03/2014 19:54:12Lol, no, please don't do that (speaking for myself) :). I find myself almost not encouraged by money, quite contrary, I see money as a contract which just adds obligations, which I don't really like :D.
Lol, ok, no problem, do it for free so :D
I'm sure some coders will need your part ;)
More seriously, I totally understand your point (I share it myself), but maybe it could be useful for some other people (temporary unemployed people for example, or student, or freelancer in period of under-occupation, etc.).
Also, as I said, no "democracy" or "accountability", you people stays in do-cracy ;)
Quote from: Crimson Wizard on Sun 09/03/2014 19:54:12
Lol, no, please don't do that (speaking for myself) :). I find myself almost not encouraged by money, quite contrary, I see money as a contract which just adds obligations, which I don't really like :D.
Spoken like a true CJ!
Yes, I believe CW is the second incarnation of God. Ags will arrive to the holy land.
Quote from: miguel on Mon 10/03/2014 11:42:28
Yes, I believe CW is the second incarnation of God. Ags will arrive to the holy land.
Err... can you please stop doing this :(
Quote from: Crimson Wizard on Mon 10/03/2014 14:22:23
Quote from: miguel on Mon 10/03/2014 11:42:28
Yes, I believe CW is the second incarnation of God. Ags will arrive to the holy land.
Err... can you please stop doing this :(
There are wizards who are dying to be worshiped and here are you, Crimson Wizard, refusing your worshiping even when the people are willingly doing it. (laugh)
I totally get CW. There's praise and then there is too much. But the point is we appreciate all the work that CW, CJ, JJS, and everyone else's name is not abbreviated ;)
I'll just add my $0.2 from the perspective of the (very) small commercial studio demographic.
Toward the continued development of AGS 3: I have seen the newest builds make leaps and bounds toward the engine I desperately need and want for Jack Houston and the Necronauts. Running the game for the first time in 1920x1080 using CW's CustomRes branch was nothing short of a religious experience. I feel that if vsync can be added back in for D3D, the engine will be exactly where I need it for now. I can get around the speed limitations. I would love to see the engine receive more tweaks and bug fixes for a while, because I can see myself using 3.x for the next year or two if need be.
As for the possibilities with a new AGS 4: I have to agree with Snarky that I don't think anyone wants to see the fundamentals of the AGS development environment change, with the exception of perhaps a more 21st century OO scripting language. I love the editor, and I think the features and the way they work have been refined so sharply over the years that they have become the major draw for me with AGS. I would pay for a better engine if there were one, but when it comes to the structure of AGS, the features it has and the ease of implementation, money cannot buy a better environment for making adventure games. If I jumped ship tomorrow for Unity (which I am currently looking at as a possibility for the long run) or one of those other "adventure makers", a major disadvantage is it would mean losing all the years of refinement that has made AGS a joy to use. This is why I think it's imperative that the basic structure of the AGS editor and development features remain spiritually in tact.
And this brings me to my final point. Although I can understand, in theory, the idea of a generic AGS 4 aimed at making "any kind of game", I think this would be absolutely detrimental to AGS. It is, after all, ADVENTURE game studio. Unity is designed to accommodate any kind of game. AGS remains a light and streamlined system because it is aimed at doing a particular thing, and it does it EXTREMELY well. I don't really think there would be anything to gain by putting in the extra work to accommodate other game genres. In fact I think it would greatly damage the usefulness of AGS for doing what it was designed to do: emulate Sierra & LucasArts adventure games. Just think of the editor and how it's laid out: text parser, lip sync, dialogs, rooms, translations, all these things were developed specifically for creating adventure games. Although it is possible to hack AGS a bit and create other kinds of games, which is perfectly cool, I do enjoy the fact that it is tailor made specifically for adventure games. I think everyone does.
Therefor, I would think that writing up a wiki to outline the desired goals for an AGS 4 would need to start with outlining all the things AGS does right (which is, above the hood -- I.E. to the end user -- , 90% of it IMO). Then creating a road map for getting to those results by way of more modern and efficient means, on a technical level, so that when you do reach the complexity level of, say, resolution, you don't hit any roadblocks.
I can't comment to much beyond this as I'm not a contributing programmer, but that is how I'm seeing it from my particular side of the fence.
As someone who just uses the engine for hobby purposes but has considered selling a few small games in the next year or so...
I've played with Construct 2, Stencyl, Unity, AGS, and Game Maker 8 and I can say without a doubt that for point and click games AGS is by and large the easiest to use and most enjoyable to work with. Even with the limitations it supposedly has, I've seen people make metal gear style stealth games, straight up bullet hell games, fighting games, GTA clones, and one of the coolest platformers I've played in the last three years (Art of Dying) with what is claimed to be a dated engine, and most of those games mentioned with the exception of AoD were done two years ago or more.
I'd be sad if AGS went the way of Unity or other game design tools and didn't keep it's simple to use interface. (not that it's necessarily being discussed, I'm just giving my .02)
As for free vs pay, I have zero problems paying for something I use regularly. My only, ONLY gripe with AGS is that it doesn't easily or perfectly port your games to Linux/OSX without some serious help. If that one issue was resolved I'd pay for a licensed version in a heartbeat. I don't personally care about android/ios integration but that's just me.
Whatever happens, I wish all the devs the best of luck and if there's a cost associated I've got no problem throwing some cash at the finished product.
I can't programme, so I'm not sure if my input is needed but I 100% agree with Stacy.
Quote from: Stacy Davidson on Tue 11/03/2014 06:05:04
Running the game for the first time in 1920x1080 using CW's CustomRes branch was nothing short of a religious experience. I feel that if vsync can be added back in for D3D, the engine will be exactly where I need it for now. I can get around the speed limitations. I would love to see the engine receive more tweaks and bug fixes for a while, because I can see myself using 3.x for the next year or two if need be.
I tested out some of our latest game in 1080 and it blew me away!
I love the CustomRes version, and with with Vsync already in the 3.3.1 test build! both of this together would make me so happy for a couple of years to come :)
the reason I picked AGS to work with to make adventure games is that within a short time you can learn the basics and make a game very easily and I hope that is something that wont change!
Edit: oh yer.. and its free ;) not that I'm not willing to pay for some software.. I am
Quote from: Soxbrooker on Tue 11/03/2014 18:33:31
the reason I picked AGS to work with to make adventure games is that within a short time you can learn the basics and make a game very easily and I hope that is something that wont change!
This to me is the most important thing of all. AGS simply must remain accessible to newcomers. I'm sure everyone already knows this, 'dont scare away potential newcomers' has to be the single most important mantra to bear in mind at every single stage of development of any new version of AGS, whatever form that may take.
Great discussion.
One of the things that sets AGS apart in my mileage is its ability to easily and accurately emulate the 320x200 classic adventure. I have taken almost every other game making tool for a test drive, and only AGS fits the bill. While more modern adventures are a "patch and hack" for AGS, the opposite is true for most of the other engines. In my mind, this is the default, narrow genre of the tool. We're partying like it's 1991! :-)
Just one man's opinion, obviously.
But in my mind, this is more than a mere technical decision to support low resolution pixel art. It's been the core focus of the tool. I would suggest the following mission statement based solely on my perception of our use of the tool:
AGS is a tool that exists to give technically able artists the ability to keep the Golden Era of adventure games alive with new content, contests, and community.
AGS must look forward, not back. If 320x2x0 can be implemented without holding back AGS, then keep it. Otherwise, it should stay with the existing versions and be dropped going forwards. While yes, a "do it all" tool from VGA resolution up to (and beyond) 1080p would be nice, it shouldn't be at the cost of functionality.
Whatever, whoever, decides the future path of AGS isn't going to please everyone - and they definitely shouldn't try to.
Quote from: Sslaxx on Thu 13/03/2014 15:31:40
AGS must look forward, not back. If 320x2x0 can be implemented without holding back AGS, then keep it. Otherwise, it should stay with the existing versions and be dropped going forwards.
Strongly disagree. 320x200/240 is an essential feature, as demonstrated by the large number of AGS games released in this format (it's more popular, I daresay, than any of the other resolutions available). Plus as TheBitPriest says, it's one of the things that sets AGS apart from any of the other available alternatives.
Theres no reason 320x2x0 should be dropped. The new system just needs to be resolution agnostic and allow the game maker to choose the filter used for scaling. We already have this to some degree.
Is there any real reason to even use full screen nowadays? "Borderless windowed" (as in adapting the game's resolution to the desktop as opposed to adapting the desktop resolution to the game's resolution) is so much better.
Interesting talk.
I actually ceased all work on my engine (based on HTML5 and Node Webkit with some Haskell glue code) due to re-discovering AGS and finding out that the editor works well under Linux.
Is the situation really this bad? I mean, I'm all for efficiency. But hardware is evolving all the time, so shouldn't we be able to get away with some inefficiencies in the stack?
@Daniel Eakins
It's kind of a design choice, I assume. Borderless windows eat up more resources, but fullscreen is less responsive during the process of switching to another application.
I'm in full agreement with what Snarky and Stacy are saying. Building an entirely new AGS4 and discarding all of the coding tweaks and iterations that have been tried-and-tested over the past decade seems like an overly ambitious task which risks running out of steam before all those little touches could be fully tested and re-implemented. Even if an exact facsimile engine was created, it'd likely be many years before it saw full completion, by which time, the most ardent/serious AGS developers will already have moved onto Unity or other feature-complete engines. Additionally, for developers who have large, existing projects, a brand new AGS4 would pretty much put them dead in the water - being forever stuck in 3.3, unable to be updated and take advantage of the newer engine's technology/features. This would have a pretty severe impact on commercial AGS games that are already available on services like Steam, as outdated AGS titles could no longer be updated and will only grow increasingly incompatible over time; to the point where they'd eventually need to be removed from the sale on the service.
About backwards compatibility being broken: as someone who has several large AGS projects dating back to 2000, which use a crapload of legacy code, I can say that yes, it would be a pain in the ass to update huge amounts of it to new code that does the same thing in an enhanced engine. For example the day-night fading cycle in our Quest for Glory 2 remake relies on numerous legacy RawDraw functions that could introduce bugs all over the place if updated. However, even though this is the case, 100% backwards compatibility still isn't overly important to me. Any developer who has an affected AGS game, which they need to keep up-to-date, is going to ensure that their project is using the latest functions and update accordingly if they get compile errors. It'd take me what - maybe a few days at most to update all those legacy code instances to the new code and then maybe a week to test it all thoroughly. In my view, refactoring 3.3 and breaking backwards-compatibility for the sake of maintaining the sanity of those working on the code is preferable to having a brand new engine that I can't even update the game to at all. Besides, there will always be the 3.3 engine if people want to play ancient AGS games. It just doesn't seem to make much sense to make backwards-compatibility with "Larry Vales" take preference over the modern needs of the engine and its userbase, giving the programmers aneurysms in the process.
The problem seems to be information overload. Some people have suggested that AGS should be a fully-integrated development system that can handle all types of games if it is to have any future. But I'd argue that this makes it just another cookie cutter engine that robs it of CJ's vision and goes against what so many current developers rely on it to do well. Of the handful of devs who create serious games with AGS, is this really worth the time investment? And what of AGS's legacy - ostracizing existing AGS developers at the expense of attracting larger crowds doesn't seem like a good way to go and makes even less sense when there's no financial motivation to do so. Now, that's not to say AGS shouldn't eventually be capable of creating other types of games... just that this shouldn't be considered as a crucial priority until the source is in a more stable state. Lofty visions divert attention and misdirect focus. AGS shouldn't try to be too much too soon. There are other engines that cater to developing all sorts of games, but AGS is, and always has been, an adventure game tool - keep it focused.
My 2 satang: If I were approaching this the same way I usually approach working on a mammoth game project, I'd identify the biggest hurdle first, regardless of how mundane it is, and work through it to make a stable foundation for building other additions/improvements. And I would not stop until that's done. With AGS3.3, the current hurdle seems to be the daunting task of refactoring of the messy code. I know that's not a fun task, and seems like a lot of time-consuming work for little reward, but at the end of the process, wouldn't the result essentially be that we'd end up with a clean, enhanced version of 3.3 with all the same flexibility and functionality of the clean AGS4 that's being proposed? If refactoring the current code is being considered, then the focus should probably remain on achieving that goal without adding any new engine features until it's done. I think we could all agree to make that sacrifice if it meant this issue becomes a thing of the past.
Regarding crowdfunding and paying a programmer to refactor the source code, I think that could be a good idea. I know CW said that, as a community member, he's personally not comfy with the idea of having an obligation, and I understand where he's coming from. But on the other hand, with a programmer hired from Elance.com, where I have had some good experience, or a similar site (preferably where you can rate their performance and value for money) the "obligation for payment" aspect may be precisely what's needed in order to have this task taken seriously, and see the work get done in a reasonable timeframe. Most people here understandably can't invest huge amounts of time to AGS development because they work other jobs and treat this as a hobby. Whereas hiring an experienced programmer who would make this their day job for a few months would ensure that the job gets taken seriously. Of course, there would first need to be a decision made about the direction for the engine to go in so that a hired programmer could be given a definitive roadmap to follow.
QuoteRegarding crowdfunding and paying a programmer to refactor the source code, I think that could be a good idea. I know CW said that, as a community member, he's personally not comfy with the idea of having an obligation, and I understand where he's coming from. But on the other hand, with a programmer hired from Elance.com, where I have had some good experience, or a similar site (preferably where you can rate their performance and value for money) the "obligation for payment" aspect may be precisely what's needed in order to have this task taken seriously, and see the work get done in a reasonable timeframe. Most people here understandably can't invest huge amounts of time to AGS development because they work other jobs and treat this as a hobby. Whereas hiring an experienced programmer who would make this their day job for a few months would ensure that the job gets taken seriously. Of course, there would first need to be a decision made about the direction for the engine to go in so that a hired programmer could be given a definitive roadmap to follow.
+1
Count me in.
I don't get why people suggest that a new application is needed to support non-adventure games. AGS already supports non-adventure games; there is even a yearly AGS award for "best non-adventure game". I've seen platform games, RPGs, shoot-em-ups, puzzle games, and board games all made in AGS. So I'm really not seeing the issue here.
Quote from: Gurok on Sat 22/03/2014 16:34:31
Quote from: miguel on Sat 22/03/2014 16:30:41
+1
Count me in.
And my axe! (Or $100)
I'd be in too, and get people I know to contribute as well. Good idea!
GD2, Miguel, Gurok, Knox, thank you: I feel less alone with the crowdfunding idea. :)
(As a french, I'm discussing on the french AGS forum if people would be ok with this idea.)
But what motivates an unpaid dev, if everyone else gets a paycheck?
How about the bounty idea? Some people (or an indie studio *cough*) offer a bounty for a certain feature and freelance-devs can claim it by implementing the feature. In the meantime, the regular development continues as it currently does. Maybe with a bit less energy-drain from CW ;)
abstauber, I was thinking that maybe one or two paid devs should be enough to accomplish our goals. Not everyone. We would be paying for dedicated time into a project and it could be someone from the community, of course.
This is just my opinion, but unpaid devs motivation would be exactly the same.
I also worry that paying for devs would demotivate open-source contributors, though that would be more of a concern if we had more active contributors. The bounty might be a better idea if we conceive it as an ongoing thing, but if the big problem is just "we need to refactor the code properly before moving forward, but refactoring is a ton of tedious work", that could potentially be a job we hire someone for. (Though of course we'd still need someone to actually look over the changes, probably even work out the desired code architecture before the hired hand could proceed.)
If this happens I would certainly be happy to chip in.
Post deleted.
Sorry, nevermind.
Quote from: miguel on Sat 08/03/2014 11:56:29
I say that only a small percentage of (ANY engine, unity, game maker, etc) users are capable of releasing good games. And add to that saying that IT IS NOT the engine that makes good games but the people and their work.
PREACH BROTHER MIGUEL! (nod)
Amen, dude! :)