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

Started by Monsieur OUXX, Mon 08/01/2018 08:57:54

Previous topic - Next topic

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]


EngineAGSBladecoderMonoAGSAdoreEscoriaPlaceholder 1Placeholder 2
Middleware / underlying game engineAllegrolibgdxNoneLöve
aka Löve2D
GodotPlaceholder 1Placeholder 2
Editor includedYesYesNot 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
YesPlaceholder 1Placeholder 2
Platform/VM for the engineNone (direct  C++), but has binds to some Windows libs.


JavaNon-Microsoft .Net Framework, aka “Mono” (considers moving to .Net Core)LuaPlaceholder 1Placeholder 2
Platform/VM for the Editor.Net framework
JDK requiredMono (considers moving to .Net Core)-Placeholder 1Placeholder 2
Hardware supportedWindows 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 1Placeholder 2
Engine's languageOld-school C with big chunks of C++JavaC#LuaPlaceholder 1Placeholder 2
Editor's languageC#JavaC#-Placeholder 1Placeholder 2
Main libraries used
(apart from DirectX+OpenGL which are included implicitly in most cases)
allegro 4I don't know how much of libgdx is self-sufficientOpenGL+OpenAL bundled in OpenTKI don't know how much of Lua is self-sufficientPlaceholder 1Placeholder 2
Proper versioningYes (git)Yes (git)Yes (git)Yes (git)Placeholder 1Placeholder 2
Automated testsNo ???Yes (“busted”)Placeholder 1Placeholder 2
Automated solution generationNoNot needed ? (Java all the way)NoNot needed (Lua all the way) ?Placeholder 1Placeholder 2
Automated build and releaseNoMost likelyYes?Placeholder 1Placeholder 2
Native support for Photoshop (PSD) filesNoNo?NoYes?Placeholder 1Placeholder 2
Localization mechanismsYes, up to 256 characters per font???Placeholder 1Placeholder 2
Good manual + community + tutorialsYesYesYes
(at least it has some doc and a proper home page)
Yes but only one demo gamePlaceholder 1Placeholder 2
MaintainersApprox.. 4Many 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 1Placeholder 2
Sound engineNot really, apart from just playing soundsYes

(libgdx)
Yes

(OpenAL has good features, that tzachs has wrapped into MonoAGS)
YesPlaceholder 1Placeholder 2
Controllers inputJust the basic : keyboard+mouse (and joystick with a plugin)Yes+
(including mobile device gesture)
Just the basicsYesPlaceholder 1Placeholder 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
YesPlaceholder 1Placeholder 2
Multithreading inside the gameNoProbablyto be implemented by the game designerProbably, using Lua?Placeholder 1Placeholder 2
Data structures / serialization / database-like processingNo, apart from arrays of structsYes (XML, Json and everything natively)Yes? (classes from Mono and/or .Net Core)Yes? (Lua has everything)?Placeholder 1Placeholder 2
Pixel-perfect low-res graphicsYes?Yes?Yes??Placeholder 1Placeholder 2
Collaborative work / compatibility with versioningPossible with scripts and rooms, but not recommended with the main game file (.agf) nor sprites library.?Editor doesn't exist yet??Placeholder 1Placeholder 2
Game scripting languagecustom (AGS script)NONE YETC#
(but some people think that things are little too hard coded yet)
Luacustom (Gdscript, aka something similar to strongly-typed Python)Placeholder 1Placeholder 2
dialogs scripting languagecustom (AGS dialogs script)InkC#Lua?Placeholder 1Placeholder 2
in-game GUIsNone/custom

(poor set of native graphic controls)
Yes

(offered by libgdx)
custom

(partially implemented)
Lua libs?Placeholder 1Placeholder 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

#3
Quote from: Monsieur OUXX on Mon 08/01/2018 14:28:48
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.

Quote from: Monsieur OUXX on Mon 08/01/2018 14:28:48
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

Quote from: eri0o on Mon 08/01/2018 14:37:57
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

Quote from: Crimson Wizard on Mon 08/01/2018 14:45:45
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

#6
Quote from: Monsieur OUXX on Mon 08/01/2018 14:46:38
Quote from: Crimson Wizard on Mon 08/01/2018 14:45:45
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:
Quote from: Monsieur OUXX on Mon 08/01/2018 14:28:48
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:
QuoteIt 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

#8
Quote from: Monsieur OUXX on Mon 08/01/2018 15:42:25
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

#9
Quote from: Crimson Wizard on Mon 08/01/2018 16:01:28
Quote from: Monsieur OUXX on Mon 08/01/2018 15:42:25
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

#10
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

#11
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

Quote

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.

Quote

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

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

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

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

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

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

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

Quote
Data structures / serialization / database-like processing
c# (the standard library and existing libraries) probably has everything you want and more.

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

Quote
@tzachs, could you clarify the points below:
Ok, you added this as I was typing, so parts I haven't touched on yet:

Quote
- implementation of usual point n click entities yes/no (rooms, characters, inventories, objects…)
yes to all (I think).

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

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

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

#14
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.
Joseph DiPerla--- http://www.adventurestockpile.com
Play my Star Wars MMORPG: http://sw-bfs.com
See my Fiverr page for translation and other services: https://www.fiverr.com/josephdiperla
Google Plus Adventure Community: https://plus.google.com/communities/116504865864458899575

Monsieur OUXX

Quote from: Joseph DiPerla on Tue 09/01/2018 00:35:37
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

Quote from: Monsieur OUXX on Tue 09/01/2018 09:25:08
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

#19
@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
 

Monsieur OUXX

Quote from: Crimson Wizard on Tue 09/01/2018 09:35:06
Quote from: Monsieur OUXX on Tue 09/01/2018 09:25:08
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).

Yes, AGS makes it even worse, because its behaviour can lean to either side of my chart depending on the renderer chosen in the settings. AGS' obsolete dependencies have magically turned this paradigm into some sort of hardware uncertainty instead of being strictly a design choice. Oh, AGS! (roll)


Quote from: Crimson Wizard on Tue 09/01/2018 09:35:06
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.
Yes, but there's a reason why it's never used (several plugins have appeard along the way to tap into DirectX's abilities, and they all died from lack of support). There shouldn't be a "programming genius" inbetween the game designer and the engine. The game designer should be able to use the 3D engine's abilities (using simple, high level code) by himself. that's what MonoAGS lets us do. And that's good.

Moving back to my concern of "OK but OpenGL does virtually nothing, I'd recommend using some middleware" : As an illustration, think of how Unity's high-level 3D primitives are used in this purely 2D example : https://unity3d.com/fr/learn/tutorials/s/procedural-cave-generation-tutorial
Do we really want to implement all those fantastic objects (2D grid, etc.) by hand?
 

Crimson Wizard

#21
Quote from: Monsieur OUXX on Tue 09/01/2018 09:40:30
- 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)

These things (and others) may work differently in MonoAGS, for instance room background is basically another object. Also I gave few of my crazy ideas to tzachs, some of them he seem to have implemented already, such as "infinite rooms" that stretch into any direction forever :). I believe in that case you won't have a static background, but dynamically created and adjusted layers, or something like that.

Monsieur OUXX

Quote from: Crimson Wizard on Tue 09/01/2018 10:33:29
These things (and others) may work differently in MonoAGS, for instance room background is basically another object. Also I gave few of my crazy ideas to tzachs, some of them he seem to have implemented already, such as "infinite rooms" that stretch into any direction forever :). I believe in that case you won't have a static background, but dynamically created and adjusted layers, or something like that.

I don't think anyone minds as long as the graphics used for the room (if any) is updated easily from the file system (through any given process that you would come up with), and if that update does not block another person working on the project.
 

Monsieur OUXX

#23
@tzachs : I finally got to have a look at your source code, and I must say it looks really really promising.

Here are my concerns :
- Like I said before, all my concerns about Sound Engine and about Assets Management are gone. Hurray!
- I'd still feel more comfortable if GUIs management was unloaded onto some third-party library like GTK# or similar,
- Keep an eye on (mild) reflexivity. One day we might want to make it possible to access objects properties through script* (for example, through an in-game console). Therefore, be careful with "anonymous" fields used by Protobufs/Protocontract. Oh wait this is actually C#. We can access an object properties through its name any time, any place.
- I suggest even more than previously the use of automatic solution generation, since I saw that you have one .sln file per target platform. https://www.reddit.com/r/dotnet/comments/6hmjrf/cmake_now_support_c/
- I'm kinda worried that there are platform-dependent wrappers for every core feature, such as drawing, input, etc. Isn't that managed by OpenTK? Or is it only some "transparent" wrapping meant for some basic C# trick (make advantage of interfaces or whatnot)?
- I would suggest taking the opportunity of this engine rewrite to put some distance between the absolute core point n' click engine (rooms, inventories, etc.) and the things that might be custom. Two examples from the top of my head : the hard-coded fade-in/fade out as seen in RoomEvents.cs, and the player's behaviour on Verb events as seen in Player/Approach. I'm not saying you should kill all that, I'm just suggesting that you imagine what could be this "less hard-coded layer of code", and that you move those things there after creating the required event hooks in the core.
- event hooks! event hooks everywhere! E.g. OnNewItemInInventory
- Have you considered an importer for an existing AGS 3.4 project? --> That would be for the community. remember how many people had a hard time switching from 2.72 to 3.0?
- You have re-implemented all the usual classes such as lists, dictionaries, events, trees (you're literally using C#!), point, rectangle (you're literally using OpenTK!), etc. I won't complain because everyone does it (ScummVM, etc.), but... what is it with you people?
- One big big concern: the IDE as it is now, and even if you intgrate an "editor" as an in-game GUI, the game development workflow would be to run and debug the game from within Visual Studio. Even if it's a free Visual Studio, we can't redistribute it, which means that we must tell the users to download two separate things: 1) MonoAGS, and 2) Visual Studio. For me that's a no go. Any solution would be better than that -- like swapping to SharpDevelop or MonoDevelop. An answer that comes to mind is : "no, you misunderstood, first you compile the game in visual studio but then you can distribute the unfinished game to develop it 'from within itself', as some sort of standalone Editor" --> that doesn't sound like a good solution, because then you can't change (and recompile) any custom script inside it as long as it travels outside of visual Studio.

* Just in case you wonder why, here is one possible illustration : that could come handy for commercial games to automatically patch softlocks that many players might have in their saved game.

Overall I would like to congratulate you for how compact is your code.
Also, kudos for using async/await.
 

Crimson Wizard

#24
Quote from: Monsieur OUXX on Tue 09/01/2018 14:00:59
- I would suggest taking the opportunity of this engine rewrite to put some distance between the absolute core point n' click engine (rooms, inventories, etc.) and the things that might be custom. Two examples from the top of my head : the hard-coded fade-in/fade out as seen in RoomEvents.cs, and the player's behaviour on Verb events as seen in Player/Approach. I'm not saying you should kill all that, I'm just suggesting that you imagine what could be this "less hard-coded layer of code", and that you move those things there after creating the required event hooks in the core.

Lol, right, Monsieur OUXX, I am pestering tzachs about this from the first moment I learnt about the engine. Even suggesting my aid in dividing things apart :).
But, I guess, this could use a community's hive mind examination at some point too.


BTW, I do not remember if tzachs mentioned about this, but in his engine the game objects are actually component-based, like in Unity, which means you may convert one object into another by adding/removing/replacing behavior component.

For example, your character has behaviors like (dummy names, because I do not remember them) HasVisuals, CanBeInRoom, HasInventory, etc. Now, at any point in time you add CanBeOnGUI behavior, and boom, character becomes a GUI element, while retaining everything else, walks among the buttons and talks to labels. ... well, assuming you also add TalkTo interactions to them.
(I believe you may see basic example of this in the Demo Game's feature demonstration menu.)

Monsieur OUXX

#25
Quote from: Crimson Wizard on Tue 09/01/2018 15:18:03
Quote from: Monsieur OUXX on Tue 09/01/2018 14:00:59
- I would suggest taking the opportunity of this engine rewrite to put some distance between the absolute core point n' click engine (rooms, inventories, etc.) and the things that might be custom. Two examples from the top of my head : the hard-coded fade-in/fade out as seen in RoomEvents.cs, and the player's behaviour on Verb events as seen in Player/Approach. I'm not saying you should kill all that, I'm just suggesting that you imagine what could be this "less hard-coded layer of code", and that you move those things there after creating the required event hooks in the core.

Lol, right, Monsieur OUXX, I am pestering tzachs about this from the first moment I learnt about the engine.

I've read that in many of your comments, but I wasn't sure that I was targetting the "same" code separation, because here I'm specifically targetting stuff that wasn't even separated in AGS itself (blocking room transitions being the most obvious example)

Quote
Component-based
Yes, that's very good.
 

ChamberOfFear

Quote from: Monsieur OUXX on Tue 09/01/2018 14:00:59
Even if it's a free Visual Studio, we can't redistribute it bla bla bla ...

I presume you got too hung up on Visual Studio that you took the time to breathe and realize that there are other options (The fact that you mentioned SharpDevelop as an option suggests to me that you're not really up to date). A ton of stuff has happened with the .NET eco system since they open sourced it. You can use Visual Studio if you like, you can use MonoDevelop you like, you can use Atom, you can use Visual Studio Code, you can use ViM, you can use eMacs, you can even use notepad and command line build tools. There's not really any restrictions anymore since Microsoft released the dotnet CLI tools, which is a lot more user friendly than MSBuild. Support for writing and building C# is easy, accessible and free.

Presumably the future IDE would be distributed with the dotnet CLI tools included, so that anyone would be able to build the game. If you need to code you could download you favorite code editor software, which most likely has a plugin for C# building. I have a hard time picturing a coder which wouldn't be delighted over the opportunity to use their favorite tool for game development.

Monsieur OUXX

Quote from: ChamberOfFear on Tue 09/01/2018 16:24:50
Presumably the future IDE would be distributed with the dotnet CLI tools included, so that anyone would be able to build the game. If you need to code you could download you favorite code editor software, which most likely has a plugin for C# building. I have a hard time picturing a coder which wouldn't be delighted over the opportunity to use their favorite tool for game development.

All I'm saying is that you can't legally redistribute Visual Studio (true?). Therefore AGS 5 can't be shipped with it (true?). Therefore if we want to be serious, AGS has to be shipped with another, user-friendly way of building the game. I know programmers (I am one) love to say "here are the sources, all you have to do is..." but real-life people, especially AGS users, need to have an all-inclusive solution provided. Not to mention AGS is portable (it doesn't have to be installed).
MonoAGS has been made with Visual Studio so far, and we know how sometimes it's tricky to build a program in a different IDE than the one in which it was originally built. I'll believe it can be built with a free, open-source, redistributable, portable IDE when I see it.

@tzachs, a question for you : why did you put emphass on functional languages in the docs? did you have some advantage on mind regarding the making of a game with your engine?

 

eri0o


tzachs

Quote from: 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.
Ah, great explanation, thanks!
Yes, it's a valid concern against OpenGL which I was not really aware of. I'll need to study it more.

Quote from: Monsieur OUXX
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.
So that's another reason for me to switch to dotnet core, their csproj supports globbing patterns so you don't have to specify specific files that are included in the project (it's possible that mono supports the new csproj too now, btw, not sure). Besides the csproj there's nothing else so there would be no conflict here.

Quote from: Monsieur OUXX
- 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)
Room background is not separate. All assets are treated the same (at least when developing): files in the file system.

Quote from: Monsieur OUXX
- 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)
Hmmmm, that's a touchy subject. I understand your concern, but on the other hand named assets are also important for intellisense and avoiding typos. It's currently not a problem but it might be when I develop the editor- I'll think about how to address that when I get there.

Quote from: Monsieur OUXX
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 ought about GTK?
Yes, I thought about GTK# among others. I have two problems with that:
1. I want to be able to have the GUIs as part of the world, meaning I need to control when and where to render it with OpenGL. So that pretty much rules out all GUI libraries that are not OpenGL based. The best GUI framework I found for OpenGL is nanogui, which I still consider my fallback plan if my current plan doesn't work as I want. The problem with that is nanogui's c# binding looks abandoned which means that I'll need to maintain the binding myself, plus get a deep understanding of nanogui workings and I tend to believe that the weight this will carry on me is not smaller then have my own framework in place. And also, this doesn't solve my second problem...
2. So, what Crimson Wizard said here:
Quote from: Crimson Wizard
Now, at any point in time you add CanBeOnGUI behavior, and boom, character becomes a GUI element, while retaining everything else, walks among the buttons and talks to labels.
I'll basically lose this ability for GUIs if I follow that route. The fact that GUIs in the engine are treated the same as all other objects and can be manipulated the same, I feel that's a great power for the engine to have.

Quote from: Monsieur OUXX
Therefore, be careful with "anonymous" fields used by Protobufs/Protocontract.
Just to be clear here, protobuf is just used for the saved games file format, that's it.

Quote from: Monsieur OUXX
I suggest even more than previously the use of automatic solution generation, since I saw that you have one .sln file per target platform.
mmm, no? I only have one sln file. Are you talking perhaps about the csproj files? I have a csproj file per platform, not a sln file per platform. I'll have to read about cmake for c# more, I'm kind of hesitant because I didn't see any c# project actually using it yet (but maybe it's because it's new, based on your link). There's a known solution for the multiple projects per platform in the c# world: Protobuild- it's used by both MonoGame and Xage, so I'm more inclined to use it. However I'm still not convinced that the added dependency (be it protobuild or cmake or something else) and the cost that goes with it is worth the multiple projects "pain", maybe it's because I haven't experienced that pain yet, currently I kind of like that clean separation between projects. Also protobuild does not currently support dotnet core as far as I know- I did want to play with it at some point to gain a better understanding of the benefits, but I don't consider this a priority. If another contributor will come and want to add something like that, I'll probably not going to stop her/him though (except for the dotnet core issue...).

Quote from: Monsieur OUXX
- I'm kinda worried that there are platform-dependent wrappers for every core feature, such as drawing, input, etc. Isn't that managed by OpenTK? Or is it only some "transparent" wrapping meant for some basic C# trick (make advantage of interfaces or whatnot)?
For graphics rendering, OpenTK supplies OpenGL bindings and OpenGL ES bindings. Those are not the same unfortunately. So I have 2 implementations of "IGraphicsBackend", the OpenGL one is used by desktop (Windows, Mac and Linux), and the OpenGLES one is used by Android & IOS. And I'll probably need yet another implementation when I add UWP (xbox and windows store) which will either be DirectX or Angle. For input, OpenTK handles it cross-platform for desktops but not for mobile: I use the xamarin APIs which are native representations of the android and ios APIs, but they are not the same. I might switch in the future if I find something.
For bitmap and text rendering, I also currently have 3 implementations (desktop, android and ios) but I want to switch to SkiaSharp which is completely cross platform (and also gives a lot of other benefits like hardware accelerated text rendering). Currently stuck on this, btw: if somebody knows/figures out how to solve this, let me know.

Quote from: Monsieur OUXX
- I would suggest taking the opportunity of this engine rewrite to put some distance between the absolute core point n' click engine (rooms, inventories, etc.) and the things that might be custom. Two examples from the top of my head : the hard-coded fade-in/fade out as seen in RoomEvents.cs, and the player's behaviour on Verb events as seen in Player/Approach. I'm not saying you should kill all that, I'm just suggesting that you imagine what could be this "less hard-coded layer of code", and that you move those things there after creating the required event hooks in the core.
Yes, I'm discussing solutions with Crimson Wizard. However... rooms are not adventure game specific? Room = Scene, and every game engine on the planet (I think) have this concept. The "OnBeforeFadeIn/OnAfterFadeIn" events for moving in/out between scenes is also generic and not adventure game specific.

Quote from: Monsieur OUXX
- event hooks! event hooks everywhere! E.g. OnNewItemInInventory
MonoAGS has event hooks a-plenty. All lists that are marked as "IAGSBindingList" have an "OnListChanged" event which gives all the items that were added/removed from that list. Good call on the inventory items though, as I didn't change it from "IList" to "IAGSBindingList" yet, will fix.
Also, all components implement "INotifyPropertyChanged", which you can subscribe to and get events whenever any property in the component changes (this is how the inspector refreshes itself to show you whenever something changes in the game).

Quote from: Monsieur OUXX
- Have you considered an importer for an existing AGS 3.4 project?
I suspect it's going to be crazy amount of work. If somebody else wants to work on it, that would be great. I'm not going to, though, not in the foreseeable future.

Quote from: Monsieur OUXX
- You have re-implemented all the usual classes such as lists, dictionaries, events, trees (you're literally using C#!), point, rectangle (you're literally using OpenTK!), etc. I won't complain because everyone does it (ScummVM, etc.), but... what is it with you people?
lol, yeah, it looks bad...
My core engine library targets dotnet standard which means I can target both dotnet framework, mono or dotnet core.
OpenTK is still not officially supported with dotnet core (it's in progress), meaning that the core engine can't reference OpenTK, only the desktop engine project can reference it. So I had to copy a bunch of their classes to make it work. Once they support dotnet core I'll be able to remove those.
For drawing bitmaps, I used stuff from System.Drawing which is also not part of the dotnet standard so I had to take dotnet framework code. Once I switch to SkiaSharp I'll be able to remove those.
And finally, my binding list is not taken from c#, it's my implementation that's there for adding those hooks you mentioned earlier which don't exist in the original list implementation. And tree is also my implementation, there's no tree data structure in c#.

Quote from: Monsieur OUXX
@tzachs, a question for you : why did you put emphass on functional languages in the docs? did you have some advantage on mind regarding the making of a game with your engine?
I don't think I did? I just listed F# as potentially the best candidate if you want to code your game using something not c#, because I know it's a dotnet implementation that is actively supported by Microsoft, and I'm not sure how actively maintained and complete other dotnet implementations are (everything else afaik is developed by the community and not sponsored by major players, I might be wrong about that).

Quote from: Monsieur OUXX
- One big big concern: the IDE as it is now, and even if you intgrate an "editor" as an in-game GUI, the game development workflow would be to run and debug the game from within Visual Studio. Even if it's a free Visual Studio, we can't redistribute it, which means that we must tell the users to download two separate things: 1) MonoAGS, and 2) Visual Studio. For me that's a no go. Any solution would be better than that -- like swapping to SharpDevelop or MonoDevelop. An answer that comes to mind is : "no, you misunderstood, first you compile the game in visual studio but then you can distribute the unfinished game to develop it 'from within itself', as some sort of standalone Editor" --> that doesn't sound like a good solution, because then you can't change (and recompile) any custom script inside it as long as it travels outside of visual Studio.
Ok, so I guess it's time to talk about my plans for the editor (important note - everything here is subject to change and might not actually happen).
First, regarding your concern: I'm hoping to distribute the editor in several flavors: the standalone version will come bundled with the dotnet cli but without any IDE. Like persn said, you'd be able to use pretty much any ide you want (you can program in notepad if that's what you want) with that. That's pretty much the equivalent for unity.
Other flavors would be as IDE add-ins, and I'm planning to target Visual Studio and MonoDevelop (hopefully all flavors will share as much code as possible between them), though that's probably not going to happen for the first version (version 0.1 coming sometimes this decade to your home). The MonoDevelop addin can be packaged together with MonoDevelop and distributed. For the visual studio flavor, yeah, you'll want to download VS first and then download the AGS extension.

Regarding what you said earlier about hard-coded verbs: the plan is for the editor to have somewhere a place to edit your list of verbs (or you'll use a game template which has the verbs pre-set). The editor will auto-generate a "Verbs.cs" file with your verbs, and the core engine itself will not have knowledge about specific verbs.

You'll also be able to edit your outfits and choose which animations are part of that outfit, those animation names will also be auto-generated to a cs file.
As for the animation editor, I plan to have a basic layout like AGS has with individual frames and live preview, but also will have a "switch to timeline" button: this will place your frames on the timeline, and you'll be able to add tweening for properties (shown on separate tracks in addition to the frames), and possibly set various blendings. And one last thing for the animation editor would be to allow for composition animations -> show the entire object tree so that you'll be able to have separate animations for the head and body (for example) and see how they work together.

For the room/scene designer, I plan the canvas to have a similar interface that InkScape has for moving/rotating/scaling objects (with grid lines/snapping for alignments etc) and for editing areas something similar to InkScape vector tools as well. In the tree view of the scene you'll be able to show/hide/lock/unlock layers or individual objects, and selecting an object will show the inspector (called "Properties Window" in AGS but the same principle, pretty much exists in all editors). From the inspector you'll be able to set values and add/remove components. You should be able to switch between "playing the room" to "editing the room" immediately (I hope), or maybe even editing while playing. You'll be able to see and edit the GUIs from the scene designer (they might not "belong" to the scene, but it's just that more convenient to see how the game will actually look from the editor). When adding a new object to the canvas you'll be able to select from various presets (object, character, button, etc): each preset is basically an entity with a specific set of components and defaults. The presets that are available for you to use will be dictated by the game template you choose, or you'll be able to create your own presets (or import from modules, etc). This is kind-of similar to prefabs in unity (but not as powerful- will probably extend this to be as powerful eventually). For each of those presets a friendly interface will be auto-generated for your coding pleasure (so you'll be able to write "character.Walk" instead of "character.GetComponent<IWalkComponent>().Walk").

For events/interactions- my observation here is that for most adventure games, most of the interactions are basically the player character says something in response for looking/interacting with an object in the room. Really, I don't think I'm exaggerating if I say that's 75% of interactions in a typical game is just that. That's why, I want first to make this as painless as possible. If you type on a object/verb combo line in the editor, it would automatically translate into player.Say(..whatever you typed..). Otherwise you'll have either the current AGS option of going straight to code, or you'll have the option to open the interaction editor. The interaction editor might be similar in some ways to what Blade Coder has. At least for the first phase, I'm not planning to have graphs with nodes a-la articy/draft, but a list of interactions with if/else branching as indented, we'll see how it goes and maybe I'll re-evaluate. The functions in the interaction editor (like the properties from the inspector, btw) will have help links directly in the editor (it will be extracted directly from the api documentation for built in functions/properties, and extracted from code attributes for external modules). You should be able to run code from the interaction editor and to run saved editor interactions from the code. Also, the interactions themselves will not be hidden, code will be generated for you so this can also be seen as a learning tool. And finally, I plan to have async/await support directly in the interaction editor. Hard to explain without a picture, but basically if you add a "Walk", for example, it will add an "await" with "walk" on the same line, but then you'll be able to drag the "await" section to its own line and put other actions between the "walk" and the "await" so you can have the character walk in parallel to other things going on in this cutscene.

Another interaction related feature I want to have is a "matrix" window. This aims to be a productivity enhancer for writing interactions in bulks and also to solve the problem of a lot of games (that drives me crazy) where the developer forgets to code all of the interactions. The matrix window will have all interactable objects + inventory items as both rows and columns. Each cell is an interaction that has to be filled. You'll have a nice "you're 64% there!" label showing you how much of the interactions are done. And you'll be able to click on each cell to edit the interaction (with any of the methods I talked about for interactions), you'll also be able to mark specific cells as "default" (which will activate that whatever "I can't do that" default interaction you configured) or as "bug: not supposed to happen" (which will also activate the default interaction but might do something else like crashing you if you debug, or send an email from a tester or whatever you set it to do on "bug"). You'll have some controls for filtering the matrix to specific rooms/only inventory/etc if it's getting too big and/or you want to focus on something specific. And finally, you'll have a "start marathon" button which will rotate between "unfilled cells" with easy shortcut keys to pass to the next interaction.

As for speech, this is also a big pain-point for me with current AGS. I still want to support the current workflow, but also have a speech control window (maybe somewhat similar to the speech center plugin), and you won't be forced to number your speech lines in the code yourself, the string itself will be the id and map to a numbered filename (or filenames for multiple localilizations), though you'll be able to override with a number for specific lines (like if you have multiple lines with the same string but need to be said differently). You'll be able to write director notes in the speech window for specific lines, and create nice looking scripts for voice actors. Also, there will be a "start marathon" button here too, you'll select a character and it will run over all of the script lines for that character and open the speech line editor. From the speech line editor you'll be able to record the voice and do basic editing. When recording you'll have keyboard shortcuts to stop this take and start a new take, and a shortcut to move to the next line. For editing you'll be able to trim beginning/end of takes, change volume/pitch/reverb. You'll be able to delete takes, and keep multiple takes (for repeating sentence where you might want some variation in how a character says a line). I still painfully remember the amount of time it took to get the independently recorded lines from the voice actor, open a big-ass audio software where all I want to do basically is select the good takes, and then do some trimming and volume adjustments, then manually exporting to files, figure out the correct filename and then needing to test it in the game to see that I completely screwed it up... This whole process took ages. Hopefully doing it all in-editor will save huge amounts of time.
Another interesting possibility here that I want to explore, is being able to open the speech line editor directly as you're playing the game. So, for editing, the game developer will be able to edit lines while playing the game which gives better context. For recording, if the voice actor is recording remotely, the game developer might prepare a few saves where the character speaks, and either instruct the voice actor what to do to get to her/his lines, or even code to directly cut to the dialogs. If the voice actor is recording with the developer in a studio, then hopefully the game developer could bring her/his laptop and hook it up to recording hardware, and switch to the saves/coded dialogs while showing the monitor to the voice actor. The goal here is that the context of the actions will be much clearer to the voice actor as the dialogs are played.

I'm going to skip various other things the editor needs (editing settings, deployments, fonts, cursors, and I maybe forgot lot of important points), but one last point I want to touch on is customizability.
There are obvious customizations you can expect, like authoring your own components and being able to edit their properties in the designer.
But more than that, as the editor will be using the same framework as the engine, it will use the same mechanisms for customizations the engine uses: meaning, almost everything should be able to be replaced if you want. You'll be able to code your own inspector if you so choose and replace the existing inspector (and then share it as a module for other developers), etc.

Quote from: Monsieur OUXX
Overall I would like to congratulate you for how compact is your code.
Also, kudos for using async/await.
Thanks :)

Theme

Quote from: tzachs on Tue 09/01/2018 22:02:43
The best GUI framework I found for OpenGL is nanogui,

Sorry for not reading everything, but did you take a look at https://github.com/ocornut/imgui
I'm using in my project, it's a immediate mode gui that works with opengl and it's in constant update.

Monsieur OUXX

#31
@tzachs : you have addressed all my worries, except for the IDE (second point below).

- About Protobuild : (btw, yes I meant multipe .csproj, not multiple .sln) you said you haven't experienced the pain of the multiple projects to maintain.
Out of curiosity, how do you currently work? Is it like this: You have the several .csproj in VS and when you build, it builds them all and you trust that is the MacOS project got built successflly, then it's OK? (not that Protobuild would address that paradigm -- just trying to have some context). The pain usually comes later, after seveal years, when you need to let users use a different IDE/Compiler or a newer version of the original IDE. You get entangled in the many versions of VS -- well not you specifically because you know how to upgrade your csproj, but there's always someone who asks about a version that you don't own -- and you cry.
I mentionned VS but I'm perfectly aware that nowadays the VC++ restributable bullshit is gone, so don't hit back on VS. My concern can be applied to trying to compile a .csproj with any "unforeseen" IDE/compiler. That's when the automated project generation becomes a magical tool.
Just sayin'.

- About the IDE : still very skeptical. the statement "you could virtually make your game in Notepad" is not acceptable, but it's always something that's very hard to hear for developers. I could virtually make my AGS game in Notepad just by writing XML. Bleh. The fact that the game designer can carry around his CLI tools is not an answer either. He/she wants to press "play", not type command line commands to run compilation. Finally, the IDE has a second purpose: organizing files and assets, and allowing thirs-party tools (plugins), as you and hamberOfFear mentionned.
Therefore, I'm asking again: what's the plan regarding a 1) legally distributable, 2) lightweight, 3) portable (no installer needed), 4) cross-platform IDE that would be rebranded "AGS 5"?
For now, MonoDevelop addresses these criteria, I believe, but is available from source only (!) and is apparently complex to turn into a portable installation. I'm not surprised that the Unity guys managed to do it, and make it seem easy, but they have way more time and money to achieve miracles ;)

 

ChamberOfFear

Quote from: Monsieur OUXX on Wed 10/01/2018 08:29:41
The fact that the game designer can carry around his CLI tools is not an answer either. He/she wants to press "play", not type command line commands to run compilation.

Maybe I was being ambiguous in my previous post, but I hope it was understood that I wasn't actually suggesting that the user of the IDE was going to type commands, because that's just insane. The dotnet CLI tools would just be prerequisite to install, in the same way that the .NET runtime and Visual C++ redistributables already is for the current AGS. The actual command typing commands would be handled "under the hood" in the IDE. From the end users perspective it would still be a build and/or play button, like we already have.

I didn't have time to read @tzachs post since I'm at work so I hope I didn't say something that was already said.

Monsieur OUXX

Quote from: ChamberOfFear on Wed 10/01/2018 10:07:51
Quote from: Monsieur OUXX on Wed 10/01/2018 08:29:41
The fact that the game designer can carry around his CLI tools is not an answer either. He/she wants to press "play", not type command line commands to run compilation.

Maybe I was being ambiguous in my previous post, but I hope it was understood that I wasn't actually suggesting that the user of the IDE was going to type commands, because that's just insane. The dotnet CLI tools would just be prerequisite to install, in the same way that the .NET runtime and Visual C++ redistributables already is for the current AGS. The actual command typing commands would be handled "under the hood" in the IDE. From the end users perspective it would still be a build and/or play button, like we already have.

I didn't have time to read @tzachs post since I'm at work so I hope I didn't say something that was already said.

That's good. I assume that CLI is also redsitributable, like VC++ rdistributables were. But the IDE needs to be redistributable (licensing) too. That was one of the strong advantages of AGS: lightweight, free and portable.
 

[delete}

qptain_Nemo told me that MonoAGS most likely will run on Arch Linux ARM too.

So, green light also from my side:


Monsieur OUXX

#35
Quote from: ChamberOfFear on Tue 09/01/2018 16:24:50
The fact of mentionning SharpDevelop as an option for the IDE suggests that not being really up to date with the .NET eco system.

@ChamberOfFear Can you explain how? Which specific point do I misunderstand? Is it only compatible with "traditional" .Net Framework? Is it compatible with Mono? Is it compatible with .Net Core? Is it out of support? Etc. It's free, portable, lightweight, under MIT license, and specfically targetted at C#, so it makes it a very appealing candidate.

@tzachs Any reason why you don't use Monogame as the "middleware" that other point-n-click engines use? (see initial table). It has recently switched to .Net Core and it has the most permissive Microsoft license. I know it was mentionned before but we never elaborated. It might not be too late.

Other question : do you use tools such as mkbundle or Monokickstart to bundle Mono in the current version of MonoAGS?
 

tzachs

Quote from: Theme on Wed 10/01/2018 07:21:23
Sorry for not reading everything, but did you take a look at https://github.com/ocornut/imgui
I'm using in my project, it's a immediate mode gui that works with opengl and it's in constant update.
I did look at it. I ruled it out mainly because I'm not sure how "immediate mode" integrates well with my design. Also I remember reading about it and people were talking about it more as a "GUI prototyping tool". And finally, the sample picture on the c# binding front page didn't look appealing. On the plus side the images on the original imgui project look better, and the c# binding is actively maintained, so I will keep it in mind.

Quote from: Monsieur OUXX
You have the several .csproj in VS and when you build, it builds them all and you trust that is the MacOS project got built successflly, then it's OK?
First of all, when I develop I rotate between developing from Mac and developing from Windows (and I'll add Linux to my rotations when support is added for that) to see that things are working well on both platforms. When I compile locally, I only compile the projects for the platform I'm testing, so I'm not compiling mobile if I don't test mobile. Once I submit a PR, the automated build kicks in which compiles for all platforms and runs the tests.

Quote from: Monsieur OUXX
The pain usually comes later, after seveal years, when you need to let users use a different IDE/Compiler or a newer version of the original IDE. You get entangled in the many versions of VS -- well not you specifically because you know how to upgrade your csproj, but there's always someone who asks about a version that you don't own -- and you cry.
I mentionned VS but I'm perfectly aware that nowadays the VC++ restributable bullshit is gone, so don't hit back on VS. My concern can be applied to trying to compile a .csproj with any "unforeseen" IDE/compiler. That's when the automated project generation becomes a magical tool.
I don't think that's currently a problem in c# world. There are multiple IDEs, but only a single compiler (Roslyn) which everybody uses. If it will become a problem, I will re-evaluate.

Quote from: Monsieur OUXX
the statement "you could virtually make your game in Notepad" is not acceptable, but it's always something that's very hard to hear for developers. I could virtually make my AGS game in Notepad just by writing XML.
Perhaps notepad was a bad example, but the point here is that while you can write your AGS game with XML on notepad, you can't debug it without the AGS editor, you don't have intellisense, code navigation, etc, without the AGS editor. With MonoAGS you can do all that without the editor, and you'll be able to do that no matter which flavor of the editor you install. Now, this wasn't meant as an answer to your specific concerns, this is obviously not a solution to a lot of people who want something built in. But it is very important to a lot of people who already have their favorite IDEs/tools and want to stick with it.

Quote from: Monsieur OUXX
The fact that the game designer can carry around his CLI tools is not an answer either. He/she wants to press "play", not type command line commands to run compilation.
Sorry for not being clear, you'll have a "play" button in the standalone version which will run the cli tools.

Quote
For now, MonoDevelop addresses these criteria, I believe, but is available from source only (!) and is apparently complex to turn into a portable installation. I'm not surprised that the Unity guys managed to do it, and make it seem easy, but they have way more time and money to achieve miracles ;)
If MonoDevelop doesn't pan out, then I'll search for alternatives, or worst case (don't want to go there, but it's always an option) build my own.
Btw, apparently unity are now shipping with Visual Studio instead of MonoDevelop. So maybe it is possible to bundle with Visual Studio (or maybe Unity and Microsoft made a deal, I don't know).

Quote from: Amélie
qptain_Nemo told me that MonoAGS most likely will run on Arch Linux ARM too.
I hope? I saw that dotnet core supports Arch Linux, don't know about Arch Linux ARM.

Quote from: Monsieur OUXX
@tzachs Any reason why you don't use Monogame as the "middleware" that other point-n-click engines use? (see initial table). It has recently switched to .Net Core and it has the most permissive Microsoft license. I know it was mentionned before but we never elaborated. It might not be too late.
When I first started development, MonoAGS was a very strong candidate for a backend. I started installing the framework, but I remember the instructions were very confusing for me, and I don't remember if ever got it to work. I remember thinking "yeah, it's not going to fly with non-programmers". Also MonoGame (or any complete game engine) brings with it a lot of baggage, dependencies, opinions and quirks that restrict my own design. Not using it gives me more freedom. However, I'm not ruling out looking into integrating with MonoGame as an optional backend (same goes for Unity, btw).

Quote from: Monsieur OUXX
Quote from: ChamberOfFear
The fact of mentionning SharpDevelop as an option for the IDE suggests that not being really up to date with the .NET eco system.
@ChamberOfFear Can you explain how? Which specific point do I misunderstand? Is it only compatible with "traditional" .Net Framework? Is it compatible with Mono? Is it compatible with .Net Core? Is it out of support? Etc. It's free, portable, lightweight, under MIT license, and specfically targetted at C#, so it makes it a very appealing candidate.
From what I can gather from their Github page, SharpDevelop is Windows only.

Quote from: Monsieur OUXX
Other question : do you use tools such as mkbundle or Monokickstart to bundle Mono in the current version of MonoAGS?
No work was done regarding deployment yet, so no. Also, as I plan on removing Mono, most likely I will not use those.

Crimson Wizard

Quote from: tzachs on Tue 09/01/2018 22:02:43
Quote from: Monsieur OUXX
- Have you considered an importer for an existing AGS 3.4 project?
I suspect it's going to be crazy amount of work. If somebody else wants to work on it, that would be great. I'm not going to, though, not in the foreseeable future.

I would like to make a small note about this, saying that it does not even have to be tzachs to make such project converter.

AGS project's format is known and parsing code available. MonoAGS project's format will be known (when it's fleshed out) and code available. So, format-wise - no problem. Two problems that I foresee:
* Finding a correspondence between AGS entities and MonoAGS entities, because same things could be represented in different ways in these two engines.
* Converting scripts, because language is slightly different, and many classes/functions names are different.
I believe this will require coding some kind of wrapper for MonoAGS to emulate AGS behavior. Like AGSCharacter, extending AGSMono's Character class, and so on.

Monsieur OUXX

#38
Quote from: Crimson Wizard on Wed 10/01/2018 15:24:25
I believe this will require coding some kind of wrapper for MonoAGS to emulate AGS behavior.
I was thinking the same thing. The (small) thing is that MonoAGS doesn't have a parser for AGS script or loading AGS resources. So it might be simpler to do it on AGS side, as an exporter.
 

tzachs

Right, Clarvalon has released an exporter to Xage (with source, apparently) which might be a good place to start.

Monsieur OUXX

Quote from: tzachs on Wed 10/01/2018 16:20:15
Right, Clarvalon has released an exporter to Xage (with source, apparently) which might be a good place to start.

True! I forgot about that. Brilliant! Damn, at the moment I work at a very restrictive company (and I have very very long days of work so I have almost zero free time once I'm at home). I can absolutely not toy around with any of that. #frustration :~(

I would strongly suggest to start orienting the amount of energy spent on MonoAGS onto the packaging part, so that a non-hardcore developers community has a chance to slowly emerge.
 

Clarvalon

Bit late to this thread but there's a frightening amount in it that's directly related to what I've been working on, especially in the last six months.  It seems like there's a lot of common ground between MonoAGS and XAGE, so thought I'd chip in.  I tend to neglect my development blog, so apologies for linking to so many individual tweets:

OpenTK:  Not sure I'd recommend this as the back end.  MonoGame previously used it but instead switched to SDL2, at least for the desktop platforms (following in FNA's footsteps) as it is better supported and more actively developed.  That's my layman understanding anyway.

ProtoBuild:  I stopped using this due to lack of .NET core support.  It's planned but I didn't want to wait.  Besides, the new .csproj options, where items are included by default, somewhat negates the need for protobuild as it's fairly trivial to automatically create the .sln and .csproj files you need.

C#:  XAGE automatically creates and updates a bunch of back end base classes - some are static wrappers to the engine via an interface and the rest are dynamically created based on the game project.  The Editor can then automatically create or jump to the C# methods that act as your game events.  I've illustrated this process via a clunky .gif here.  There are some workarounds under the hood as C# script is somewhat stricter than AGSScript, but from an end-user point of view it can feel pretty familiar to AGS depending on your engine API.

.NET Core:  The introduction of .NET Standard 2.0 massively improved the core landscape.  Ethan Lee's MonoKickstart bundler for Linux & Mac seemed to work fine, but getting mono to play nicely with mkbundle, to create standalone executables, was a nightmare.  Eliminating Mono is nice and being able to use dotnet publish seems to work pretty well.

IDEs:  Seems strange for anyone to get hung up on Visual Studio, given the Community Edition is free for small teams and hobbyists.  As per above, you can create an interface between an editor and Visual Studio without too much work.  Maybe it's because the minimum download size is large.  There are also other IDEs that are compatible with .NET Core, as mentioned, Visual Studio Code which is also cross platform.

Protobuf:  Good choice - it is very good for engine game state serialization.  Much faster than everything else I've tried.  Here's an old comparison with XML.

Dear ImGui:  Second the vote for this - it's extremely easy to use.  I recently plugged this into the debug build of XAGE.  There's a nice C# wrapper here that is MonoGame and FNA friendly.

AGS.Plugin.ExportToXAGE.dll  Recently I was kindly given the source to an AGS game that uses runtime plugins, the first time I've encountered this.  As a result, I've been making some recent changes to this editor plugin.  The code in the original thread is quite old.  I could provide a more recent version, though it's a bit messy as it uses remote links to classes in other projects.
XAGE - Cross-Platform Adventure Game Engine (alpha)

tzachs

Quote from: Clarvalon on Wed 10/01/2018 23:32:39
It seems like there's a lot of common ground between MonoAGS and XAGE, so thought I'd chip in.

Hehe, yes, I remember reading your blog ages ago and thinking "wow, this is very close to what I wanted to do too". In fact, one of the reasons I didn't start working on MonoAGS sooner was because I was waiting for Xage (and one of the reasons I eventually started working on MonoAGS was because I thought that Xage was abandoned).
Judging from the recent tweets you linked here it looks pretty sweet.

Quote from: Clarvalon on Wed 10/01/2018 23:32:39
OpenTK:  Not sure I'd recommend this as the back end.  MonoGame previously used it but instead switched to SDL2, at least for the desktop platforms (following in FNA's footsteps) as it is better supported and more actively developed.  That's my layman understanding anyway.
When MonoGame made the decision to drop OpenTK it was when there was a big drama in OpenTK- the main maintainer left the project and it seemed like OpenTK was going to die. As it turns out, it didn't, other people came and took over, and it's very actively maintained now. Btw, from what I remember reading at the time, they switched to SDL2 for window and input, but they stuck with OpenGL and OpenAL and just wrote their own bindings instead of OpenTK.

Quote from: Clarvalon on Wed 10/01/2018 23:32:39
There are also other IDEs that are compatible with .NET Core, as mentioned, Visual Studio Code which is also cross platform.
I'm a big fan of VS Code, and yes, it supports dotnet core for development, the problem with it however is that it doesn't support c# for writing extensions, only Typescript/Javascript. So it doesn't look like I'll be able to bundle my editor with VS Code. Note: there's WebSharp that looked like it could be promising in terms of maybe compiling c# for Electron and then perhaps it is possible to write extensions for VS Code, but it hasn't been touched in a few months so I'm afraid it was abandoned.

Quote from: Clarvalon on Wed 10/01/2018 23:32:39
Protobuf:  Good choice - it is very good for engine game state serialization.  Much faster than everything else I've tried.
Yes, I chose protobuf for both speed and good support for backwards compatibility. Btw, if speed is what your after, rumors has it that Cap'n Proto is even faster the protobuf.

Monsieur OUXX

#43
Guys, thanks for all the feedback above. Lots of accurate things to move the discussion forward.

However there's one point that seems to be continuously misunderstood, which is Visual Studio. I'll say it more time : it does not matter if it's free (money-wise) when it's not legally redistributable, it makes it unsuitable for a packaged AGS. VS Code is not brandable nor redistributable either.

recap one more time :  a potential IDE must be :
Quote
- free (money-wise = zero dollars)
- free (license = you can do a commercial use of the game you make, you can extend the source code, and you can add the AGS logo on the IDE)
- legally redistributable (you can host it ont he AGS website and you can allow to copy it around)
- OPTIONAL BUT HIGHLY WANTED : portable (as in "no installer required")
- OPTIONAL BUT HIGHLY WANTED : lightweight (less than 50MB all included, no separate download/install required beforehand -- in AGS you'd need the .Net Framework, but everyone usually already has it)

SharpDevelop is all of that, VS is not, VS Code is not -- that's is why I'd like someone to explain why ChamberOfFear said it's outdated.
 

eri0o


Monsieur OUXX

Quote from: eri0o on Thu 11/01/2018 11:46:28
Monodevelop is redistributable, isn't?
Yup, it's a mix of LGPL and MIT license. Alsoif I understand correctly it would still be c ompatible with .Net Core (if only using this http://lastexitcode.com/projects/MonoDevelopDnxAddin/ , or natively )
 

tzachs

Quote from: Monsieur OUXX on Thu 11/01/2018 08:28:52
VS Code is not brandable nor redistributable either.
Why not? It's open-source and released under the MIT license.

Quote
SharpDevelop is all of that, VS is not, VS Code is not -- that's is why I'd like someone to explain why ChamberOfFear said it's outdated.
I think you missed my earlier comment on this- it's Windows only which is a deal-breaker. And also, this.

Monsieur OUXX

Quote from: tzachs on Thu 11/01/2018 15:00:38
Quote from: Monsieur OUXX on Thu 11/01/2018 08:28:52
VS Code is not brandable nor redistributable either.
Why not? It's open-source and released under the MIT license.

I don't think so; I think they made it misleading on purpose : https://github.com/Microsoft/vscode/issues/17996
It's written here and there on the Internet that the source code is MIT, but that the EULA states that the use of the software is still licensed, whatever that means.


If it turns out that VSCode is indeed free in every way, then it can become a good candidate. But some effort still needs to be put asap into packaging the thing with MonoAGS, which could be far from trivial.
 

ChamberOfFear

Quote from: Monsieur OUXX on Thu 11/01/2018 15:31:33
I don't think so; I think they made it misleading on purpose : https://github.com/Microsoft/vscode/issues/17996
It's written here and there on the Internet that the source code is MIT, but that the EULA states that the use of the software is still licensed, whatever that means.

If it turns out that VSCode is indeed free in every way, then it can become a good candidate. But some effort still needs to be put asap into packaging the thing with MonoAGS, which could be far from trivial.

I wish I had more time to engross myself in this, but I'm just going to comment this one thing. Doesn't the second post in the issue you linked to contradict your conclusion? In fact, it looks like VS Code meets most of your criterieas, even the one with rebranding (looks like it was designed to meet these criteria), as long as we build it ourselves, which we were going to have to do anyway if we want the blue cup. https://github.com/Microsoft/vscode/issues/17996#issuecomment-273994925

For it to be a viable candidate we'll still need to figure out how to bundle the C# plugin with it of course, and a compiler still has to be included.

Edit:
It looks like plugins can be bundled fairly easy assuming we're using an installer, we'd just have to install them to their designated paths https://code.visualstudio.com/docs/extensions/example-hello-world#_installing-your-extension-locally

tzachs

Quote from: ChamberOfFear on Thu 11/01/2018 16:05:12
It looks like plugins can be bundled fairly easy assuming we're using an installer, we'd just have to install them to their designated paths https://code.visualstudio.com/docs/extensions/example-hello-world#_installing-your-extension-locally

That's cool, however I'm less concerned with how to bundle the plugin, I'm more concerned about how to write it. As VS Code only supports writing your extension in TS/JS it means we either need to figure out how to compile c# to js (there are some solutions but I'm very skeptic regarding their completeness) or do it IPC which I'm afraid will be too slow (unless maybe we duplicate the entire render loop in js which might be a big burden on maintenance). A third possibility might be to fork VS Code, and run c# from Electron directly, but I'm also a little bit skeptic about this.
Another problem is that apparently Electron doesn't work with OpenGL currently, so we'll also need to write a WebGL backend (which might not be too bad, considered doing it eventually anyway for supporting WebAssembly).
I personally prefer VS Code to MonoDevelop, but VS Code looks to be much harder to do in practice.

ChamberOfFear

I'm sorry but you completely lost me. Why does it matter that extensions are written in JS? Why do we need to compile C# to JS? I don't understand what use-case you're trying to solve.

tzachs

For example, I want to run the room designer in a tabbed document window in VS Code. The room designer itself will be written in c#, using components from the engine & API (both c#) and rendering the actual c# game code in the window.

ChamberOfFear

I see, that's interesting. In that case wouldn't a C# to JS transpiler be sufficient? Bridge.NET looks very professional and complete, I'm not sure if the license allows us to use it, don't feel like reading it from top to bottom.

tzachs

Right, Bridge.NET is one of the solutions I mentioned which I'm skeptic about. My concern with Bridge.NET is that it directly transpiles c# to JS, it doesn't compile the generated IL, meaning all the dependencies will need to be compiled as well, and some of them do IL injection, so not sure what the solution there would be.

Either JSIL or WebSharp look like a more appropriate solutions but both look abandoned. I suspect both are abandoned because WebAssembly makes it all obsolete. Both Mono and .Net Core have in progress ports to WebAssembly, and as Electron supports WebAssembly this might be a good solution for the future, but probably not viable for now.

eri0o

Just a reminder you can just do what Unity does and have the thing you write code separated from the rest - this is also how working with Chrome/Firefox developer tools with VSCode works, and I think with Unreal too. People seem to be OK with this - I know in the past we used to have IDEs but not doing it looks to me more maintainable. Also think about a package manager (you can use one that already exists) to share scripts.

Monsieur OUXX

Quote from: ChamberOfFear on Thu 11/01/2018 16:05:12
Doesn't the second post in the issue you linked to contradict your conclusion?

Maybe. The thing is that I wrote this message in a work environment where I couldn't open the link that I linked; I could only read its summary in Google. But the day before I did read several posts in several websites on the Internet, stating that VS Code is a "fake" free software. Anyways that settles it. "Really" MIT = OK for our purposes. Carry on ;)


QuoteUnity, Unreal engine
eri0o I fel like there is an ongoing misunderstanding about Unity and Unreal : I've stated several times that those are not suitable for our purposes for licensing reasons. But you keep posting about them. Unless we decide that AGS should be a Unity plugin and that AGS games will have forever the splash screen/watermark "made with free Unity".

I'm asking again : what's wrong with SharpDevelop?
 

eri0o

I think you are misunderstanding: those are good pieces of software, I am not saying to build AGS on top of any commercial engine, I am saying LOOK AT HOW THEY SOLVE THE EXACT SAME PROBLEMS, and take a note. Seriously.

I have absolutely no idea why you don't look commercial engines up considering considering they have history - not for building on top, taking inspiration, and they have open bits (or are completely open), either on github or bitbucket. I know that I will stay on AGS and migrate to a better maintained engine if the "replacement" is just New Mistakes Edition. It's completely not fun being in middle of development and have your engine swept away.

tzachs

Quote from: eri0o on Fri 12/01/2018 00:16:55
Just a reminder you can just do what Unity does and have the thing you write code separated from the rest - this is also how working with Chrome/Firefox developer tools with VSCode works, and I think with Unreal too. People seem to be OK with this - I know in the past we used to have IDEs but not doing it looks to me more maintainable.

So, as I said earlier:
Quote
I'm hoping to distribute the editor in several flavors: the standalone version will come bundled with the dotnet cli but without any IDE. Like persn said, you'd be able to use pretty much any ide you want (you can program in notepad if that's what you want) with that. That's pretty much the equivalent for unity. Other flavors would be as IDE add-ins, and I'm planning to target Visual Studio and MonoDevelop (hopefully all flavors will share as much code as possible between them), though that's probably not going to happen for the first version (version 0.1 coming sometimes this decade to your home).
What you're saying here is basically what I planned for the first release.

However, for people who don't have a particular favorite IDE they want to work with I think that having everything built in the same product provides for a better seamless experience (especially if you're working from a single monitor- I wrote some unity games and switching between the applications on my laptop was super annoying). The fact that unity and a lot of other engines aren't doing something like this is indeed alarming and a cause of concern regarding how maintainable it is. I still want to try and see for myself if I can make this work, and then evaluate maintainability concerns.

Quote from: eri0o on Fri 12/01/2018 00:16:55
Also think about a package manager (you can use one that already exists) to share scripts.
I'm using standard c#, so nuget or paket should both work fine.

Quote from: Monsieur OUXX
I'm asking again : what's wrong with SharpDevelop?
Seriously? I've answered this (twice). Any reason for ignoring what I wrote there?

morganw

Quote from: Monsieur OUXX on Fri 12/01/2018 08:07:44
I'm asking again : what's wrong with SharpDevelop?
Quote from: The SharpDevelop website
Supported operating systems: Windows Vista and later

Plus it looks like there are issues going past C# 5.
http://community.sharpdevelop.net/forums/t/22341.aspx
I wanted to use it at work to avoid Visual Studio licensing, but existing code was already using features of C# 6.

Monsieur OUXX

Quote
Quote from: Monsieur OUXX
I'm asking again : what's wrong with SharpDevelop?
Seriously? I've answered this (twice). Any reason for ignoring what I wrote there?

I've missed it (twice). Now I see it.

@eri0o : it wasn't clear to me that you were just mentionning Unity for its features, not as a candidate for AGS 5 underlying tech. When I started this "comparison of engines" thread I should have been more specific : comparison of strengths and flaws of technologies that might become the underlying tech for AGS 5.

I know that Crimson Wizard is interested in a top-down approach (features first) -- aparently, so do you. I started this thread with a bottom-up approach on mind (tech first). Let's meet halfway.
 

Clarvalon

Quote from: tzachs on Thu 11/01/2018 18:10:03
I personally prefer VS Code to MonoDevelop, but VS Code looks to be much harder to do in practice.

As a quick proof of concept I hooked up VS Code (running in 'Zen Mode' to hide some of the UI elements) to the main panel and was able to debug my C# game solution directly within my editor.



I can absolutely see the appeal of this approach, preventing the need to switch between applications (in my case, XAGE Editor and Visual Studio) as well as reducing the initial download size.  However it's only really useful if:


  • VS Code can be customised and bundled without limit.  EDIT:  Looks like it's MIT license if you build it yourself.
  • It's possible to better hide the VS Code UI (i.e. suppress shortcuts) so it feels like one application rather than two glued together.
  • Some of the VS Code limitations can be worked around - for instance, it doesn't seem to be performing incremental builds for some reason, so it's a bit slower than Visual Studio to start the debugger.

A better, but far more complex approach, would be to rip out the code editor and debugger and integrate it properly.  Sounds like a lot of work though.
XAGE - Cross-Platform Adventure Game Engine (alpha)

tzachs

Oooh, very interesting! I haven't considered hosting VS Code inside my own editor (I thought of doing the opposite), but that might be a viable alternative as well.

Monsieur OUXX

The more "external" code/tools/graphical elements you can embed in the game, the more development tools you can have for making games -- things you potentially wouldn't have thought about (graphic programming, dialogs editor, script debugger, etc.). This sounds perfect.
 

ChamberOfFear

Quote from: Clarvalon on Mon 15/01/2018 20:28:50
It's possible to better hide the VS Code UI (i.e. suppress shortcuts) so it feels like one application rather than two glued together

Yeah, it's possible. We don't even have to modify any source code as far as I can tell, just provide our own keybindings.json to suppress conflicts.

Clarvalon

Had another quick play with this - confirmed it's possible to override and suppress key bindings as stated, and I've been able to get it to maximize and resize nicely within the parent panel.  A dozen or so user/workspace settings can simplify the UI to a point where it all feels pretty coherent.  It's not perfect though - the main remaining issues for me are:

  • I'll need a way of capturing certain keypresses from the code.exe process and handling them within the parent editor program.  For example, F5 in VS Code will launch the build task to recompile the code, when in reality we'd actually want F5 from within the Editor to make sure the assets are all up to date first (spritesheets built et al).
  • Edit & Continue is not yet supported in the VS Code C# Plugin.  This is unfortunate as being able to make runtime changes, as with Visual Studio, is a big productivity gain.
  • It is currently only really suitable for the desktop platform - Xamarin & UWP are not supported so you'll need to use Visual Studio anyway for those.  So it may be simpler just to stick with the existing paradigm rather than forcing the user to learn two.
I'm going to stick with Visual Studio for the time being and take a look at VS Code again once it matures further.  It's been a fun experiment at least, but I can't afford the feature creep right now :)
XAGE - Cross-Platform Adventure Game Engine (alpha)

Monsieur OUXX

Leadership decision to take :

AGS 5 based on this? Last call?
 


Monsieur OUXX

Quote from: ChamberOfFear on Sat 20/01/2018 18:11:58
You mean AGS 4?

I support it.
I said AGS 5 to avoid creating confusion with the "AGS 4" cleanup branch, but it doesn't really matter.
 

morganw

I think from all the engines in the table, MonoAGS is the only one which could function as a direct replacement (without re-scoping the whole project).

Monsieur OUXX


Keep them coming guys. Now is the time to take a strong decision, after the initial shock.

My own vote, on a par contributing to BladeCoder OR MonoAGS. There's a billion reasons why they're equally good from my perspective. In a nutshell: I think BladeCoder is better, but handling the Java bits (packaged distribution of the JDK) make it a pain in the neck, PLUS it doesn't have a strong impulse in the AGS community, unlike MonoAGS which is carried by tzachs and others.



   
       
   
       
   
       
   
       

Name
       

Vote
       

Reason
       

ChamberOfFear
       

MonoAGS
       

-
       

morgangw
       

MonoAGS
       

"the only one which could function as a direct replacement (without re-scoping the whole project)."
       

Monsieur OUXX
       

MonoAGS or BladeCoder (on a par)
       

I think BladeCoder is better, but handling the Java bits (packaged distribution of the JDK) make it a pain in the neck. MonoAGS has a strong impulse in the AGS community.
       
 

tzachs

Quote from: Monsieur OUXX on Mon 08/01/2018 21:57:21
- replication of known AGS functions (character.Say, etc.) -- to which extent?

I created a "cheat sheet" which compares AGS functions to MonoAGS functions: https://tzachshabtay.github.io/MonoAGS/articles/ags-cheat-sheet.html

The "cheat sheet" has 2 sections, the first compares AGS script to c#, and the second section compares the APIs (functions and properties).

I plan on maintaining this document as we add more missing APIs (or change existing APIs to make them friendlier).
Any feedback (like missing functions that you think are important to add) will be appreciated.

Crimson Wizard

#71
I am not sure what this voting meant for... after all contribution is a voluntary action.

Looking at the "voting" chart Monsieur OUXX has posted, frankly neither reasons mentioned are clear enough to me.

I don't know if I can or should vote, barely being acquianted with any of the mentioned alternative engines.

Quote from: morganw on Wed 24/01/2018 20:30:46
I think from all the engines in the table, MonoAGS is the only one which could function as a direct replacement (without re-scoping the whole project).
TBH I think it is XAGE that rather looks like a direct replacement, even though it is not in the table.
What I mean is that scripting API stays almost the same, from the looks of it. MonoAGS, on other hand is pretty different both in terms of scripting API and optimal coding approach.


Anyway, I am currently doing experiment by porting my recent racing AGS game into MonoAGS. I specifically chose a game that does not have any adventure elements as a first step. After that I plan to try making a simple adventure game for a test.
Then I will be able to give more actual user feedback (as opposed to theoretical thoughts from programmer's perspective).

Clarvalon

Quote from: tzachs on Tue 06/02/2018 14:42:05
I created a "cheat sheet" which compares AGS functions to MonoAGS functions: https://tzachshabtay.github.io/MonoAGS/articles/ags-cheat-sheet.html

This is good.  I need to do something similar and annotate my documentation which is mostly automatically generated.

One thing worth mentioning is that AGS structs support inheritance whereas C# structs do not, so classes may be a better fit if you're looking to perform automatic code conversions (although then you have to worry about things like instantiation).

A main pain point for me is AGS's somewhat lax approach to typing compared to C#'s strictness.  Things like allowing return values from functions despite not having a defined return type, and using integers to drive if statements. 

Quote from: Crimson Wizard on Tue 06/02/2018 15:04:23
TBH I think it is XAGE that rather looks like a direct replacement, even though it is not in the table.

I think it's excluded on the basis it is not open source, which I agree is desirable if you're already working from an open source engine.
XAGE - Cross-Platform Adventure Game Engine (alpha)

Crimson Wizard

#73
Quote from: Clarvalon on Wed 07/02/2018 08:06:36
A main pain point for me is AGS's somewhat lax approach to typing compared to C#'s strictness.  Things like allowing return values from functions despite not having a defined return type

That is probably done for backwards compatibility, AGS does not check for missing return operator either. The "function" keyword actually works as an alias to "int" in contemporary versions, because that is what it returns IIRC.

morganw

Quote from: Crimson Wizard on Tue 06/02/2018 15:04:23
What I mean is that scripting API stays almost the same, from the looks of it. MonoAGS, on other hand is pretty different both in terms of scripting API and optimal coding approach.
I'm wondering if the workflow is similar enough that, even if the scripting API is not a directly comparable, the editing tools could be shared (or just modular enough so both sets work in the same environment). The benefits would be, easier migration to MonoAGS from AGS, a newer editor for AGS in the short term, a boost for MonoAGS in the long term.

tzachs

I don't think differences in workflow is the big problem here, but rather the sheer amount of work involved to have the editor speak in an additional engine format. And also, a lot of the editor features will need to be disabled/hidden as they will not be supported by current AGS (or a lot of effort will be required to modify the engine), making me doubt how useful it would be in practice, and if the perceived benefits will be worth the effort.
That said, I will be making an effort to make the editor relatively modular (separating the editing experience from the output generators, for example), so that if somebody wants to go for it, she/he will be able to do that.

SMF spam blocked by CleanTalk