AGS: Let's start over?

[Calin Leafshade]

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.

[BigMc]

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

[Snarky]

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.

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! 

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.

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.

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.

But we can do it; I'm in!

Great! Knock yourself out.

[Calin Leafshade]

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.

[tzachs]

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

[Monsieur OUXX]

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

[Snarky]

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.

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

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

[miguel]

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.

[Adeel]

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

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!

[Lt. Smash]

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.

[Lt. Smash]

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.

[Snarky]

You realize that AGS is already on Github? https://github.com/adventuregamestudio/ags/

[bicilotti]

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 and XNA).
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!

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!

[Lt. Smash]

You realize that AGS is already on Github? https://github.com/adventuregamestudio/ags/

Ah my bad! Must have overslept that Thanks for the update!

[miguel]

In Portugal, expensive coders have their testicles removed.

[Gurok]

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.

[Besh]

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.

[Lt. Smash]

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:

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.

[Wyz]

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

[Crimson Wizard]

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.