Define a project goal

[morganwillcock]

To resolve #762, to then resolve #757, the primary goal of AGS needs to be defined. At the moment the position of any future development is not clear, and any change is potentially deemed to a move in an incorrect direction.

I'll leave some relevant text from the website here, which is probably the closest thing to a goal that exists for the moment:

Adventure Game Studio (AGS) provides the tools to make your own adventure, for free! Bring your story and artwork and slot it in, and let AGS do the rest. AGS provides everything you need from within one easy-to-use application. Create, test and debug your game, all in one place.

[gurok]

I suggest creating a sub-task for assembling a goal-defining committee.

[AlanDrake]

At the risk of sounding obvious, I think the goal of a tool for making adventure games is making adventure games.

[ghost]

Every tool has to meet certain demands. What is important for it, what is not, what is priority, what is not, what functionality should development aim and what should not. What should program design look like. What the user workflow should be. This is what I meant when I suggested discussing the goal. "Making adventure games" does not define anything. You can make adventure games on paper - problem solved, you don't need AGS?

Developing a program without goal is like walking into random direction. Maybe eventually we will get where we like, or maybe not. On a side note it also makes it really complicated to work with non-core contributors. How can you recommend them any tasks if you don't have a clear goal yourself? How can a maintainer of a program decide whether the suggested change is acceptable withing the concept of a tool or not, and whether it should be merged? Or we should merge in anything that "looks good" and produce more mess?

[AlanDrake]

I only wrote that to remind what the most important purpose is. As for development, to me the primary goal is making the codebase simpler and easier to handle, because that makes further change easier. Other goals are implementing new features, coming up with ideas to improve the scripting (like a better audio api as you also suggested), give the possibility to overwrite hardcoded behaviours and so on. Ideally, we should work toward decreasing the mess because we wanted to rebuild a better foundation.

[ghost]

Other goals are implementing new features, coming up with ideas to improve the scripting (like a better audio api as you also suggested), give the possibility to overwrite hardcoded behaviours and so on. Ideally, we should work toward decreasing the mess because we wanted to rebuild a better foundation.

I guess we are talking about different "levels" of goals. The "new features" is not what I had in mind. The "better foundation" is. But my belief is that this foundation should be defined on its own, as an ideal we are going towards. After the goal is set we may decide how to reach it from where we are, which is a separate problem.

To give an example of a goal, in my understanding, morganw wants to have Editor work with raw source files on disk rather than import stuff with menus and have them saved in some "special" formats. The conversion and packaging is only done at the compilation stage. IIRC he also wanted all compilers to be stand-alone tools that may be run separately from IDE.

That's actually a defined goal, it describes the general Editor workflow (working process), and could be pretty much enough to know which changes to Editor are wanted and which are not in the long term. It also indicates which parts of the Editor may or should be removed (hence they have less priority when it comes to enhancing something).

[morganwillcock]

I do want these things. But starting from the highest level, if we all agree that this is a project for building games, with scripts, with an IDE, the workflow and scope is something similar to:

user code -> AGS -> playable game

...this is clearly not what is happening right now. As the example of what I'm mostly concerned with (in both senses of the word), if the only input is new code then there is no requirement for backwards compatibilty. I'm suggesting that this:

old compiled game -> AGS -> playable game

...is not sustainable.

I'd suggest this is reasonable:

3.4 project data -> AGS 3.5 -> playable game 

...where project data is guaranteed to load but not guaranteed to compile.

If AGS is a game authoring tool and nothing else then I don't think you need to do anything more; games have authors, authors are reponsible for supplying a working game, authors have access to AGS. What I am mostly interested in establishing here is the position on:

• the level of backwards compatibility that is offered
• use of this project as a way to run games which have been abandoned by their authors

At the moment, based on the description of AGS taken from the AGS website, we need neither of these features. So we either establish a goal which includes more than just game making, or we remove all backwards compatibilty.

Forgive me for being a little blunt here but I feel it is the best way to demonstrate my concerns.

[messengerbag]

I see you edited out this bit, ivan-mogilko:

Anyhow, it seems no one is really interested in doing this, as little were interested in defining these goals years ago.

I think on the contrary, there was a lot of interest in it and a lot of discussion, and in fact there seemed to be widespread agreement on a number of points.

I like the overall goal morgan cites at the top of the thread. I would say the goal of the project is the long-term maintenance and improvement of AGS as a free, powerful, and easy-to-use toolset for teams and individuals to make both free and commercial, high-quality 2D adventure games in widely varying styles of gameplay and presentation, and an engine that allows the games to be smoothly deployed and played on as many platforms as possible. I think it's also important to agree that it should be an engine for the AGS user community.

You can of course break that down into a much more specific (and longer) explanation, but I would argue that this proposed goal does establish a basis for making a lot of decisions and coming up with sub-goals. You can say that "right now, the project falls short of this goal in such-and-such a way, and therefore we should have a sub-goal to solve this problem". For example, Alan's point about improving the codebase goes to the bit about "long-term maintenance". On the other hand, ensuring that the engine can run older AGS games arguably does not really fall under any part of this goal as written.

[ghost]

I see you edited out this bit, ivan-mogilko:

Yes, I was a bit frustrated... but then, maybe I keep worrying about things that no one else consider an issue. Or don't consider an issue right now.

[ghost]

I think on the contrary, there was a lot of interest in it and a lot of discussion, and in fact there seemed to be widespread agreement on a number of points.

This may be my subjective impression, but these discussions took place mainly at the times when I expressed my tiredness with a project. It felt like everyone suddenly woke up and realized there's a project going on that needs attention; but then this did not lead to anything productive, at least not in regards to AGS. So either I at that time failed to use these opinions as advice in my work, or there was not enough momentum gained to push concerned community members further than simply forum posts.

PS. Anyway, that's not important anymore.

[messengerbag]

or there was not enough momentum gained to push concerned community members further than simply forum posts.

What more were you hoping for? Or more to the point, what more are you hoping for now?

[rofl0r]

an engine that allows ... to be ... and played on as many platforms as possible.

imo this should be an explicit non-goal, because there are some really odd platforms with halfbaked SDK's out there that need a ton of ifdef's and special code to get working. this makes the codebase messier and harder to understand.

"an engine with a portable and simple codebase that should work on all platforms with a proper POSIX implementation, and windows" would be a more reasonable goal.

[fernewelten]

Commercial game developers that look at their options for a development tool won't be looking for a high number of platforms. They will have a priority list, and I am fairly sure it would run along the following lines:

“I need it to run on 1a. (tied) Android, 1b. (tied) iOS,

3. Windows 10;
4. general Linux as a very very nice to have; 1-4. Offering the game as a web service would be a replacement for all of the above and so be very enticing, provided we can pull it off.
5. Gaming consoles are very iffy for Adventure type games. but should the framework offer it with very low extra overhead, we might go for it, too. ”

Hobbyists and indies will have a similar priority list, only more so due to their limited ressources.

So looking at AGS as a game writer support tool, there's much to suggest focusing on the platforms above, top-down. There wouldn't be much point going for the maximum of platforms possible.

Note that Dave Gilbert has left the room: Wadjet Eye's newest game won't be AGS based. Dave: “I always consider our designs quite modern in terms of design. But some people say they're retro or throwbacks to nostalgia or love letters to the golden age. I'm like no! They're not! […] But, they look like that. And I can't deny that's what they look like […] So I thought, well, maybe it's time to try to do something a little more modern, a little less retro in presentation at least.” https://adventuregamers.com/articles/view/37538

[JanetGilbert]

Wadjet Eye has not abandoned AGS :)

We also have exciting things coming in terms of Nick Sonneveld working on a Switch port which is very functional right now.

Janet Gilbert

On Jun 8, 2019, at 8:30 AM, Peter Bouillon [fernewelten] notifications@github.com wrote:

Commercial game developers that look at their options for a development tool won't be looking for a high number of platforms. They will have a priority list, and I am fairly sure it would run along the following lines:

“I need it to run on 1a. (tied) Android, 1b. (tied) iOS,

3. Windows 10;
4. general Linux as a very very nice to have; 1-4. Offering the game as a web service would be a replacement for all of the above and so be very enticing, provided we can pull it off.
5. Gaming consoles are very iffy for Adventure type games. but should the framework offer it with very low extra overhead, we might go for it, too. ”

Hobbyists and indies will have a similar priority list, only more so due to their limited ressources.

So looking at AGS as a game writer support tool, there's much to suggest focusing on the platforms above, top-down. There wouldn't be much point going for the maximum of platforms possible.

Note that Dave Gilbert has left the room: Wadjet Eye's newest game won't be AGS based. Dave: “I always consider our designs quite modern in terms of design. But some people say they're retro or throwbacks to nostalgia or love letters to the golden age. I'm like no! They're not! […] But, they look like that. And I can't deny that's what they look like […] So I thought, well, maybe it's time to try to do something a little more modern, a little less retro in presentation at least.” https://adventuregamers.com/articles/view/37538

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[sonneveld]

Sorry, these thoughts have been percolating, and this is a bit of a brain dump:

I wonder if a lot of the value is the in the editor itself, narrowing the wide landscape of game development and software development in general to a simple set of tools needed to create adventure games.

The engine itself could be simplified to a basic scriptable machine that draws 2d textures, accepts input, manages resources, plays sound, etc. Everything else the current engine does, inventory, save games, character movement, animations, dialogues, could be implemented through the scripting language itself. AGS itself would just be an "adventure game library" for the simple 2d engine, written in whatever scripting language it provides. But the game developer doesn't care, they only see the editor and what that provides.

on legacy: The open source AGS started when CJ open sourced it, but it really blossomed when crimson wizard started his refactor to start adding new features and in parallel JJS ported AGS to other systems to allow other people to play AGS games (new and old) on systems that they weren't originally published for.

I'd like to keep the legacy games available on these systems but I realise the burden of maintaining that along side new features has been pretty great. I do propose that if we do create a new engine, it doesn't use any code from the previous engine, except possibly in a shared non-adventuregamey cross platform library. It would be good if we could compile both old and new engines in the same build project until it has been properly grandfathered into something like scummvm which is designed for running legacy games. This is just to ensure that the legacy games are always playable on non-windows systems.

on platforms: In regards to platforms, we do have a problem in that we have a much lower barrier of entry for Windows and Linux development. Apple platforms, mobile, consoles,... all require special hardware, agreements, developer time and energy. They'll always be also-rans, and we shouldn't expect the main developers to support them, but we also shouldn't go out of our way to exclude them.

I have noticed that while working on porting the engine to other systems, this work is often done in the current development branch but game developers will tend to stick with the last release or two of the editor. If/when we do figure out a policy of deprecating and dropping support for older engines, it would be good if we support the last N engines so we can support new systems without the developer having to upgrade their game project to a work-in-progress editor.

on goals: "AGS is a tool for creating adventure games that will be playable on current and future systems."

[messengerbag]

Commercial game developers that look at their options for a development tool won't be looking for a high number of platforms.

Yes, that bit was badly phrased. I agree it's not a matter of running on as many platforms as possible just in sheer numbers, or that engine development should be limited by a requirement that it should run on all sorts of oddball hardware. But I would say that relatively poor platform support (and difficulty of porting) is one of the biggest limitations of AGS at the moment.

(And as you say, not just for commercial devs. I started working on a MAGS game recently, and quickly came to the conclusion that what I really wanted/needed for the gameplay mechanic I envisioned was touchscreen support.)

1a. (tied) Android, 1b. (tied) iOS,

3. Windows 10;
4. general Linux as a very very nice to have; 1-4. Offering the game as a web service would be a replacement for all of the above and so be very enticing, provided we can pull it off.
5. Gaming consoles are very iffy for Adventure type games. but should the framework offer it with very low extra overhead, we might go for it, too.

Something like that. Personally I would tweak it to (with approximate market share of online devices):

1. Windows 7-10 (37%)
2. Android (37%)
3. iOS (14%)
4. MacOS (7%) X. Web service (potentially in place of rest of list) (significant gap)
5. Gaming consoles (Switch) (significant gap)
6. Windows XP-Vista (1.5%)
7. General Linux (0.7%)

In either case, I think it's clear that this argues for high priority on improving/simplifying Android and iOS porting specifically.

[fernewelten]

Everything else the current engine does, inventory, save games, character movement, animations, dialogues, could be implemented through the scripting language itself.

One might argue that “legacy crust” has particularly accumulated in those parts, in particular.

Some things out of the top of my head:

• Options that ought to be orthogonal to each other are bundled into the “Sierra/Lucas Arts” switch. You must choose them either all the way to Sierra or all the way to LucasArts. For instance, if you choose Lucas Arts, you don't get to design your own “speech bubble” window.
• Even if you choose “Override built-in inventory window click handling”, the inventory frames are still not treated exactly as all the other frames are. For instance, AFAICR, clicks on the inventory that don't hit specific inventory icons aren't passed on to the window itself and can't be processed.
• Even if you create a high-resolution game, the automatic speech outline is still limited to 1 pixel. So if your background is bumpy, LucasStyle speech becomes very hard to read.
• If you create a high-resolution game, say 1200x900, then your characters and objects will need to move faster around the screen correspondingly. But the view frame delay is delimited to be at least zero and the loop delay is delimited to be at least zero. For higher speeds at still constant tick length, the sprite moving logic would probably need to fundamentally change.
• There isn't any really good way to cater for comic-style speech bubbles. You're pointed to extension packages that can't change the “Say” command; in order to use them in the Dialog editor, you must resort to kludges.

This isn't meant as bug reports for the individual issues, but as random examples that the game-specific parts of AGS in particular seem to have remained stable for a long time whilst the quirks remained. Perhaps the code is particularly unpleasant to touch/read/refactor in this area. But in this case, it doesn't help to have backward compatibility at the script level as a a mayor development goal.

[morganwillcock]

I wonder if a lot of the value is the in the editor itself, narrowing the wide landscape of game development and software development in general to a simple set of tools needed to create adventure games.

I think this is the crucial part, the goal is the toolset to make something.

I'd probably suggest a bold move that splits the goal into the production of three parts, which are related but can operate independently. I'm not suggesting this is the final wording, just (broadly) what each part should do.

---

1. Provide an Editor editor enivironment for the "create, test, and debug" of your game

I've mentioned this to a couple of people before, but if this is modular there is the option to share the Edtior with another engine which has none, specifically I'm thinking of MonoAGS, but WMELite is also in an awkward position here. This Environment needs to use other AGS components to make something (see below), but doesn't need them to run. It needs to have a debug interface that an engine or compiler can use.

2. Provide game compiler and engine with good support for upgrade and downgrade of persistant game data, and upgrades of project data

This knows nothing of old games and concentrates on providing a good scripting and runtime environment for chosen platforms. It is critical that resource and data loading be dynamic enough that there are reasonable methods of loading in old or replacement data (safe crash-free fallback). Maybe these components can break the project data every major version, maybe guarantee only trivial API or data changes on a point release, but it doesn't preserve legacy features long term and can faciltate a complete rewrite. These are standalone components that don't require an editor.

3. Production of decompiler and reassembly framework for old games

I'm proposing that rather than legacy code be in the engine, if it isn't handled by another project such as ScummVM, it is better in the long term to concentrate of decompiling all previous variants of game data into a common format. Then take 'patches' (which are hooks for a reassembly framework) to put the game back together in a format that can be processed by the compiler (see above). Any games which are rebuilt by this method are also cleary flagged as community rebuilds and not the original release, they should also be verifiable so that people can know what they are getting wasn't modied at a later date.

---

Parts 1 and 2 combine to give you the ability to make games and upgrade them (with nice features to help them keep working on upgrade), which covers the main existing goal. Part 3 is for playing old games but also lets you continually rebuild old games into a format expected by the newest compiler (as long as there is no legal issue with the game source). At the very least, just bulk decompilation can preverse the original internals for someone else to read.

I guess I'm most interested in people's take on part 3, since this isn't covered by the existing goal, and a couple of people here already have working decompilers - they will know better than me how feasible this is.

[rofl0r]

"an engine with a portable and simple codebase that should work on all platforms with a proper POSIX implementation, and windows" would be a more reasonable goal.

what i was getting at, is that platforms like Linux, OS X, *BSD, iOs, Android (which is practically linux with a rather stupid libc implementation slapped on top) all provide a proper POSIX implementation in their standard libraries. supporting them is basically equivalent to allowing CC, CXX, CFLAGS, etc for the build system to be overridden from the command line. (see my primer on the topic here). Unfortunately many people not experienced with C/C++ toolchains think portability means littering the Makefiles with hardcoded custom include paths to their SDKs, whereas they are meant to be specified on the command line when compiling or putting them into config.mak, which is included from the Makefile. Unfortunately, other platforms like consoles, handheld or otherwise, require a lot of special case code too which needs to be conditionally compiled only for them. the result is usually code that is rarely tested and falls apart as soon something in the surrounding code is changed.

General Linux (0.7%)

i don't know where you pulled these numbers, but i can assure you that many people using linux and *bsd specifically use AGS, because it allows them to play a lot of games in a world where most games target only windows. my impression is that at least 30% of issues/PRs opened in this repo come from linux users.

[messengerbag]

This isn't meant as bug reports for the individual issues, but as random examples that the game-specific parts of AGS in particular seem to have remained stable for a long time whilst the quirks remained. Perhaps the code is particularly unpleasant to touch/read/refactor in this area.

I'm pretty sure the reason why it remains is that there's little push for taking existing features out of the engine.

what i was getting at, is that platforms like Linux, OS X, *BSD, iOs, Android (which is practically linux with a rather stupid libc implementation slapped on top) all provide a proper POSIX implementation in their standard libraries.

I feel like this is getting a bit into the "how", rather than establishing priorities based on user needs.

i don't know where you pulled these numbers, but i can assure you that many people using linux and *bsd specifically use AGS, because it allows them to play a lot of games in a world where most games target only windows. my impression is that at least 30% of issues/PRs opened in this repo come from linux users.

The stats come from some sort of aggregated visitor tracking on websites. I only meant it to be indicative (and obviously it doesn't cover games consoles or other devices rarely used for web browsing). AGS may be popular among Linux users (and the OS therefore somewhat overrepresented among players, so that 0.7% is too low), but people who open issues/PRs on github are by no means a representative sample, and the sample size is very small in the first place. I would be astonished if more than 5% of AGS games played are on Linux; my guess would be 1-2%.

Of course, Linux is the one platform other than Windows that AGS has pretty good support for already (AFAICT), and there's no reason to drop that. But yeah, I'd argue that it should be lowest priority of all these platforms.

[fernewelten]

From the vantage point of a user, a re-organized code base doesn't offer any value whatsoever: It's completely below the hood; there's nothing visible from the outside. So the user will see it as a liability: They know that the rewrite will have introduced new bugs, so they will compulsively cling to the current bug-free version and ignore the update as hard as possible.

A pure re-write is very exciting from the programmers' point of view, but it makes for a dead version that nobody will want from the users' perspective. To sell a re-write to the users, they will need to be enticed right from the beginning with real, tangible, added value that enhances their experience visibly.

At the moment, I am having a hard time seeing that enticing added end-user value. All the highlights, such as an improved pathfinder, seem to be either in 3.5 already -- or phased out of the project for not being “compatible” enough. And the known visible game specific quirks and snafus don't get touched by the re-write, either.

[ghost]

Rewrite's goal could be introducing new different engine's design. If written from scratch it could be easier to achieve what you want than trying to get there by gradually replacing parts of existing code. Real example: I had to rewrite graphic renderers and its initialization 4 or 5 times already while implementing custom resolutions and then custom viewports/cameras, because each time I introduced new bugs, each time I had to restore connections with existing functions and then with backwards compatibility.

Ofcourse it may not make much sense to do complete rewrite if the wanted changes are small, but if they are significant and mean cardinal change in engine's and game objects' design, than it may be a viable solution.

PS. Also, it does not necessarily have to be exciting to users. It's developers' consideration after all, since they know better whether it's easy to continue working with existing codebase or not and can see what perspectives are there for keeping old code.

[selmiak]

what about this:

the goal of the project is the long-term maintenance and improvement of AGS as a free, powerful, and easy-to-use toolset for teams and individuals to make both free and commercial, high-quality 2D adventure games in widely varying styles of gameplay and presentation, and an engine that allows the games to be smoothly deployed and played on (almost) all modern platforms (win, linux, OSX, iOS, android) and is easy and intuitive for developers to port to new platforms.

[ivan-mogilko]

I guess I should close this issue, although it seems that the discussion ended abruptly without a logical conclusion. Some of the posts above, both by @sonneveld and @morganwillcock , are pretty interesting read, and contain good ideas. It's just not obvious whether these ideas may be or are wanted to be applied to the current project (like the suggested game project disassembly-reassembly workflow, or a suggestion to write a more barebones engine, moving most of the game logic to script modules).

One important thing happened since the times of this conversation: ScummVM now features a working AGS port, which somewhat relieves us from an obligation of maintaining legacy support.