AGS: Let's start over?

[bicilotti]

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

[Snarky]

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

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

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

- 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

[Wyz]

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

[Crimson Wizard]

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.

[Radiant]

This article by Joel Spolsky strikes me as very relevant to the discussion here. It's not that long, and highly recommended!

[Ryan Timothy B]

This article by Joel Spolsky strikes me as very relevant to the discussion here. It's not that long, and highly recommended!

As explained in this classic article.

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.

[Snarky]

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.

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

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?

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.

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

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.

I'm not convinced "quick decisions" are our most pressing problem.

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.

Hey, we're done! 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.

[Ryan Timothy B]

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.

Hey, we're done! Good work, team!

Engine != framework.

[qptain Nemo]

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

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?

[bicilotti]

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.

Hey, we're done! 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?

[Joseph DiPerla]

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

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

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

[Ryan Timothy B]

@Bici: Everything everyone mentions should be present in a proper game engine.

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

[Crimson Wizard]

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.

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.

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.

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

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

[Snarky]

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?

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.

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.

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.

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

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.

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?

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.

[Snarky]

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?

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.

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?

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

[Monsieur OUXX]

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

[qptain Nemo]

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?

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.

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.

[Monsieur OUXX]

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.

[Lt. Smash]

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

[Wyz]

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