Discussion on Bladecoder,MonoAGS,Adore,Escoria + MonoAGS audit

[Monsieur OUXX]

Following post-mortem this thread and all the previous threads http://www.adventuregamestudio.co.uk/forums/index.php?topic=55657.msg636578880#msg636578880

Spoiler

EDIT : everything that is written in this hidden section was my original post but you should not consider it my opinion -- it was more of a conversation starter and has been contested. The table is better.

I'm starting this thread in this forum for two reasons :
1) there was no thread dedicated specifically on MonoAGS
2) This is virtually a sub-thread to the "AGS 4"  thread (aka "why this project is screwed up"), only dedicated to MonoAGS as one of the many options.


What I like about MonoAGS

• It's started by one (seemingly skilled) person, who has leadership
• he sources are immediately available on git.
• Some thought has been given to follow in AGS legacy (programming-wise). Specifically: Not being unncessarily anti-Microsoft, while still focusing on cross-platform tech
• Some thought has been given to having a good, flexible scripting language (i.e. C# as a scripting language that can still be compiled separately from the engine or Editor source)
• Some effort in the documentation

What I don't like about MonoAGS

• The Editor is not part of the initial vision. It's envisionned as some sort of tool "external" to the engine, that can come after. It means there's no vision on assets management and game-creation pipeline.
• It's focusing a lot on basic graphics rendering (SDL), with no vision regarding the other components, such as sound engine, controllers input, GUI, timing, etc. That's my biggest concern with many wannabe game engines: they lose steam after they manage to render the graphics of the game, but that's only 25% of the whole picture.
• It doesn't do vectors, even only just by wrapping some basic directX primitives/data structures. There are many vectors usages that you might not think about until they're missing and it's too late (graphics scaling, walkable areas, perspective, camera control, tweens, parallax, etc.).

What I don't know about MonoAGS

• Is the build automated? Like, do you maintain a solution made with something such as cmake to generate the .sln file and all? That's one of the weaknesses that CW pointed out in AGS. Those tools are real magic to generate soluions for any IDE/compiler/Visual Studio version in one click

Apart from that,I have no opinion on the switch from Mono to .net Core. That's a side discussion.

There should also be threads to discuss Blade Coder and Adore.

[close]

Engine	AGS	Bladecoder	MonoAGS	Adore	Escoria	Placeholder 1	Placeholder 2
Middleware / underlying game engine	Allegro	libgdx	None	Löve aka Löve2D	Godot	Placeholder 1	Placeholder 2
Editor included	Yes	Yes	Not yet (plans on making things editable directy in-game)	No editor provided but many frontends suggested (e.g. Notepad++ with a plugin) See link in footnote	Yes	Placeholder 1	Placeholder 2
Platform/VM for the engine	None (direct  C++), but has binds to some Windows libs.	Java	Non-Microsoft .Net Framework, aka “Mono” (considers moving to .Net Core)	Lua		Placeholder 1	Placeholder 2
Platform/VM for the Editor	.Net framework	JDK required	Mono (considers moving to .Net Core)	-		Placeholder 1	Placeholder 2
Hardware supported	Windows desktops. Existing ports : MacOS (outdated) ]PSP Android iPhone(?)	All++ (not only the build+execution, but also subtle things for mobile devices such as tapping, hand motions and accelerometer)	All (but for subtle things meant for mobile devices such as tapping and accelerometer, you'll need extra code/libraries)	All+ (not only the build+execution, but also subtle things for mobile devices such as tapping, hand motions and accelerometer)		Placeholder 1	Placeholder 2
Engine's language	Old-school C with big chunks of C++	Java	C#	Lua		Placeholder 1	Placeholder 2
Editor's language	C#	Java	C#	-		Placeholder 1	Placeholder 2
Main libraries used (apart from DirectX+OpenGL which are included implicitly in most cases)	allegro 4	I don't know how much of libgdx is self-sufficient	OpenGL+OpenAL bundled in OpenTK	I don't know how much of Lua is self-sufficient		Placeholder 1	Placeholder 2
Proper versioning	Yes (git)	Yes (git)	Yes (git)	Yes (git)		Placeholder 1	Placeholder 2
Automated tests	No ?	?	?	Yes (“busted”)		Placeholder 1	Placeholder 2
Automated solution generation	No	Not needed ? (Java all the way)	No	Not needed (Lua all the way) ?		Placeholder 1	Placeholder 2
Automated build and release	No	Most likely	Yes	?		Placeholder 1	Placeholder 2
Native support for Photoshop (PSD) files	No	No?	No	Yes?		Placeholder 1	Placeholder 2
Localization mechanisms	Yes, up to 256 characters per font	?	?	?		Placeholder 1	Placeholder 2
Good manual + community + tutorials	Yes	Yes	Yes (at least it has some doc and a proper home page)	Yes but only one demo game		Placeholder 1	Placeholder 2
Maintainers	Approx.. 4	Many for libgdx,  +1 very efficient for Bladecoder, +approx. 4 from the AGS community if we go there	1 +approx. 4 from the AGS community if we go there	Many for Löve2D, +1 for Adore, +approx. 4 from the AGS community if we go there		Placeholder 1	Placeholder 2
Sound engine	Not really, apart from just playing sounds	Yes (libgdx)	Yes (OpenAL has good features, that tzachs has wrapped into MonoAGS)	Yes		Placeholder 1	Placeholder 2
Controllers input	Just the basic : keyboard+mouse (and joystick with a plugin)	Yes+ (including mobile device gesture)	Just the basics	Yes		Placeholder 1	Placeholder 2
Subpixel management / maths / vectors (see in an other post in this discussion what I mean by that)	No, apart from basic float management and the Tweens module	Yes+ skelettal animation out of the box	basic OpenGL stuff + everything that was ported to C#. Anything else has to be binded manually	Yes		Placeholder 1	Placeholder 2
Multithreading inside the game	No	Probably	to be implemented by the game designer	Probably, using Lua	?	Placeholder 1	Placeholder 2
Data structures / serialization / database-like processing	No, apart from arrays of structs	Yes (XML, Json and everything natively)	Yes? (classes from Mono and/or .Net Core)	Yes? (Lua has everything)	?	Placeholder 1	Placeholder 2
Pixel-perfect low-res graphics	Yes	?	Yes?	Yes?	?	Placeholder 1	Placeholder 2
Collaborative work / compatibility with versioning	Possible with scripts and rooms, but not recommended with the main game file (.agf) nor sprites library.	?	Editor doesn't exist yet	?	?	Placeholder 1	Placeholder 2
Game scripting language	custom (AGS script)	NONE YET	C# (but some people think that things are little too hard coded yet)	Lua	custom (Gdscript, aka something similar to strongly-typed Python)	Placeholder 1	Placeholder 2
dialogs scripting language	custom (AGS dialogs script)	Ink	C#	Lua	?	Placeholder 1	Placeholder 2
in-game GUIs	None/custom (poor set of native graphic controls)	Yes (offered by libgdx)	custom (partially implemented)	Lua libs	?	Placeholder 1	Placeholder 2

Escoria : https://github.com/godotengine/escoria/blob/master/README.md
MonoAGS : https://tzachshabtay.github.io/MonoAGS/
Bladecoder: https://github.com/bladecoder/bladecoder-adventure-engine/wiki
AGS: https://github.com/adventuregamestudio/
Libbgdx : https://libgdx.badlogicgames.com/features.html
Löve : http://www.love2d.org/
Suggested editors for Löve : http://www.gamefromscratch.com/post/2016/01/25/Editors-and-IDEs-for-Lua-and-Love-Development.aspx


Ink : https://www.gdcvault.com/play/1023221/Ink-The-Narrative-Scripting-Language
Java :
Mono : https://en.wikipedia.org/wiki/Mono_(software)
Mono versus .Net Core : https://stackoverflow.com/questions/37738106/net-core-vs-mono
Adore : https://github.com/CalinLeafshade/adore

[Monsieur OUXX]

imho, Bladecoder is clearly the heavyweight here, especially because libgdx is very complete and well supported, and because it relies on state-of-the-art third-party libraries (I'm thinking of the Ink language).

MonoAGS could be promising, but it's a billion years behind and doesn't even have an Editor. I can see it trap itself into a corner from aiming "too small" and trying to code everything manually.
Adore too, but... who would be able to handle an all-Lua thing?
I haven't been able to dive too deeply into Godot.

[eri0o]

Is there any reason why ignoring Unity3D, Gamemaker, RPGMaker, Unreal, Lumberjack, Pygame, Phaser, Pico8, Visionaire Studio, Construct, ...?

[Crimson Wizard]

What I don't like about MonoAGS

• It's focusing a lot on basic graphics rendering (SDL), with no vision regarding the other components, such as sound engine, controllers input, GUI, timing, etc. That's my biggest concern with many wannabe game engines: they lose steam after they manage to render the graphics of the game, but that's only 25% of the whole picture.
• It doesn't do vectors, even only just by wrapping some basic directX primitives/data structures. There are many vectors usages that you might not think about until they're missing and it's too late (graphics scaling, walkable areas, perspective, camera control, tweens, parallax, etc.).

TBH reading this makes me wonder if we are looking at the same program. Also,... what you say about vectors is completely baffling me. I mean... I cannot even understand what you mean.

MonoAGS could be promising, but it's a billion years behind and doesn't even have an Editor. I can see it trap itself into a corner from aiming "too small" and trying to code everything manually.

Tzachs is preparing editor as an overlay inside the engine. AFAIK there is a work being done in code, but he better tell about that himself.

[Monsieur OUXX]

Is there any reason why ignoring Unity3D, Gamemaker, RPGMaker, Unreal, Lumberjack, Pygame, Phaser, Pico8, Visionaire Studio, Construct, ...?

Yes.
- Many of those are neither open source nor free. (Unity, Unreal...)
- Some others are not designed for adventure games. Justlike some people were awkwardly trying to make RPGs with AGS, I don't want to awkwardly make a point n click with RPG maker
- Pico8 ... the goal here is to make retro games, but with modern comfort, not to enter the demoscene or an assembly language competition!

If some of the engines you named still stand out after I explained my motivations, then please point them out, I'll look into them.
Also, my reflex would be to immediately discard an engine that comes with zero Editor (even an embryo would do), or one that only comes with graphics rendering and just awkwardly glues sound management and input management onto it.

[Monsieur OUXX]

TBH reading this makes me wonder if we are looking at the same program. Also,... what you say about vectors is completely baffling me.

Correct me. I'll update the table. I'm not saying I'm right, I'm just trying to put the data together.

[Crimson Wizard]

TBH reading this makes me wonder if we are looking at the same program. Also,... what you say about vectors is completely baffling me.

Correct me. I'll update the table. I'm not saying I'm right, I'm just trying to put the data together.

Could you explain what you meant by saying this, because I honestly do not understand it:

What I don't like about MonoAGS
It doesn't do vectors, even only just by wrapping some basic directX primitives/data structures. There are many vectors usages that you might not think about until they're missing and it's too late (graphics scaling, walkable areas, perspective, camera control, tweens, parallax, etc.).

What do you mean by "doing vectors", which vectors are you referring to, and how do they relate to scaling, areas, camera controls etc?



EDIT: For the reference, this is DemoGame recreated in MonoAGS:
https://www.dropbox.com/s/mhmad5ipsrpq6t9/MonoAGS-DemoGame.zip?dl=0

The reason I was so confused by what you've said is, that this game has sounds, GUI, camera controls (zooming, rotating). I think there might be some misunderstanding, maybe even mutual.
You may click on "?" button on the top bar and see demonstration of several advanced features too, like:
1) several rooms displayed at the same time, with cameras displaying them positioned anywhere on screen.
2) moving and rotating walkable areas with character moving and rotating after them


EDIT2: To be fair, I would agree on this though:

It means there's no vision on assets management and game-creation pipeline.

Well, maybe not literary so, but in a general sense. This was my big concern too, also a reason I'd like to try paricipating in the production (so much as the author lets me ).

[Monsieur OUXX]

I didn't know it had these capabilities. Pretty cool for something based on SDL! To be honest with you I was pretty hyped up by MonoAGS until I saw everything that Bladecoder can do -- but maybe there'sstill something to it. In paticular, if the plan is to sort-of intgrate the Editor directly as an in-game experience, it might do the trick.

I'm wondering how much of that walkable area manipulation is implemented "by hand". What I mean by "doing vectors" is everything related to sub-pixel processing, a.k.a. everything related to float values and geometric transformations. In modern engines that's usually achieved by trimming down 3D capabilities rather that upping up 2D capabilities (and therefore having to reinvent the wheel -- just , not as well as 3D would do it).


To illustrate the many unexpected things that one might want to achieve with proper "vector" abilities: these are the sort of things that modern game designers expect from an engine nowadays, even for low-res games: https://www.gamasutra.com/blogs/MichalBerlinger/20160323/268657/Combining_Perspective_and_Orthographic_Camera_for_Parallax_Effect_in_2D_Game.php

Finally, about sound and other "secondary" features: playing sounds is not the same as having a proper sound engine. Beware! Same thing for the controller inputs : Implementing tapping, finger gestures and accelerometer features are difficult tasks. Why redo all of that when it's already been made (better than we can ever hope to?)

[Crimson Wizard]

I didn't know it had these capabilities. Pretty cool for something based on SDL!
<...>
I'm wondering how much of that walkable area manipulation is implemented "by hand". What I mean by "doing vectors" is everything related to sub-pixel processing, a.k.a. everything related to float values and geometric transformations. In modern engines that's usually achieved by trimming down 3D capabilities rather that upping up 2D capabilities (and therefore having to reinvent the wheel -- just , not as well as 3D would do it).

But it is not based on SDL, it is based on OpenTK, and OpenGL! It is a 3D engine behind the scenes.
Where did this info about SDL come from?

[Monsieur OUXX]

I didn't know it had these capabilities. Pretty cool for something based on SDL!
<...>
I'm wondering how much of that walkable area manipulation is implemented "by hand". What I mean by "doing vectors" is everything related to sub-pixel processing, a.k.a. everything related to float values and geometric transformations. In modern engines that's usually achieved by trimming down 3D capabilities rather that upping up 2D capabilities (and therefore having to reinvent the wheel -- just , not as well as 3D would do it).

But it is not based on SDL, it is based on OpenTK, and OpenGL! It is a 3D engine behind the scenes.
Where did this info about SDL come from?

I got confused. It's indeed not SDL but OpenGL in a C# wrapper. But that does not fundamentaly reassure me and my statement remains the same:

Beware because the situation is not the same as circa 2000 -- back then "3D engine" mostly meant "3D rendering". And DirectX/OpenGL were considered top-shelf libraries, more than enough.

Nowadays, you may consider OpenGL (even combined with OpenAL and glut) virtually useless, because it does "nothing". The rendering is barely considered low-level, and when we say "3D engine", people expect 2D and 3D engines that come with convenient libraries and tools -- they expect editors and engines that can manage scenes, assets, camera motion, shaders, (even for low-res games, even for making a 2D game in the end). AGS does that. Same thing for a sound engine: OpenAL is low-level, but you'd still need a lot of work for the modern "fancy" (and yet bare minimum) stuff (localized/oriented sounds, crossfading, ambiant, etc.)

You might wonder what I'm babbling about, and you might think I'm shooting too high, but everything I mentioned (apart from the sound), AGS almost entirely does it already. Either natively, or thanks to the modules contributions over almost 15 years (smooth scrolling, tweens, room scripts, particle modules, etc.). We could make all those things available instantly and let the community focus on other things.

[Crimson Wizard]

EDIT: Sorry, nevermind. I apologize, being in an angry mood because of unrelated reasons.

I think it is better to leave explaining how the engine works to tzachs, who knows better about it, and his own plans.

[eri0o]

You know what AGS does really well, as simple as is it's functions and editor? GUIs. I made a game using only GUIs. GUIs in AGS are very easy to do.

[Monsieur OUXX]

I don't know if you're serious about basing off AGS 5 on Unity or Unreal, but there are so many reasons why it sounds crazy (licencing!)

=====

Moving on to another topic:
MONOAGS AUDIT REQUIRED

@tzachs, could you clarify the points below:
- monoags automated build yes/no
- monoags automated tests yes/no
- implementation of usual point n click entities yes/no (rooms, characters, inventories, objects...)
- replication of known AGS functions (character.Say, etc.) -- to which extent?
- editor (explain your plan)
- you're really not using any game-oriented  middleware for assets loading, sound management (apart from basic OpenAL), controllers input, animation, camera control, etc.?

[tzachs]

The Editor is not part of the initial vision. It's envisionned as some sort of tool "external" to the engine, that can come after. It means there's no vision on assets management and game-creation pipeline.

The editor is a critical part of why I started my project in the first place, it's definitely part of the initial vision. My AGS development background is exclusively the editor, and I had a much clearer idea on what I wanted to do with the editor than the engine when I started.
The engine comes first because it's the core, and because I wanted it to be independent from the editor in the sense that at any time during the development you can ignore the editor completely and just stick with the engine.

Like Crimson Wizard said, I currently work on the editor as an overlay in the engine, as I want you to be able to edit rooms as you play them (i.e to remove the “edit room -> debug -> edit room -> debug” annoying loop). I don't want to talk too much about the editor currently -> I can probably go on and on about features I plan for the editor if you'll push me, but because it's very early stages and things will change greatly, I don't want to over-promise. Anyway, if you have ideas for stuff you want to see in the editor, now is a very good time, so let me know.

Regarding assets management -> That's kind of vague and can be interpreted in many different ways:
In the context of the editor the idea is to have an “explorer” view with the assets folder which will bind to the assets in the actual folders, so just by copying to the folder on your computer should automatically update the assets (though of course it will also have dedicated context menu and drag&drop support). It should also support hot-reloading the assets during the game (when debugging). 
In the context of asset bundles, packing textures, compressions, etc, that's all stuff I want to add in the future, though it's true I don't have a clear vision for this, I don't have the experience, but I definitely want to tackle that. Crimson Wizard gave me a detailed proposal that I'm going to implement in terms of making the engine easily extensible for loading different bundles from different locations. Any other feedback on this (or anything else) is welcome.
I might have completely missed your point here, because, as I said, it's vague, so let me know if you meant something else.

Regarding game-creation pipeline -> This is even more vague than assets management, so it would help if you expand on that.

It's focusing a lot on basic graphics rendering (SDL), with no vision regarding the other components, such as sound engine, controllers input, GUI, timing, etc. That's my biggest concern with many wannabe game engines: they lose steam after they manage to render the graphics of the game, but that's only 25% of the whole picture.

So first to clear the confusion a little bit, I'm currently not using SDL, but OpenTK. OpenTK has the option of taking SDL as a backend to override OpenTK's own native handling of windows, input and graphics. In theory this should give better stability and better controllers handling- so far I didn't add controller support and didn't see any stability issues related to OpenTK so I'm not using SDL, but I have the option to if the need arises.

Regarding sound engine, here's what I currently have:
- The ability to play/loop/stop/pause/resume/rewind (or seek to a specific position) sounds.
- The ability to change a sound's volume/pitch/panning (you can set it for the audio clip itself or for individual sounds played by the audio clip), including tweening.
- The ability to query a sound's state and to get all currently playing sounds for an audio clip
- The ability to asynchronously wait for a sound to finish playing
- Automatic cross-fading for music clips when switching rooms with the ability to configure fade-in/fade-out time and tween.
- A sound emitter which can be attached to a moving entity and automatically adjust the panning based on its position in the scene (i.e positional sound), and also volume changing areas, that changes the volume automatically when the emitter moves across the areas (lower volume for far away entities, etc). The sound emitter can also be configured to easily play sounds on specific animation frames (useful for footsteps).

Here's what I don't currently have but want to add (and I have a tracking issue on Github for each one of those):
- Automatically reduce volume for playing sounds when speech is playing (but allow overriding it per sound)
- Allow adding effects to sounds (like reverb) at runtime
- Support envelopes
- Support for Opus format (and other audio formats)
- Support runtime synth of sounds (midi)
- Support audio streaming

If there's more stuff you think a sound engine needs which I am not aware of please let me know.

Regarding GUIs, here's what I currently have:
- Various controls: labels, buttons, checkboxes, comboboxes (drop-downs), inventory windows, listboxes, scrolling panels, sliders, textboxes
- Layouts: stack layout and tree-view layout.
- All GUIs are basically extensions of existing entities, meaning that they can be treated just like all other entities, so you can have GUIs as part of your world, they don't have to be on top. They can also be parents of non-GUI entities and vice versa (so you can, for example, have a character walking inside a scrolling panel if you want) and you can also tween GUIs and change their position, scale, rotation and pivot points.
- Dialogs like yes/no, with the concept of focus so that dialogs can take input focus from the game.
- A proof-of-concept skinning (theming) engine for GUIs.

As to what I don't currently have, there's a ton of stuff missing, from various controls (tabs and menus come to mind immediately), responsive grid layouts, pretty built-in skins, and the existing controls themselves also might miss functionality. This is all very much in progress. The kicker here is that as I'm building the editor based on this GUI framework, assuming I'm successful you can expect that eventually I'll have a very complete GUI framework that can be easily integrated into the game world (not a lot of engines can claim that, I believe).

Again, let me know if there's more stuff you think it's missing.

Regarding timing, I'm not sure what you mean by that, please expand if you can.
Regarding controllers, yes, I currently don't support those, but plan to add eventually (though it's not a top priority currently as people can use libraries to work-around that).

It doesn't do vectors, even only just by wrapping some basic directX primitives/data structures. There are many vectors usages that you might not think about until they're missing and it's too late (graphics scaling, walkable areas, perspective, camera control, tweens, parallax, etc.).

Like Crimson Wizard, I was also confused. I originally thought you meant vector art (svg), which is currently indeed not supported (but it's actually a high priority for me). Vector areas is another thing completely which is also currently not supported (but planned). Lastly, based on the gamasutra article you linked to, I think the only thing missing to do something like that is perspective camera support, as everything automatically uses ortho cameras currently (MonoAGS already support parallax layers, btw). This is something I can probably add.

Is the build automated? Like, do you maintain a solution made with something such as cmake to generate the .sln file and all? That's one of the weaknesses that CW pointed out in AGS. Those tools are real magic to generate soluions for any IDE/compiler/Visual Studio version in one click

The build is automated (and there are automated tests as well- though the tests are not as comprehensive as I would like them to be). Also, a big fantasy for me would be to have UI tests (i.e use docker to open up an OpenGL context, and automatically run the demo game or some other test game with video recording if something goes wrong).
I don't use cmake nor do I understand what you mean by "generate the .sln file and all”. I'm not familiar with any c# project that uses cmake? I don't have any experience with c++, but in c# you almost never update the sln file manually, the IDE handles it for you, and the IDE itself rarely touches it as well (just when adding/removing projects).

Apart from that,I have no opinion on the switch from Mono to .net Core.

.net core should be faster and more stable than mono, but the really big appeal is that it can be self-contained, meaning you can bundle the runtime with the game so it's not needed for the user to have the runtime installed on her/his machine.

Good manual + community + tutorials: yes

I would not say that's true: I consider the current documentation to be miles off from where I want to be: I have reference API docs and some explanation articles but zero tutorials, samples and recipes.

Subpixel management / maths / vectors: to be binded

I don't understand the category and the “to be binded”. MonoAGS supports subpixel positioning. Not sure what you mean by “maths”, but c# has built in math in the standard library, and already mentioned my misunderstanding of what you mean by vectors.

Multithreading inside the game:
to be implemented by the game designer

MonoAGS currently uses 2 threads, one for the render loop and one for the update loop. And other than that, yes, developer can create threads if she/he wants. I talk more about the threading model here.

Data structures / serialization / database-like processing

c# (the standard library and existing libraries) probably has everything you want and more.

1) relying on a cross-platform tech? If yes which one?
2) which is the licensing Of that underlying tech ?
3) Is that underlying tech  only a graphics renderer or a full multimedia engine? In other words: does the graphics rendering come bundle with the audio and potentially 3D or GUI rendering, or are these separate libraries?
4) Is that underlying tech  only a game engine or an Editor too?
5) How old is each of the few central underlying tech or lib (name them) and the main project itself ?
6) What third-party libraries is it using (full list)? How old/robust/well maintained/too restrictive are they?
@tzachs not accurate enough!  could you please have a look at the bits I added in italics in the quote above?

Ok, expanding on the “italics” parts:

1. All the techs I list here are cross-platform (and by cross-platform, I mean, at the very minimum: Windows 7 and above, Mac, Linux, Android, IOS.
2. Dotnet framework, OpenTK, SDL, OpenAL Soft, Protobuf.net,NVorbis, FFmpeg, everything else is MIT.
3. The underlying tech is low-level multimedia bindings (you see it as useless, I thought the opposite: I didn't want to get the burden of an existing complete engine, as it gives more freedom).
4. …
5. Very hard to answer about the underlying tech age, it's not something usually published on the front page: dotnet core is probably the youngest one (2 years?). I originally started working on MonoAGS on Aug 7, 2015 (on the flight to Mittens New-Orleans). Everything else has been around longer than that.

@tzachs, could you clarify the points below:

Ok, you added this as I was typing, so parts I haven't touched on yet:

- implementation of usual point n click entities yes/no (rooms, characters, inventories, objects…)

yes to all (I think).

- replication of known AGS functions (character.Say, etc.) -- to which extent?

So I went over the API back in the day, and I think I have most of it in some form or other. I probably missed a bunch of stuff though.
Things that I know I don't currently have are: Object.Solid, tint areas, text parser and drawing surface. I'll go over it soon and make a more exhaustive list.

- editor (explain your plan)

Ok, so you are pushing me . It will be a long post on its own, and will take me some time to write, so I'll get back to you on that.

- you're really not using any game-oriented  middleware for assets loading, sound management (apart from basic OpenAL), controllers input, animation, camera control, etc.?

Not that I know of.

[Crimson Wizard]

Part of the issue with this discussion is that we are speaking on bit different languages here, the examples with "vectors", and another with "automation" and "cmake" illustrate this.

I think what Monsieur OUXX meant by "vectors" is 3D scene and texture rendering versus software bitmap blitting.

A little note about automation. When I marked the lack of it as a weak point of AGS, I was not thinking about lack of Cmake scripts. In fact, that's funny, because some people complained about our Allegro 4 fork that had these, because they wanted to have SLN files instead, which I added. Anyway that's not the point, naturally Cmake is a good thing to have.
My main point was lack of automatic building, that is - compiling + packaging a release. For which you do not necessary need a cmake, you need to have a server and a tool that would run building scripts per demand (e.g. when it detects a new commit in repository).

I would also argue about the need to mix organization-related issues, like versioning and autobuilding, into this. These clearly are important, but on a completely different level compared to overall engine design and its compatibilities. They may also be much simplier to solve (assuming you have control over source code).


On other hand, this talk about middleware caught my eye. It seems Monsieur OUXX considers this to be very important, but tzachs barely touched this issue.
If I got this right, Monsieur OUXX's concerns were that without ready 3rd party libraries for things like asset and sound management, animations, input handling, etc, the engine will be difficult to code and maintain.


EDIT: Sorry, I keep updating my posts all the time, bad habit I know.
I wanted to mention this, although won't like to go too far into this right now, but I have my own points of doubt about MonoAGS. Thing is that I found its game-related design a bit too hard-codey from one side (something I disliked and wanted to resolve in AGS), and a bit too complicated for a regular AGSer from another side. But I was planning to PM my thoughts to tzachs about this for ages, which I might do soon.
What's certain, in my opinion, it may really benefit from discussing a game creation workflow, sooner is better. Because it seem to have quite some technical compatibilities, and it would be sad if people will find it inconvenient to use.




PS. On a side note. I made a very quick look into Bladecoder-engine code; does it actually have a scripting support? From the first glance it has only a set of actions to choose from, similar to old AGS's interaction editor.
The Wiki mentions "creating custom actions", but the article is missing.

[Joseph DiPerla]

Bladecoder doesn't currently support scripting. The author plans on implementing it after he is satisfied with his Ink implementation. Scripting will be Lua. After that is added, then support for html export is next.

[Monsieur OUXX]

Bladecoder doesn't currently support scripting. The author plans on implementing it after he is satisfied with his Ink implementation. Scripting will be Lua. After that is added, then support for html export is next.

Good feedback. I totally missed that.

[Monsieur OUXX]

This is aimed at explaining once and for all what I mean every time I try to express some concerns regarding what I sometimes call "vector abilities", sometimes "3D geometry", sometimes "subpixel transformations", etc.



Note that MonoAGS places my concerns on the right-hand side.

[Crimson Wizard]

This is aimed at explaining once and for all what I mean every time I try to express some concerns regarding what I sometimes call "vector abilities", sometimes "3D geometry", sometimes "subpixel transformations", etc.

BTW, AGS currently is middleground, because it has software renderer which is purely 2D, and two 3D renderers (where we have to solve these pixel-perfect problem too).

Strictly speaking, it is possible to implement full 3D effects in AGS, for example, make rooms rotate around all 3 axes, using native Direct3D and OpenGL abilities, but software renderer will work much worse.

[Monsieur OUXX]

@tzachs  : You have addressed all my worries regarding :
- Sound engine
- assets management (in that topic I was including both the things you mentionned)
That's great!


By game production pipeline I meant that the work of the project leader, game designer, artists and scripter don't overlap.
Here is how they sometimes overlap in AGS :
- Every time you add a sprite or a room, it modifies game.agf or some other central set of files. Conflicts cannot be resolved easily.
- If a sprite changes on the file system, you have to reimport it --> you have addressed that. (by the way, make sure that room backgrounds are not managed separately -- AGS keeps them in a black box, unlike sprites)
- if you add or remove a sound, it creates its corresponding name in the script. It breaks compilation if you remove the sound. (the sound artist's work conflicts with the scripter's work)
- I can't think of any other example right now but you get the idea.

About the GUI : I strongly recommend that you use a thirs-party library, and that you don't implement GUIs yourself! Home-made GUIs are the plague of many game frameworks. There's always a moment when scripters want to extend the behaviour or aspect of a GUI control, and then they can't because they can't hook on the controler events or graphical containers, or can't make sense of the rendering flow. And then you will have to carry that weight. Have you thought about Gwen.Net ? https://stackoverflow.com/questions/17403551/opengl-ui-library-for-c-sharp-with-opentk (Gwen is dead since 2015) Have you ought about GTK? https://stackoverflow.com/questions/8686820/gtk-opentk-libraries