The Editor is not part of the initial vision. It's envisionned as some sort of tool "external" to the engine, that can come after. It means there's no vision on assets management and game-creation pipeline.
The editor is a critical part of why I started my project in the first place, it's definitely part of the initial vision. My AGS development background is exclusively the editor, and I had a much clearer idea on what I wanted to do with the editor than the engine when I started.
The engine comes first because it's the core, and because I wanted it to be independent from the editor in the sense that at any time during the development you can ignore the editor completely and just stick with the engine.
Like Crimson Wizard said, I currently work on the editor as an overlay in the engine, as I want you to be able to edit rooms as you play them (i.e to remove the “edit room -> debug -> edit room -> debug” annoying loop). I don't want to talk too much about the editor currently -> I can probably go on and on about features I plan for the editor if you'll push me, but because it's very early stages and things will change greatly, I don't want to over-promise. Anyway, if you have ideas for stuff you want to see in the editor, now is a very good time, so let me know.
Regarding assets management -> That's kind of vague and can be interpreted in many different ways:
In the context of the editor the idea is to have an “explorer” view with the assets folder which will bind to the assets in the actual folders, so just by copying to the folder on your computer should automatically update the assets (though of course it will also have dedicated context menu and drag&drop support). It should also support hot-reloading the assets during the game (when debugging).
In the context of asset bundles, packing textures, compressions, etc, that's all stuff I want to add in the future, though it's true I don't have a clear vision for this, I don't have the experience, but I definitely want to tackle that. Crimson Wizard gave me a detailed proposal that I'm going to implement in terms of making the engine easily extensible for loading different bundles from different locations. Any other feedback on this (or anything else) is welcome.
I might have completely missed your point here, because, as I said, it's vague, so let me know if you meant something else.
Regarding game-creation pipeline -> This is even more vague than assets management, so it would help if you expand on that.
It's focusing a lot on basic graphics rendering (SDL), with no vision regarding the other components, such as sound engine, controllers input, GUI, timing, etc. That's my biggest concern with many wannabe game engines: they lose steam after they manage to render the graphics of the game, but that's only 25% of the whole picture.
So first to clear the confusion a little bit, I'm currently not using SDL, but OpenTK. OpenTK has the option of taking SDL as a backend to override OpenTK's own native handling of windows, input and graphics. In theory this should give better stability and better controllers handling- so far I didn't add controller support and didn't see any stability issues related to OpenTK so I'm not using SDL, but I have the option to if the need arises.
Regarding sound engine, here's what I currently have:
- The ability to play/loop/stop/pause/resume/rewind (or seek to a specific position) sounds.
- The ability to change a sound's volume/pitch/panning (you can set it for the audio clip itself or for individual sounds played by the audio clip), including tweening.
- The ability to query a sound's state and to get all currently playing sounds for an audio clip
- The ability to asynchronously wait for a sound to finish playing
- Automatic cross-fading for music clips when switching rooms with the ability to configure fade-in/fade-out time and tween.
- A sound emitter which can be attached to a moving entity and automatically adjust the panning based on its position in the scene (i.e positional sound), and also volume changing areas, that changes the volume automatically when the emitter moves across the areas (lower volume for far away entities, etc). The sound emitter can also be configured to easily play sounds on specific animation frames (useful for footsteps).
Here's what I don't currently have but want to add (and I have a tracking issue on Github for each one of those):
- Automatically reduce volume for playing sounds when speech is playing (but allow overriding it per sound)
- Allow adding effects to sounds (like reverb) at runtime
- Support envelopes
- Support for Opus format (and other audio formats)
- Support runtime synth of sounds (midi)
- Support audio streaming
If there's more stuff you think a sound engine needs which I am not aware of please let me know.
Regarding GUIs, here's what I currently have:
- Various controls: labels, buttons, checkboxes, comboboxes (drop-downs), inventory windows, listboxes, scrolling panels, sliders, textboxes
- Layouts: stack layout and tree-view layout.
- All GUIs are basically extensions of existing entities, meaning that they can be treated just like all other entities, so you can have GUIs as part of your world, they don't have to be on top. They can also be parents of non-GUI entities and vice versa (so you can, for example, have a character walking inside a scrolling panel if you want) and you can also tween GUIs and change their position, scale, rotation and pivot points.
- Dialogs like yes/no, with the concept of focus so that dialogs can take input focus from the game.
- A proof-of-concept skinning (theming) engine for GUIs.
As to what I don't currently have, there's a ton of stuff missing, from various controls (tabs and menus come to mind immediately), responsive grid layouts, pretty built-in skins, and the existing controls themselves also might miss functionality. This is all very much in progress. The kicker here is that as I'm building the editor based on this GUI framework, assuming I'm successful you can expect that eventually I'll have a very complete GUI framework that can be easily integrated into the game world (not a lot of engines can claim that, I believe).
Again, let me know if there's more stuff you think it's missing.
Regarding timing, I'm not sure what you mean by that, please expand if you can.
Regarding controllers, yes, I currently don't support those, but plan to add eventually (though it's not a top priority currently as people can use libraries to work-around that).
It doesn't do vectors, even only just by wrapping some basic directX primitives/data structures. There are many vectors usages that you might not think about until they're missing and it's too late (graphics scaling, walkable areas, perspective, camera control, tweens, parallax, etc.).
Like Crimson Wizard, I was also confused. I originally thought you meant vector art (svg), which is currently indeed not supported (but it's actually a high priority for me). Vector areas is another thing completely which is also currently not supported (but planned). Lastly, based on the gamasutra article you linked to, I think the only thing missing to do something like that is perspective camera support, as everything automatically uses ortho cameras currently (MonoAGS already support parallax layers, btw). This is something I can probably add.
Is the build automated? Like, do you maintain a solution made with something such as cmake to generate the .sln file and all? That's one of the weaknesses that CW pointed out in AGS. Those tools are real magic to generate soluions for any IDE/compiler/Visual Studio version in one click
The build is automated (and there are automated tests as well- though the tests are not as comprehensive as I would like them to be). Also, a big fantasy for me would be to have UI tests (i.e use docker to open up an OpenGL context, and automatically run the demo game or some other test game with video recording if something goes wrong).
I don't use cmake nor do I understand what you mean by "generate the .sln file and all”. I'm not familiar with any c# project that uses cmake? I don't have any experience with c++, but in c# you almost never update the sln file manually, the IDE handles it for you, and the IDE itself rarely touches it as well (just when adding/removing projects).
Apart from that,I have no opinion on the switch from Mono to .net Core.
.net core should be faster and more stable than mono, but the really big appeal is that it can be self-contained, meaning you can bundle the runtime with the game so it's not needed for the user to have the runtime installed on her/his machine.
Good manual + community + tutorials: yes
I would not say that's true: I consider the current documentation to be miles off from where I want to be: I have reference API docs and some explanation articles but zero tutorials, samples and recipes.
Subpixel management / maths / vectors: to be binded
I don't understand the category and the “to be binded”. MonoAGS supports subpixel positioning. Not sure what you mean by “maths”, but c# has built in math in the standard library, and already mentioned my misunderstanding of what you mean by vectors.
Multithreading inside the game:
to be implemented by the game designer
MonoAGS currently uses 2 threads, one for the render loop and one for the update loop. And other than that, yes, developer can create threads if she/he wants. I talk more about the threading model
here.
Data structures / serialization / database-like processing
c# (the standard library and existing libraries) probably has everything you want and more.
1) relying on a cross-platform tech? If yes which one?
2) which is the licensing Of that underlying tech ?
3) Is that underlying tech only a graphics renderer or a full multimedia engine? In other words: does the graphics rendering come bundle with the audio and potentially 3D or GUI rendering, or are these separate libraries?
4) Is that underlying tech only a game engine or an Editor too?
5) How old is each of the few central underlying tech or lib (name them) and the main project itself ?
6) What third-party libraries is it using (full list)? How old/robust/well maintained/too restrictive are they?
@tzachs not accurate enough! could you please have a look at the bits I added in italics in the quote above?
Ok, expanding on the “italics” parts:
1. All the techs I list
here are cross-platform (and by cross-platform, I mean, at the very minimum: Windows 7 and above, Mac, Linux, Android, IOS.
2.
Dotnet framework,
OpenTK,
SDL,
OpenAL Soft,
Protobuf.net,
NVorbis,
FFmpeg, everything else is MIT.
3. The underlying tech is low-level multimedia bindings (you see it as useless, I thought the opposite: I didn't want to get the burden of an existing complete engine, as it gives more freedom).
4. …
5. Very hard to answer about the underlying tech age, it's not something usually published on the front page: dotnet core is probably the youngest one (2 years?). I originally started working on MonoAGS on Aug 7, 2015 (on the flight to Mittens New-Orleans). Everything else has been around longer than that.
@tzachs, could you clarify the points below:
Ok, you added this as I was typing, so parts I haven't touched on yet:
- implementation of usual point n click entities yes/no (rooms, characters, inventories, objects…)
yes to all (I think).
- replication of known AGS functions (character.Say, etc.) -- to which extent?
So I went over the API back in the day, and I think I have most of it in some form or other. I probably missed a bunch of stuff though.
Things that I know I don't currently have are: Object.Solid, tint areas, text parser and drawing surface. I'll go over it soon and make a more exhaustive list.
- editor (explain your plan)
Ok, so you are pushing me
. It will be a long post on its own, and will take me some time to write, so I'll get back to you on that.
- you're really not using any game-oriented middleware for assets loading, sound management (apart from basic OpenAL), controllers input, animation, camera control, etc.?
Not that I know of.
