Messages

I'm not following: the concept of room item and loaded room are already split. You can get a room from the factory with zero state and add stuff later to it, and you can add stuff with or without graphics/audio loaded.
We're missing the built in loading/unloading resource strategies we mentioned before (which one of them will be "load room resources when moving to room"), but other than that, I'm not sure what's missing.

Yes, a sub-forum for MonoAGS will be useful.

Yes, that's the lifecycle of a room.

//by the way wouldn't it be more efficient to provide "game" straight away?

I wouldn't say more efficient, but more aesthetically pleasant, yes.

And then at any time later in the game, whenever something happens that might have broken a pointer to a room (like restoring a saved game) :

Right, only restoring a saved game is the only thing that can break that pointer.

You can change the title and window size after the game started (but not the virtual resolution, sorry about that): game.Settings.Title = "My title";

@tzachs, BTW, do you think it may make sense to provide a "file tree" interface to iterate asset entries, instead of call "load" for them? (Not sure if it actually always loads for real though).
In other words, instead of (or along with) IResourceLoader, have something like IResourceTree with dictionary of all assets and possibility to request their loading.

Yes, it definitely makes sense. I've added an issue for this here. We'll need to think of how the API will look and how it will be integrated with the current API, and how to integrate the "re-scan" with hot reloading.
I'll try to think about it more (and look at Monsieur OUXX's implementation) after finishing up my current work.

Ah, ok, I missed the fact that you want to load recursively.
So, if I understand correctly, you want this method: "public List<IResource> LoadResources(string folder)", to be changed to "public List<IResource> LoadResources(string folder, bool isRecursive)". Right?
Yes, I think that can be valuable.
You haven't mentioned though which member you want to see protected and how it would help you to write the recursive scanning.

I'm also not sure what you mean by "it also checks if there is an xml file in it". Is this about the filename or about verifying the contents? Do you want a boolean true/false about a folder or the list of xml files in that folder?
If it's about the filename, then you can do:

Code: csharp

var resources = loader.LoadResources(myFolder);

bool hasXml = resources.Any(r => r.ID.EndsWith(".xml"));
//or:
List<IResource> xmlResources = resources.Where(r => r.ID.EndsWith(".xml")).ToList();

And if it's about validating the contents, then you can create your validation code and filter based on that:

Code: csharp

private bool isValidXml(IResource resource)
{
   //read the stream and validate.
}

var resources = loader.LoadResources(myFolder);

bool hasXml = resources.Any(isValidXml);
//or:
List<IResource> xmlResources = resources.Where(isValidXml).ToList();

EDIT: Ah, hold on, I see you added an example, let me take a look.

Ok, I understand what you want to do now: load recursively only files matching a specific pattern.
I still don't know what member do you want to be protected to help you write that.

[Autofacs]

AGSEngine.Desktop has a reference to Autofac, while AGSEngine has Autofac as nuget dependency.

Ah, AGSEngine.Desktop was still using the old project format while AGSEngine was converted to the new format, so it's the same bug I mentioned before, I believe. I fixed it in this branch- can you try pulling from that branch and see if that solves it for you? I'll push to master once you confirm, otherwise I'll try to reproduce during the weekend when I have more time.
Btw, for posterity, this is the dotnet bug I'm referring to, which creates problems when combining old and new project formats in project references.

Because some of the projects have evolved since then and you need to add references to Autofacs and System.ValueTuple (and possibly Guilabs.Undo). These are not mentionned in the docs.

You shouldn't need to add those as references to your game project (unless you use those directly), that was a result of that bug too (I think).

The question is: Why did I have to do this in my new solution with the git submodule but not in the original checkout of MonoAGS? Because there I magically have the packages folder already and the references work.

I think the difference is that in MonoAGS, the engine projects and the demo project are configured to be compiled to the same folder. So the demo game happened to work because the engine project copied the dependency to its own folder which happened to be the demo folder too.
In your setup, however, I'm guessing both projects are configured to be compiled to different folders so it didn't work. I might change the demo quest to compile to a different folder so that I would encounter this bug sooner if it reoccurs.

I'm getting a headache trying to do extend some classes functionalities without modifying directly MonoAGS's code. The reason is that tzachs used "private" everywhere instead of "protected"! Is there a specific reason? I thought that nowadays, "protected" was more common than the very punishing "private".
Because of that, I cannot derive any class from the engine's classes. Or if I do, I have to rewrite all the helper methods exactly as they are in the parent class instead of just calling them.
PS: if you read closely all the good practices about "protected" vs "private", people say "member variables should always be private, not protected"... but then they say "it's ok if accessors are protected". So I'd say : make everything but member variables protected.

Having everything protected and not private will encourage people to extend via inheritance, which I (and many others) don't like. Inheritance should be used sparingly, I believe, as a lot of time it acts as an anti pattern. This is why MonoAGS tries to encourage composition over inheritance.
Note that in Java when no access modifier is declared the default is protected (same as what you want and I don't). The c# designers had the same opinion as me, that this is a mistake, and so in c# the default modifier is private.

That said, I'm not ruling out inheritance completely, so if you can explain which member you wanted to see as protected and why (i.e what are you trying to do exactly), we can discuss specific use-cases.

How did you create your game project?
Did you create a project with visual studio or copy the project from the demo game?
The thing is, the demo game is using an older project format which has some issue where packages from dependencies are not properly copied to your folder.
I already converted the demo game to the new format in one of the dev branches which should resolve the issue, I haven't pushed it to master yet.
So if you copied the project from the demo game, this might be the same issue. You can work around it by either converting your project to the new format, or directing the engine project to compile to the same directory as your game, or manually copy the dll to your binaries folder.
If, however, you created the project using recent visual studio, then I'm not sure what's going on, and I'll need to investigate further (so if you're ok with sending me your project I can take a look).

It's not enforced (and I don't think it can be enforced).

I would like to add, that although indeed you can create a ResourceLoader from resolver, that will be a separate new object, not the one from game.Factory.

That's not true, it will be the same object that the game factory gets, because it's registered by the engine as a single instance.

TBH I do not know at which point you need to call this command, probably before IGame is created?

If you want to override engine behavior, then yes, you need to do it before IGame is created.

Personally, I'd prefer to stay away from this Resolver stuff if possible, because it will affect everything in the engine.

Using the resolver for changing behaviors can affect things in the engine, and you need to know what you're doing.
But as for resolving things from the resolver, that wouldn't have an effect (worst case scenario is that you won't be able to resolve something because it's missing a parameter and you'll get an exception immediately).

I realize you're sticking with "Object" and "Character" from AGS, but is it too late to change that? It makes it much more annoying to discuss scripting when you have the ambiguity with the standard data types.

I like the SCUMM convention where Rooms are Scenes, Objects are Props and Characters are Actors, and would suggest that as an alternative.

It's not too late to change.
It annoys me too, but I opted for keeping familiarity to AGSers to be higher priority than ambiguity when I think that ambiguity is tolerable (i.e I don't think I actually use the dotnet object anywhere in the code, and the keyword for characters is char). But I agree that it can be confusing when discussing or reading c# general tutorials.
I'm open to change names if there's a majority agreement, although slightly concerned as I think the early adopters represent the more advanced AGSer who might cares less about familiarity than mainstream AGSers.
About the names themselves:
- Room vs Scene: I find scene to be a better name than room too, but there's also no ambiguity here, so Room doesn't actually bother me that much. I'm ok either way.
- Object vs Prop: Like CW said, I'm not sure prop covers all scenarios for object. An object in MonoAGS is something that has a transform (move, scale, rotate), an image/animation, a collider, and can be placed in a room or as a GUI. So all characters and guis are also objects. Some alternative names that come up: "Drawable", "Moveable", "Thing"?
- Character vs Actor: I have a problem with Actor because it has ambiguity with the actor model which is a model used to utilize safe concurrency, and we might choose to use it in the future. Alternative names that I can think of all suck: "Creature", "Person", "Individual"?

@Monsieur OUXX: I'm going to answer your questions to try helping you better understand the inner workings of the engine, though I agree with CW, you don't actually need that, the example he gave is what you should probably do, unless I misunderstood what you want to do.

First of all, any API that you can't find a direct reference to and want to use, you can try resolving it. So:

Code: csharp

using AutoFac;

var resourceLoader = AGSGame.Resolver.Container.Resolve<IResourceLoader>();
var device = AGSGame.Resolver.Container.Resolver<IDevice>();

Although like CW said, resource loader can be found in "game.Factory.Resources" (and device can be found in AGSGame.Device).
The resolver is how the engine gets the concrete implementations injected to it (and also how you can give it different implementations and customize almost everything imaginable), and how the factory is populated.

IResourceLoader (or is it IResourcePack ? I don't even understand) implementation : _loader.LoadResource(path)

It's resource loader. The resource loader has multiple resource packs to allow loading resources from multiple sources. Currently there's a "file system" resource pack and an "embedded resource" resource pack, but in the future we can have a "get from web" resource pack, "get from ftp" resource pack, etc.

Regarding the actual example CW gave, here's a minor improvement you can make (you might argue that it's not an improvement but at least know you have the option). You can access the game statically with "AGSGame.Game" as well.
So you can provide a default in your class and allow the user not to think about it:

Code: csharp

public class LoaderThatCreatesAGSObjectsFromXML
{
    IGameFactory _factory;
 
    public LoaderThatCreatesAGSObjectsFromXML(IGameFactory factory = null)
    {
        _factory = factory ?? AGSGame.Game.Factory;
    }

    ...

And then you can call it like CW showed, or without giving the factory: "var loader = new LoaderThatCreatesAGSObjectsFromXML();"

[About repeatedlyExecute :]

I'm very confused because none of the pages you mentionned have any links on the left, nor at the top, nor at the bottom. I only see the article. Maybe it's because they're iframes blocked by my current firewall at work (they have a very restrictive policy).

So anyways, don't spend any more time on that, it's not on you.

Hmm, just to make sure: which browser and version are you using?
Assuming you're running on chrome, if you right-click the page and click inspect, and then switch to the console tab, do you see any errors?

About repeatedlyExecute : the "warning" I was talking about is in AGSGame.cs :

Ah, that's a comment meant to explain why the engine invokes the function asynchronously (to any future engine developer or a future version of myself), it's not relevant to how a game developer would use the event.

[Question 4: what core feature does not work in MonoAGS? Does save/load work?]

Question 4: what core feature does not work in MonoAGS? Does save/load work? That's super duper important and that's the most difficult task. I would be pretty pissed off if I spent several months developing in MonoAGS only to realize that the difficulty of Save/load implementation was underestimated and the project stalled.

Save/Load game does not work now. I don't think I'm underestimating the task, as I've never given an estimation: I have no idea how long it's going to take to get it right. Same goes for having a complete editor.
Those are both very complicated things to get done right and I expect they will come through several iterations until they will perform reliably and be stable.
Note though, that the fact that built in save/load doesn't work does not mean you can't roll out your own. Depending on your game, specific save/load systems might be much easier to create than a generic works-for-everyone system: especially if you do saved checkpoints, which would be very easy (relatively) to implement.

Other core features (that I know of) from AGS which are not implemented yet: Object.Solid (characters will walk through each other), playing videos, text parser, translations, lip syncing, non 32-bit games (and color palettes).
Also you can see missing APIs in the cheat-sheet: https://tzachshabtay.github.io/MonoAGS/articles/ags-cheat-sheet.html#api-comparisons

Question 5 : is there a more natural way of implementing "RepeatedlyExecute" than the one relying on recursive call (which is targetting specifially the splash screen, that is a room with very unstable framerate)? I've seen in one of the source files that you issue a warning about Repeatedly Execute, that might cause an infinite loop of calls/dependencies if not used properly. Can you produce a simple example of : a) such infinite loop issue, b) a proper way of doing things?
The naive, dirty approach that comes to mind would be for the scripter to define an arbitrarily stack storing the order in which to call the repeatedlyExecute method of each object, just like scripts in AGS can be moved up and down and that defines the order of execution.

You can subscribe to repeatedlyExecute from the game events: "game.Events.OnRepeatedlyExecute.Subscribe(onRepeatedlyExecute);".
I don't remember any warning about an infinite loop, the docs for this event have warnings about not to do slow operations or intensive memory allocations from repeatedly execute (same warnings apply to classic AGS as well) so maybe that's what you were referring to? Those same docs also give good/bad examples for those issues: https://tzachshabtay.github.io/MonoAGS/api/AGS.API.IGameEvents.html#AGS_API_IGameEvents_OnRepeatedlyExecute

I would suggest to make the help articles (those ones : https://github.com/tzachshabtay/MonoAGS/tree/4f0189c1bebe15b4d36a0e8c34dea6c5f0120399/Docs/articles ) easier to find.
When you're here, you have no idea that they exist : https://github.com/tzachshabtay/MonoAGS/tree/4f0189c1bebe15b4d36a0e8c34dea6c5f0120399
When you're here, either : https://github.com/tzachshabtay/MonoAGS/blob/4f0189c1bebe15b4d36a0e8c34dea6c5f0120399/Docs/index.md
When you're here, you still don't know that they exist : https://tzachshabtay.github.io/MonoAGS/
And here either : https://github.com/tzachshabtay/MonoAGS/blob/4f0189c1bebe15b4d36a0e8c34dea6c5f0120399/Docs/articles/getting-started.md

I know I've stumbled upon a page where they were listed on the left, but I cannot find how to go back to that page.

So you were looking at the documents on github instead of in the documentation website. The documents in github is the source which triggers the generation of the website.
In the main readme on github you linked to there's a link to the documentation website, it's both in the top of the page and in the bottom of the page.
Here's the link again: https://tzachshabtay.github.io/MonoAGS/index.html
From the documentation website you have a link to the articles and api on the top, and the getting started link (or any article link) have the list of articles in the left.

[About onRepeatedLyExecute :]

Question 1 : If I understand the code correctly, you can have tweens that do not update automatically, but instead you let them give you a dummy function (_visitTween) when you create them, and then it's your responsibility to call that function whenever you want?

You understood correctly.

Question 2 : Is there a way to let the Tweens do their thing without having to call that function? (in a normal context where the game is not busy loading resources, like it's the case in the splash screen). I suppose yes, by calling "Run" instead of "RunWithExternalVisit".

Right again.
In case you missed it, there's a few dozens of built in tweens, and they are implemented as a one-liner using Tween.Run: https://github.com/tzachshabtay/MonoAGS/blob/master/Source/Engine/AGS.Engine/Misc/Tweening/Tweens.cs

About onRepeatedLyExecute :
I see that you actually call it yourself (insteads of letting the game engine do it automatically), by making the function call itself recursively every Task.Delay(5).
Question 3: Isn't there a risk that the recursive calls stack explodes after some time? Or am I being a dinosaur for even thinking that it's still (ever was) a thing?

You're not a dinosaur, but there's no risk (I think), because it's using async which means it's not a direct continuation of the call stack (every time the logic continues after Task.Delay it's a new stack).

You can do both, but I would recommend on adding a reference to the project. You can have MonoAGS projects as part of your solution, and then you don't need to browse to the sub folder when adding a project reference, it would appear in your list of projects.
If you add a reference to a dll however, then yes, you'll need to browse to the location of the dll file.

The advantage of adding a project reference (and having it in your solution), is that if you change the code to your version of MonoAGS and then run your project, it will automatically compile both.

Oh, I completely missed that readme. I just read the github.io documentation. Maybe you should add the info about test runner also to the "Getting Started" section there.
Anyway, tests are running now.

Maybe, the thing is though that the github.io documentation is intended for game developers and the readme is intended for MonoAGS developers. Running the tests is not something that game developers should really care about, which is why I didn't put it there.

About that git/submodule thing:
I plan to port one of my games to MonoAGS for fun. How should I handle this in Git? Create a new repository somewhere else for the game and then include it in the solution? Or should I do this submodule thing?

You can do both. I think that the main advantage of the submodule is that it allows you to more easily update to a new version (or to restore to an older version), and easier to see which version you're actually running against. The disadvantage is that it's another tool that you need to learn and occasionally shout WTF at (it is part of git, after all, being intuitive was not part of its original goal).
Note that if you do the submodule thing, it's not instead of creating a repository for your game, it's about how you link from your game repo to MonoAGS.

I've created my new local branch but I fail to publish it to the remote repo.

So it sounds like you didn't create a remote repo. You can create a a remote repo from the console by doing "git remote add" or directly from github by clicking on the branches drop-down and then click on "create new branch". However you can't do this from my repository as you don't have permissions. That's why, as CW said, you need to fork first.
Also, as you're console-phobic (like me, btw) you can do it without using the console:
1. Click the fork button on my repository to create your own repository.
2. Create a new remote branch on your repository from the branches drop-down in Github.
3. Clone that remote branch directly from Visual Studio's Team Explorer. You can also commit and push directly from visual studio, no console or third party GUI required (at least not for the basics).

Then I've added a ".Net Core library" project tot he solution.

I don't think that would work (I don't know if mono will be able to run a dot net core project). What you want is to create a DotNet Standard library -> this then works with both  mono and dotnet core.

I'm in the process of creating the feed : https://www.myget.org/feed/Packages/fakeags

I wasn't proposing that you'd create your own feed, but rather push your package(s) to the community feed I created already. Each feed can host multiple packages, so having all AGS-related packages in one feed will make it easier for people to find stuff. The editor will show packages from that community feed so that's where you'd want to push your package.

I'm reading this : https://weblogs.asp.net/bsimser/automatically-publishing-nuget-packages-from-github

What's annoying me right now is a design question : I'd like to keep my "FakeAGS" in the MonoAGS solution, to benefit from neighbour sources/autocompletion and easy testing, but if I understand correctly it has to be in an entirely different solution/repo to benefit from MyHub's auto build and push. Correct?

I think if you publish your nuspec (that's the file that's created when you build your project for nuget) then (if I understand correctly) MyGet will pick it up for your nuget so it might work.
Btw, I just tried it on MonoAGS without having a nuspec, and it seemed to create a package per project. I'll need to create a nuspec to have multiple projects in the same package.

EDIT:

I'm still hesitating because part of my work will be to extract hard-coded things from the demo game and turn them into some sort of generic library to simplify some tasks, and I feel like tzachs might want to get some of that back for MonoAGS. If it's a separate repo, it might be a pain to recover and integrate that code. Damn.

As long as your repository is public (and with a permissive license) it's not going to be a problem for me to take your code if I need it, so don't worry about it.

IGameState is a "main" holder of rooms that keeps them in memory. I am not sure for what purpose, but guess there are built-in mechanics that process that list of rooms in IGameState by default.
And "static class Rooms" is just your own custom management system, for convenience.

I am also not sure how and where, but supposedly IGameState recreates all rooms in its list when it restores save, out of data written in a save file.

Right, IGameState is the object that gets saved and loaded from the file, so basically everything that can change is part of the game's state, including the rooms. All variables that are created outside of game state (like if you simply do "int i = 5" instead of "int i = state.GlobalVariables.Ints.GetValue("MyVariable", 5)") will not be saved by default and it's your responsibility to load it after loading a game.

Crimson Wizard's explanation was spot on, note that this convenience Rooms game specific class will be automatically generated by the engine, including that boilerplate code of restoring the references after game load.

I took a somewhat deep look at the code and documentation yesterday. I have to say, I'm absolutely blown away by what you have achieved already, tzachs! It seems to be an almost feature complete new version of AGS in a clean coding style and thoroughly documented. Amazing what you have done so far all on your own.

Thanks!

What do I have to do to run the unit tests? Is there some additional stuff I need to install? I get the message "No test is available in D:\Daten\MonoAGS\MonoAGS\Source\Tests\bin\Debug\Tests.dll. Make sure that test discoverer & executors are registered and platform & framework version settings are appropriate and try again."

"To run the unit tests, please install the NUnit 2 Test Adapter (available from Visual Studio, tools menu -> Extensions and Updates... -> Online)." (from the readme)

What files do I need to deploy of a game? Everything from DemoQuest.Desktop\bin\Release except .pdb?

If you just want to deploy for Windows, then yes.
To deploy for Mac & Linux, the executable itself will not be recognized by default. So you can either add a small shell script just with "mono mygame.exe", and request for users to install mono, or create a self-contained mono application like we mentioned before. Like I said, I haven't tried it yet, but this is the link with instructions: http://www.mono-project.com/docs/tools+libraries/tools/mkbundle/
To deploy for Android, see here: https://docs.microsoft.com/en-us/xamarin/android/deploy-test/publishing/

I agree, there need to be templates instead of needing to copy stuff from the demo game.

Yes, this will be part of the editor. Copying code is just a temporary thing for now.

I fully agree. I was surprised to see that RotatingCursorScheme is part of the engine when it should actually be more a built on top thing.

It's part of the engine in the sense that's in the same dll, but it's definitely a built on top thing, it's a layer above everything else with nothing depending on it, and it will be no trouble to move it to a template project once the editor is ready.

So, it's something similar to a promise?

Yes, Task is c# equivalent of a promise, and it powers async/await in c# the same way a promise powers async/await in javascript.

Kind of, yes. As a package maintainer you can either push a package to the feed via command line (so you can integrate it automatically on every change in a CI build in your source code repo, for example) or by browsing and selecting the nuget package manually from the MyGet website. To actually create a nuget package from your library, I think it's just a checkbox somewhere in the build options of the project in visual studio ("create nuget" or something like that) which creates a nuget package every time you build.
On the client side, in visual studio, for example, you'll see there's an update to the package in the solution explorer, and then you can right click -> update. It doesn't update automatically by default, but apparently there's a way to configure it for automatic updates (never tried it myself).

[NuGet package]

Maybe a NuGet package? So that the thingy can be recompiled by the maintainer(s) and then re-imported on the fly by all the people who use it?

I created a community channel on MyGet for this (currently empty). Everybody can push nuget packages there and pointing visual studio to that channel will help you find MonoAGS specific packages. I plan to make the standalone editor pointing to it by default in its "third party modules" future window.
To point visual studio to that channel, open the Package Manager Settings and create a new package source with this url: https://www.myget.org/F/ags/api/v3/index.json
To push a package to the channel, I think you need to sign in to MyGet and go to this url and then follow instructions: https://www.myget.org/feed/Packages/ags

On a different note: code-wise, how do you plan on binding an event function (such as : button.OnMouseClick(() => { .../* DO THINGS */ } ) ) from the in-game GUI? I have no trouble believing that the AGS Editor can simply insert some function name in game.agf and simultaneously insert an empty function with the same name in a game script file. It happens while the game is not running. But with Visual Studio, while the .exe is running, will that not be a bit tricky?

Yes, it's very tricky. I had a few (maybe naive, maybe not) thoughts on how to handle it, one is compiling tiny assemblies and side-load them, the other is to use an in editor interpreter, and if all else fails, then we'll fall back to "stop the game -> unload the exe -> recompile -> reload".