Messages

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.

[@tzachs :]

@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

Btw, it's uncanny how spot-on Snarky's predictions from 14 months ago are.

Hope that was tongue-in-cheek, Khris

the funny part is that Trump is already the  "short-on-expertise extremist/sycophant/charlatan" about whom Snarky is talking, if you compare him to literally any US politician before the 90's, even the ones from his own political family.

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?

Left aside all the sexist innuendos : very good pixel art, executed with a lot of taste. Very good colors.

[absolute core point n' click engine]

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

Component-based

Yes, that's very good.

I don't think that knee bending works, I get tired just by looking at him standing like that.

It's not because of the bendig itself, but because his body balance is too far to the back. His center of mass (his hips) should be slightly more to the front.

[@tzachs :]

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

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.

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!

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?

[@tzachs :]

@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

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

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.

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.

[MONOAGS AUDIT REQUIRED]

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

[AGS almost entirely does it already.]

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.

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

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.

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.

[Bladecoder]

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.

Like you and Scotch, I prefer a Javascript game engine.

I would immediately leave AGS if it switched to a weakly-typed language. Thse are awful and cause a billion of human mistakes. Best evidence from the main actors themselves : http://www.adventuregamestudio.co.uk/forums/index.php?topic=55283.msg636571805#msg636571805