AGS: Let's start over?

[hedgefield]

Plus the plugin itself appears to be $70.

Oh, yeah that's right, I forgot about that... but maybe that price could go down if it was more than just one man putting his free time into it. But anyway I can't speak for what Chris wants to do with the plugin, just a suggestion. The feature set there is so robust that it almost seems like double the effort to redo it once again. But I also think the free aspect is important yeah, anything above a few dollars might scare away amateur devs.

To the point of Unity being free, the official FAQ says "you can create and sell a game with the free version of Unity, without paying royalties or any revenue share. However, the free version of Unity may not be licensed by a commercial entity with annual gross revenues (based on fiscal year) in excess of US$100,000, or by an educational, non-profit or government entity with an annual budget of over US$100,000." Which I think most of us are not in danger of.

[bicilotti]

To the point of Unity being free, the official FAQ says "you can create and sell a game with the free version of Unity, without paying royalties or any revenue share. However, the free version of Unity may not be licensed by a commercial entity with annual gross revenues (based on fiscal year) in excess of US$100,000, or by an educational, non-profit or government entity with an annual budget of over US$100,000." Which I think most of us are not in danger of.

Wikipedia states (about Unity free) "...but limited in features and watermarked for web". Is that correct? The FAQ is unclear about it: "Please also be aware that the feature set of the free version is not intended for the production of professional games and interactive content.". Are those limitation really that limiting?

To be honest I think proprietary licences can lead to big problems (especially when the copyright holder is not 'part' of the community). I guess many devs see those as trumped by easiness and rapidness of development, etc.

And since we are on topic: Calin, are you still planning to release your engine under a liberal/OS licence?

[DoorKnobHandle]

The technical limitations in Unity Free are there but they aren't massive. You can't use your own custom shaders for example - but it doesn't limit the amount of assets you can have, the texture sizes or anything like that. It's perfectly usable to make a game with.

[Monsieur OUXX]

would not that be better if the ScummVM version would become the leading interpreter for running original AGS games, while interested AGSers could make a completely new engine, free of old ties, not needing to be backwards compatible?

That's the most clever thing I've heard regarding AGS and ScummVM getting closer to each other.

[Snarky]

If ScummVM is going to make existing AGS games easily playable on a wide range of platforms, that's fabulous, and takes care of one of the big feature requests for AGS.

The big questions, as I see them, are still:

- Should future work on an AGS engine (defined as "an engine for the AGS community") be based on the existing code base, or is it better to start fresh?
- To what extent should a future AGS engine be compatible with or follow the same design as the current engine? Which aspects should be preserved, and which should be changed?

These questions are intertwined, but distinct: you could do a complete rewrite of the engine that was 100% compatible with AGS 3.3, and you could work from the existing code base but make enough radical changes that the new engine followed a completely different design.

And then finally, of course:

- So who is going to do it?

[BigMc]

- To what extent should a future AGS engine be compatible with or follow the same design as the current engine? Which aspects should be preserved, and which should be changed?

These questions are intertwined, but distinct: you could do a complete rewrite of the engine that was 100% compatible with AGS 3.3, and you could work from the existing code base but make enough radical changes that the new engine followed a completely different design.

One of the really bad things about AGS is the format of the compiled games so the answer to this question is quite obvious to me.

[Crimson Wizard]

I only wanted to check what's the progress of ScummVM AGS port. I was surprised to see that, in fact, the port is not finished yet, missing many important features, one of which is save/load functionality. At first I thought I could help them copying new 3.3.0 features, but it appears there's still much work to get it complete. Also, since the code is rewritten from scratch, it will require lots of testing.
Alyssa Milburn also sais she has doubts if they will be able to get students working on it (for Google Summer of Code event), because the work requires "transcribing" original engine code, which may be bit tough.
Also, there's one important thing: ScummVM does not provide hardware graphics support. I heard they have hardware support in future plans, but before it happens, their AGS port cannot be considered "final".
Also, I have no idea about plugin support, I did not yet learnt if their system supports such thing. And I am afraid that the rewritten engine was made in a way that could break plugin compatibility (someone needs to check how optimistic/pessimistic things are).

So, frankly, I now think maintaining original AGS engine may still be essential for some time (well, for a year at least).

[Monsieur OUXX]

In other words, how do you (all of you who favor a new start) respond to the Joel on Software article?

Aahhh. I remember this article. And I disagree . I've seen too much bad code, I think.

The thing is that this article doesn't apply here :
- we don't want to do the code from scratch, because we'd use some widespread libraries (graphical routines, etc.)
- we don't switch entirely from the "old" ags to the "new" ags. There would be a period of transition, with the two of them being developed at the same time.

I want to say that, in my opinion, the choice of existing libraries and or framework is essential.

That's where the discussion stalls every time. I think we must take a strong decision: a forum thread with several candidate libraries for each key part of the Editor and Engine (RAD, script parser, graphical routines, etc.). Like, one table per component, with serveral entries in each table, one for each candidate library.
Then we discuss. Then we vote. And then the people who volunteer for rewrite stick to that.

[Crimson Wizard]

Then we discuss. Then we vote.

Vote??? ...

[Snarky]

One of the really bad things about AGS is the format of the compiled games so the answer to this question is quite obvious to me.

The format of compiled games is a problem? How?
And how does that imply a decision one way or the other any more than any other AGS shortcoming does?

The thing is that this article doesn't apply here :
- we don't want to do the code from scratch, because we'd use some widespread libraries (graphical routines, etc.)
- we don't switch entirely from the "old" ags to the "new" ags. There would be a period of transition, with the two of them being developed at the same time.

Just because you're using libraries doesn't mean you're not rewriting from scratch. (Which is to say: using libraries is such a standard part of development that it's taken for granted, just like the assumption that you're probably not writing your own hardware drivers. The work discussed is what you have to do on top of that.) AFAIK there's no "Make your own AGS" library: you'd still have to stitch together a bunch of separate libraries and build a fair amount on top of that. Plus integrate it all into a nice package with the editor, plug-in system, manual and all that. As much as some keep saying it's not a lot of work, I remain unconvinced. (CW's observations about the ScummVM port seems to me to demonstrate the significant gap between "proof of concept engine" and "fully working system".)

I think the central points of the article still hold: (1) All the existing code represents a bunch of knowledge about the domain, with thousands of specific features and fixes for particular situations. (2) By starting over, you're pretty much guaranteed that you'll have a looong period of development before the next version is even close to feature-complete and you're able to address new feature requests, while by refactoring current code and rewriting components of it piece by piece, throughout development you'll have a version with more or less the features that have already been implemented, which you can bugfix or add to at any time. The philosophy has something in common with Agile programming: don't try to tackle a huge thing all in one go, but break it up into smaller, more tractable tasks, and have something you can run (in this case, a usable adventure game engine) after every step.

Of course you could always â€" in principle â€" keep developing the old version in parallel (same thing applied to Netscape back in the day), but since coders are our most limited resource, that's not a very efficient use of effort.

Now, I don't think Joel's advice should be followed as an absolute rule, but I think it's something to think very carefully about.

I want to say that, in my opinion, the choice of existing libraries and or framework is essential.

That's where the discussion stalls every time. I think we must take a strong decision: a forum thread with several candidate libraries for each key part of the Editor and Engine (RAD, script parser, graphical routines, etc.). Like, one table per component, with serveral entries in each table, one for each candidate library.
Then we discuss. Then we vote. And then the people who volunteer for rewrite stick to that.

No, fuck that. Offering suggestions is one thing, but what the hell is the point of a vote? Most people don't have any clue about the technical intricacies involved, and it's not like there's any way to stop someone from going off and doing what they want just because a vote said it should be done some other way. It's a do-ocracy, not a democracy.

The people who do it get to decide how to do it. If someone is interested in implementing some part but isn't sure what library to pick, they can ask for advice. Meanwhile, discussion is futile unless someone is going to step up and write the code.

If we get into a position where we have multiple different branches with different solutions, and have to decide which one gets to be the official release... well, that's a better position than we're in now, not having any particularly active developers, and we can deal with it if it comes to that.

[Crimson Wizard]

(1) All the existing code represents a bunch of knowledge about the domain, with thousands of specific features and fixes for particular situations.

I'll put it this way: it were CJ's own words that AGS was made by "hacking" new things into over and over again. This makes it pretty messy, many features are hard-coded, while they could be made customized, there's lots of overcomplications, and many fixes serve only supporting those hacks to work together.

Of course you could always â€" in principle â€" keep developing the old version in parallel (same thing applied to Netscape back in the day), but since coders are our most limited resource, that's not a very efficient use of effort.

To put things really straight, the situation is this:
1. If the developers will stick to current engine, they will have to rewrite parts of engine, and if they must do that by "small steps", this means that with every essential change they will need to take extra effort and time to keep all things working the same. Seriously, I nearly became mad when was trying to follow the "baby steps" strategy while trying to make "removed limits" version: after every change I had to re-test whole thing, check how savedgames work, check several rooms in several games, etc, and making "temporary hacks" to keep things working in the intermediate state.

2. If the developers will be making a new engine, they will be free from constraints of backwards compatibility, but will have to spend more time on planning & developing from scratch.

In summary: whichever path is chosen, it will take much time to make a serious improvement. There will be specific problems on both paths.
In the first case the new features will get implemented faster, but the chances are high that the result will still bear some old problems of AGS.
In the second the result will be more clear, but it will take more time that ALL the features similar to original AGS will work.
The question really is: does everyone needs ALL features, including hard-coded styles&modes, from AGS to use the new engine?

[Monsieur OUXX]

Obviously, only the people who think they know about the topic should vote. Snarky, you're always so negative about everything. Most people won't care at all, or have no idea what it's about, so they won't vote. Why would people give their opinion just to sabotage the debate? And the vote is not so formal and strict. It's just taking the decision now that at some point we stop arguing, and we decide.

We don't know yet who will do it, so there's no point in saying "it's those who do it who decide". the community needs to decide, and stop hitting again and again the glass ceiling of "which libraires should be used".

======

For example, here is a fictional scenario:
Which library should be used for graphical routines?
- Allegro
- Ogre3D
- Unity
- just DirectX or OpenGL
(yes, yes, I do know that they're not on the same level, middleware-wise).

We discuss. Then at some point we call for a decision, and everybody (involved) names his favorite candidate.


If the libraires are decided beforehand, then there's room for someone to make a proof of concept, without the risk of telling him: "sorry, you did something very cool, but on the long run we think the libraries you built it on suck, so your awesome embryo of a new AGS can be immediately thrown to rubbish".

[Snarky]

Obviously, only the people who think they know about the topic should vote. Snarky, you're always so negative about everything. Most people won't care at all, or have no idea what it's about, so they won't vote. Why would people give their opinion just to sabotage the debate? And the vote is not so formal and strict. It's just taking the decision now that at some point we stop arguing, and we decide.

I'm not negative about everything. I'm positive about people going off and contributing to the engine (or making their own engines, if that's what they want to do), or even just offering ideas and suggestions. But I think a vote is completely pointless, because a "decision" is not a decision unless there's some capacity to act on it. We might as well have a vote on world peace.

Is there anyone who's standing around, ready to rewrite/write a new graphics stack but just waiting for a group decision on which library should be used? Because if not, a "decision" isn't going to lead to action any more than more arguing will.

The choice of library is an implementation detail, better left to the developers who are going to do the implementation. (If the choice of a particular library has specific implications for the engine in terms of compatibility, performance, licensing etc., that's a different matter that's certainly worth discussing... once the whole thing is not just hypothetical.)

Or to put it another way: OK, let's have a vote! I vote for "any way you goddamn please, as long as it works!"

[Lt. Smash]

Just my 2 cents. The primary purpose of AGS is that it makes it easy to develop Adventure Games and other similar types of games. No need for super hardcore 3d games and other special tasks. So my question is, why not using a low-end open-source backend, like LibGdx or other similar frameworks? No need to reinvent the wheel (developing an engine from scratch), especially for games that don't need much resources.

My proposal is this:
AGS 3.3 is working pretty well as it is. So games will continue to work as they are and game developers can stick to this version to complete or enhance their games.
AGS 4 will be completely new on top of a framework like libGDX.

Why LibGDX you ask?
+ Ok, that's maybe just my personal preference but I think that Java and C# are some of the most readable and understandable programming languages. At least one has an easier time learning Java (or C#) than C or C++ or Obj-C. LibGDX is developed in C, C++ and Java. AGS script is similar to Java and C#, so it wouldn't be too difficult for AGS developers to switch to Java language.
+ It is easily extendible and works well with IDEs like Eclipse and IntelliJ IDEA.
+ It is portable across Windows, Linux, Mac, Solaris, iOS, Android, Blackberry, all major browsers (as applet or HTML5 app).
+ It is extremely performant (using OpenGL 2+) and can run even 3d games on Android without lacks.
+ It is constantly enhanced by a large community which will help with all problems that the AGS development team could come across.
+ Super fancy OpenGL Shaders!
+ Unlimited sprites, animations, rooms, characters, everything! The only limitation is the hardware.
+ The developer can use any code (like the AGS "plugins" and modules) that is available for Java. For example: Facebook integration, in-app purchases, server connection ...
+ Today Java is pre-installed on almost any supported OS and we could also create a default game installer, which automatically installs the JRE if necessary.
+ Super high motivation, because we could have a working full-featured sample of the framework in a matter of months.

First step would be to create the AGS framework on top of LibGDX. We can create similar named classes and methods so AGS developers have an easier time to get into the new framework.
Second step would be to create the AGS editor. This could be done by creating Eclipse/IntelliJ plugins and a custom AGS View. Or a separate application.

The end developer would then develop using the Java language. For example:

Code: java

public class MyAGSGame extends AdventureGame {
  public void start() {
    // Game start

    Cutscene.begin();
    Character cEgo = Character.get("ego");
    cEgo.say("This is the beginning...");
    cEgo.walkTo(15, 30);
    cEgo.wait(2);
    cEgo.say("...of something great!");
    cEgo.playAnimation("raise arms");
    Cutscene.end();
  }
  public void pause() {
    // Game in background.
  }
  public void resume() {
    // Game back from background.
  }
  public void update(float delta) {
    // The old repeatedly execute
  }
  public void quit() {
    // Game quits.
  }
}

http://libgdx.badlogicgames.com
https://github.com/libgdx/libgdx/wiki

[bicilotti]

Then we discuss. Then we vote.

Vote??? ...

I share the same feelings. It is only sensible and just that the people putting in the effort/hours/swearing will be the ones setting the vision of the project; basic do-ocracy tenet. That doesn't mean ousting proposals/discussion/consensus reaching (which is, in a way, what folks contributing to this thread are trying to achieve. Hooray for us!).

To put things really straight, the situation is this:
[...]

As one of the persons with most hands on experience in AGS hacking (barring CJ himself), your inputs are precious Crimson; the more you write on the matter, the more elements everybody gets to make their own judgement (and you get a "Crimson Wizard tells it all" therapeutic session for free).
I don't know where I am going with this really; I wrote a list-of-question which I subsequently scrapped (too inquisitive/tactless now), but the point I am making is: your experience makes your opinions insightful,  even if you won't contribute in the future, so post like there is no tomorrow! 

edit: a proposal! For the interested reader, libgdx is released under Apache 2 (and apparently hasn't been packed in Debian yet).

[Wyz]

Ok for anyone how cares; my two cents.

Should we start over? Or keep working on the existing source? both!

Let me predict the future if we only do one of either:
Stick with the old
If we keep on working on the existing source we will probably get lost in it and face the same problems as CW did. The problem is that it really needs to be refactored because the code is not in the state where it can be worked on simultaneously by a group of developers: it's monolithic and not easily understood. In the meanwhile the world keeps on going and people will request more elaborate things to be added or changed at which the developers can not keep up and eventually grow tired of as it seems to be a loosing race: the project will be abandoned over and over.

Start over
A fresh an clean slate would be very nice since now we can design something that is up to par with modern standards. This will how ever not happen overnight: it is a lot of work and require a lot of coordination. Even if we find a passionate team working well together it would take at least 2 years to get something finished of the same posture of AGS (I reckon it might actually be 5 years). During the period of time to world also keeps on going. People will not stop making games but might not want to use an engine with a most recent version being years old an decide to use other tools. Other tools mean other communities and sooner or later people will start to migrate. In turn this will hit morale and the developers working on the new version and eventually drop out as well leaving the project astray. This sounds grim but I'm completely honest about this; this is what I think will happen.

So what then?
Do both! We can work on a new version that completely breaks with the old version so we don't have to make concessions but also refactor the original so we can still maintain new versions ever so often to keep people interested. More over we should not focus on the details so much as it comes to certain processes: why fuss about a splash screen when we don't even have the framework finished? It is better to zoom out and see the bigger picture. I've seen many many discussions where people promote the things they like and although I get that, it's besides the point. When we make something new it has to be for the community and the community should benefit from it. The problem is how we get there and I feel that's the biggest hurdle to take. I guess a way is to limit the amount of people involved in decision making but still the needs of the community needs to be reflected in the decisions they make. It's almost like governing a country wow to think of it.

Refactoring
This is just a lot of work and if it's for anyone the same as for me: you just don't know where to start. I would probably also have a hard time motivating myself for much task knowing there isn't much love; when purely refactoring you work for a year straight ending up with exactly the same product and everyone wonders: what's new? Well it's under the bonnet, it's what makes it susceptible to changes and fixing obscure (which are very much lit after refactoring) bugs. How do we sell it? I don't know but it needs to be done. It needs to be broken up in ever smaller chunks until it is at a point each chunk is easily understood and tested. Gah! Where to start.

A new version, how?
This calls for wits other then lots of talking: maybe we can split up the tasks make everything 100% modular. That way everyone can work on things matching their expertise. But this obviously needs some coordination or maybe rather a framework. I'm going to go reaaaally outside of the box here. For instance we have been discussion whether to use allegro or sdl or whatever: we can abstract from that using a wrapper: it's not about which library but rather about "how do we draw a sprite on the screen?". So rather then thinking "how do we do that using lib X and maybe is lib Y beter?" we make a wrapper that has a interface to draw a sprite on the screen and then whoever can write whatever bindings for whichever library they think is suitable.
Another example: instead of arguing about which script language to use we make it really easy to write language bindings with a wrapper. Then whoever wants can write whatever bindings for which ever language they seem fit. See where I'm going with this? So in the end we have a very basic framework that can be extended virtually limitless. The real power will be a flexible and easy to use editor that all stitches it together. Operating systems, platforms, all will be supported if there is someone willing to extend the framework in such way. What we will end up with then is the most powerful engine in the world (although with the editor still very much tailored to the needs of adventure game developers around the globe) and in the distant future even ATM machines will be run on AGS. And not regarding the last comment I'm not shitting you, this is very much a possibility and I'm sure it can be a reality though not over night. But we can do it; I'm in!

[RetroJay]

I know that opinions are like assholes... everyone has one...but.

AGS was originally designed to create 'old style Point And Click adventure games' right?

I started with 2.72 which done a damn fine job of fulfilling a goal I had wanted to accomplish since the ZX Spectrum, but had no scripting knowledge.
The editor taught me HOW to script, this was sorely missed in 3.0.

Had I started using 3.0. I would probably have given up right then and there, like many other so called 'Game Makers'.

Now everyone wants 3D graphics, better sound, higher res and all of the other shit that makes crap games of today like...
'Oh! can I knock that box over... WOW!... yes I can. (how exciting!).

My point.
Have you all lost sight of CJ's dream of creating Retro games?
I thought it was why we all downloaded AGS in the first place... wasn't it?

I know that my opinion won't matter, just read my avatar.

[Lt. Smash]

Creating retro style games will still be possible with AGS 4.0, I hope
Frankly, it shouldn't be any problem to create a retro game and a super high resolution adventure game with the same language and framework. If you can create something super fancy, you can also create something not so fancy, low-res. (I imagine 8-bit color mod, implemented via custom OpenGL shaders which also allow for color cycling, just like in those old days)
And regarding developing without scripting knowledge. I think that code templates would be a good substitute for that feature. There could be an editor plugin which automatically adds code templates to the game code. The developer just has to select a template and fill in the correct data, the plugin does the rest.

[Ponch]

I started with 2.72 which done a damn fine job of fulfilling a goal I had wanted to accomplish since the ZX Spectrum, but had no scripting knowledge.
The editor taught me HOW to script, this was sorely missed in 3.0.

Had I started using 3.0. I would probably have given up right then and there, like many other so called 'Game Makers'.

I know I'm nowhere skilled enough to contribute anything to the future of the AGS engine, but I wholeheartedly second this notion. Without the old editor, I would have given up on making games pretty easily. I'm comfortable with scripting now, but that editor was a lifesaver back in the day.

[RetroJay]

Hi Brother Ponch.

Same here.

After making 'The Lost Prince Of Lorden' (Shameless Plug)
I went through it again and re-scripted the entire thing again using proper code before uploading it.

I am currently trying to create the second part of my game and am pulling my hair out over the hideous audio system 3 has.

Also I am wondering why I am bothering with 3 at all as colleagues at work and family are playing my first game with no problems on windows 7 and 8 and 8.1.

Why can't we just go back to 2.72 and build on that version? It worked. (please excuse my ignorance on programing matters).