Messages

I wasn't thinking of an external setup but of a separate download altogether. Each voice pack is expensive in terms of hard-disk space, so my personal preference as a game developer will be not to force it on the player who knows which language she/he wants at download time anyway. But I realize other developers might have different preferences, and it is definitely useful for text only games.

Right, sorry, I only talked about replacing the assets and forgot to talk about replacing the texts. I also like the approach of the text in the code written in the base language (I really dislike using some resource id without text so you don't know what's going on when you read the code). And I imagine having an interface in the text rendering pipeline which gets as input the base language string and returns a translated string, and the built in implementation will read the translation files and build a dictionary.
There's already an interface like this now specifically for speech that you can override and add translations in there, but nothing for HUDs yet, so I'll probably add that interface further down in the engine which will cover both scenarios (hope that makes sense). And of course there will be tooling on top, it'll combine both translations and speech into one GUI (both need to display all strings from the game) and will export translation/speech scripts etc. And to cap off the localization story there will be API to get the current language (and maybe also to set? Not sure how useful it would be to change the language at run-time) and change specific puzzles if needed based on the language (monkey wrench scenarios), and maybe also get some meta-data on the language (like is it right-to-left -> this is always a very painful thing to support in software, luckily I'm in a very good position for this).

In contrast to AGS, MonoAGS' output is .NET, right? This means, that not only developers but also players will have to have .NET installed on their PCs. Isn't this a problem? It seems that the newer Windows versions ship with .NET installed, but what about the older ones? What version would be safe for most Windows versions? I guess the engine build should target a low enough version? Any thoughts on that topic?

Yes, MonoAGS output is .Net, but players will not necessarily need to have .NET installed. MonoAGS currently compiles to dot net framework on windows and on mono for non-windows. The plan is to also add support for .Net Core, which is the new open source runtime sponsored by Microsoft. Both .Net Core and Mono can be packaged with the game so that the player will not need to download it, and there are linkers that strip out all parts of the framework that the game doesn't actually use, so the added hard-disk space should not be too big (this is in theory, we'll need to actually try it out to see that it works as intended).
As for old Windows version, the engine supports Windows 7 and above, Windows XP (and vista) are not supported. I wanted to support Windows XP but it's too hard:
1. It would mean targetting an older dot net version and losing out on a lot of features and cross-platforming capabilities (not to mention security fixes).
2. One by one all of the dot net libraries are killing support for Windows XP, so that will require using older versions or maintaining our own forks, not feasible for the long-term.
Otoh it's getting less and less used by the day (as of this day it has only 0.25% market share on steam) so hopefully it would not be too big of an issue.

When starting the game, there are two windows opened. Why is that so?

The console window can be turned off (somewhere in the project options iirc). I currently left it on for my development purposes (I noticed that on rare occasions, at least on Mac, it will show me errors that are not visible on the visual studio debug console), but I'll turn it off by default soon.

Did you plan localization for games? ITranslate seems to refer to positions, not language. Adding localization support later on could be a pain in the a..

Yes, I have plans for adding localization support (tracking issue is here if you have some specific thoughts). I have some vague ideas on how it will be implemented (basically thought of a partially cloned structure of the asset tree in a specific language folder -> if there is a matching translated asset we will take it, otherwise we'll take the base language asset).
I agree that it will be a big PITA to implement in a working system, but so is everything else really: i.e I had to make some hard decisions on which features to support initially and which to add later (I couldn't do all at once), and it doesn't matter what my choice is, the later a big feature is to add, the harder it gets do develop it.

Why do the shaders not affect the player character?

Currently you can set a shader for the entire game/screen and a shader for specific entities. If you set a shader for a specific entity it overrides the shader of the game, and the player has a specific shader (just for demo purposes). There is a plan to support multiple shaders per entity/screen which will then apply the screen shader to the player as well (this will probably be opt-out because you might WANT to override the screen shader).

Is there anything that can be actually done in the demo game?

Do you mean, puzzles? No.
You can look at the window in the left-most screen to see some viewport zooming, rotating and moving in parallel with some simple tweens.
You can click on the "?" button which opens a window to show a few of the features.
You can click alt+g to open the game view and the inspector and can play with all the different properties of the entities (there's a lot more to play there than with the properties window in AGS, so it's probably worth the time understanding them all, though note that the inspector is not completed yet so there are some available things you can do with the engine which you still can't do with the inspector).

I have an idea. Making proper and thorough documentation takes a while, but posting solutions in forum posts make things go unnoticed.

Monsieur OUXX, what about creating a google drive document, or any similar kind of page, and sharing permission with few people, tzachs + those who are interested trying MonoAGS. Then fill that documents with FAQ and first step instructions, that all contributors could ammend.

I created a FAQ wiki page with what was raised so far: https://tzachshabtay.github.io/MonoAGS/articles/faq.html
Note that if you have a Github account you can easily (I think) contribute changes: there's an "Improve this doc" button on the top right of the screen (and all on other pages in the website) which takes you to the page on github, from there it's just about clicking the edit button (behind the scenes I believe it automatically forks the project, and creates a pull request with the suggestions).

If that's not satisfactory, I'm ok with having a google doc.

I'm joining you playing MonoAGS

Great!

but I'm already stuck

Not so great..

but I don't have the dotnet command on the command line

Hmmm, that is weird. Were there any errors during the install?
I would check first if dotnet core was really installed: is there a "C:\Program Files\dotnet" library? what folders do you see in "c:\Program Files\dotnet\sdk" and "c:\Program Files\dotnet\shared\Microsoft.NETCore.App"?
If nothing is there, then it looks like it wasn't installed. I don't know if it's a problem in VS installer, but you can also install it from here: https://www.microsoft.com/net/learn/get-started/windows
If there is a dotnet core version installed, then maybe for some reason the installation failed to add it to your PATH environment variable.

Other than that, what time did you download MonoAGS? I pushed a fix to the original problem a few hours ago. If you downloaded before the fix make sure to delete the "global.json" file.

Crimson Wizard, I believe Monsieur OUXX was asking about how sprite loading works in AGS, not how it works in MonoAGS.

This is, among with lack of the Editor, IMHO the weakest part of MonoAGS right now. The problem is that it does not have any built-in resource manager yet.
You have to mostly write storing and loading (and freeing) stuff yourself.

Right, well, from my point of view the issue of having to write the loading code yourself is because there's no editor, not because there's no resource manager. The editor will generate that code for you.

As for a resource manager, the current plan is to have a resource loading strategy and resource freeing strategy which will be built on top of the current infrastructures. So for resource loading strategy you might have "load on startup", or "load when entering room (which has the specific asset)" or "load only when the asset is needed" (lazy loading), and you'll be able to code a custom resource loading strategy which does things differently. Similarly for a resource freeing strategy you might have "free after resource was not used for X amount of time" or "free when leaving room" or "always in memory" or your custom coded freeing strategy.
And you'll have the option to set a default loading/freeing strategy for the game, and override it for specific assets.

the mixed resolutions (game in low-res, font in hi-res,

You can turn off the hi-res fonts, just delete the lines: "GLText.TextResolutionFactorX = 4; GLText.TextResolutionFactorY = 4;" in Program.cs.

and I couldn't see if the cursor is aligned to the low-res grid or to the screen's resolution)

Everything is done with sub-pixel positioning so the cursor should align with the screen's resolution. If aligning the cursor the the low-res grid is important, it shouldn't be too hard to add as a feature (though if you couldn't tell the difference, who will?).

2) building the animations (views/loops). Without a GUI, it will be a real pain! For me that's a big no no.

I agree, an animation editor is a must for version 0.1.
Note though that for loading the animation loops, you can load an entire folder as a loop without having to write every single frame path (assuming the frames are alphabetically ordered).
In fact, loading idle + walking animation for the hero in the demo game is done with this single expression:

Code: csharp

IOutfit outfit = await game.Factory.Outfit.LoadOutfitFromFoldersAsync(_baseFolder, walkLeftFolder: "Walk/left",
	walkDownFolder: "Walk/front", idleLeftFolder: "Idle/left", idleDownFolder: "Idle/front", 
	speakLeftFolder: "Talk", loadConfig: loadConfig);

I should let you know that I downloaded Godot alongside MonoAGS, though <-- that's to maintain pressure and suspense

haha, game on!
Are you using Escoria? https://github.com/godotengine/escoria
Because that would make things even more interesting.

Great! Thanks for verifying.

The console output looks like this when I run without the correct version installed

Yeah, that's what it should do, it makes sense, I was surprised that it didn't give me this error on the linux machine. But I think that was because it's not about which dotnet version is the active one, but whether it's installed on the machine at all, and I guess it is installed on my machine so it didn't yell at me even though I installed a newer version, it simply ignored it and used the older one.

That's very weird, it doesn't reproduce on my linux machine (using version 2.1.104).
Can you try deleting the global.json file and try again?
If it doesn't work, then you can either download that specific version from the link ChamberOfFear posted (and 'un-delete' global.json), or wait for me to get to a windows machine (tonight) and I'll try to reproduce it from there.

It's good to know that I don't need Xamarin for the Android project. (maybe adding a little note on that topic in the Wiki would be a good idea?)

You do need Xamarin for the Android project, you don't need the android project for running on desktop. Yes, I'll add that to the docs too, good idea.

I cannot build AGS.Editor either, it sais "The current .NET SDK does not support targeting .NET Standard 2.0.  Either target .NET Standard 1.6 or lower, or use a version of the .NET SDK that supports .NET Standard 2.0."
Probably it requires installing very particular SDK?

It requires the .net core 2.0 sdk. It should be installed automatically with the latest VS2017 update. If it didn't install for some reason, you can get it from here: https://www.microsoft.com/net/download/windows/build
You can verify which version you have installed by running from console: `dotnet --info`.

The only other project that requires Editor.dll is DemoGame (it did not before iirc).

Yes, that's a temporary thing, in the current version I'm working on I removed that dependency.

Hi! And.. Cool!

A few notes so far:

Editor:

There is no editor to speak of yet. This is what I am currently working on.
Currently the only "editing" component that exists is the inspector, which is currently opened from the game itself.
From the demo game you can click alt+g to open the game view, then select one of the room objects, and edit the properties of that selected object -> only it's not actually changing any code currently, it just changes it for the current game.
Rough timeline:
In my next big code push (coming hopefully in the next week or two), I'm removing the alt+g to open the game view from the game and moving it to the editor, along with a play/pause button and the ability to select/drag/scale/rotate objects directly in the scene when paused -> though still only in the current running game.
After that the next item for the editor will be to generate the needed code for actually modifying the game code.
And then, I'll add a "create new game" button (currently there's only "load game") with one default template (for now) for generating the startup code.
Following that, working on completing up the initial version of the editor and rewriting the save/load game system before releasing an official 0.1 version: a not comprehensive list of issues for that release can be viewed here: https://github.com/tzachshabtay/MonoAGS/milestone/1

Android & IOS:

Like ChamberOfFear said, you'll need Xamarin installed and the android/ios SDKs.
I've posted links with instructions in the main readme in the repo: https://github.com/tzachshabtay/MonoAGS/blob/master/README.md
I haven't written it down in the docs website, though, I'll add it there soon.
If you currently are just developing for desktop, you can indeed ignore those errors.
Also note that IOS is not currently officially supported, it was only partially working the last time I tested it (no sound and incredibly slow on an ipad2, I haven't tested it on a newer device yet, and the editor takes priority so I'm probably not going to add ios support for a while).

General early adopter warnings:

Problems you'll probably encounter:
- Missing features: Save/load is the most striking gaping hole in the engine now. Other than that I think that most of the widely used AGS features are there in one form or another -> let me know otherwise if you're in need of something specific.
- Usability: Well, obviously, as there's no editor, you'll need to write code for everything, including object creation which might not be the most friendly experience around (check out the demo game, or Crimson Wizard's games for examples on how it's done). Also, the API might be different at times than AGS, use the AGS cheatsheet if you can't find something and let me know of any problem that arises.
- Bugs: Might go without saying, but you will encounter bugs -> open issues on github or write to me/here if you prefer, I'll try to assist in any way I can. Note that you can also open an issue on github just to ask a question or start a discussion.
- Changes: The codebase is still getting A LOT of breaking changes, so it's going to be difficult to keep pace with engine updates (Crimson Wizard's games, for example, will not compile with the newest engine version, as there were breaking changes in the last month -> I'll submit a pull request to fix this when I finish with the current editor work I'm doing).
This is optional, but if you want, you can put your code on github or some other source control provider if you prefer, and I'll try to help and submit pull requests when I have a new engine version to make sure your game still compiles and runs as expected. Creating a public repo also has the benefit of allowing me to easily debug issues that you'll report, and it will help future potential users as another sample.

Other than that, I really really appreciate you taking the effort of trying it out, I hope you'll like it, and don't be afraid to ask the silliest questions you can think of and request the tiniest or most epic features imaginable.

I also think that any public domain asset should be allowed, though not sure how I feel about previously created assets (unless you make it public domain) -> and all assets should get the same treatment whether it's graphics, sound or code.

Now, for a little more radical idea, and I'm not even sure if I'm for it, but I thought it might be worth bringing it up for a discussion: what do people feel about allowing other game engines to participate?
It will bring more participants which equal more cool games, and might lure outsiders to join the community, and maybe try AGS one day.
On the downside, there's a sense of homey feeling here that's hard to describe, and it would be shame to see it disappear.

[Chris]

I'd also like to mention Chris, who would like to change the world. It's about making an impact, seeing how things you do in the world actually make a difference. If I steal a cake from a bakery, for example, maybe I can see the baker installing a home security system when I come back later.
A sub-set of this, is also about making choices that have consequences. Like which person do I save, as seen in "The Walking Dead" game. And I can mention The vacuum as an AGS game that did this superbly.

Spoiler

Any chance the team/tzach tries to rescript, reimagine, emulate AGS Script, so transition to monoAGS is easy?

Well, AGS script is based on c++, and c# is c++ re-imagined, so applying this full-proof logic will tell you that c# IS AGS script re-imagined.
Anyway, I'm not going to work on an AGS script emulator myself (I feel the work-to-benefit ratio is too small here), but anyone else is welcome to do it.
For ease of transitioning between the languages I wrote a document that explains the differences between the languages and the APIs: https://tzachshabtay.github.io/MonoAGS/articles/ags-cheat-sheet.html

Also, I plan to create an interaction editor that will hopefully allow you to write most of your game without having to code at all: my hope is that this will make the transitioning relatively simple.

[close]

The biggest issue I have now, even though that sounds dumb, is that I have literally no idea where to look for these jobs. Which kind of shows my disconnection from this world of game developement. I mean, ofcourse there are those well-known giant companies producing AAA games, but that sounds too much for starters.
That is why I was asking, maybe there is some kind of a place, like a internet hub, to check out for smaller groups, indie companies, etc, to begin with something?

Tigsource: https://forums.tigsource.com/index.php?board=40.0
IndieDB: http://www.indiedb.com/jobs
Gamasutra: http://jobs.gamasutra.com/

Also, silly question, but have you tried googling for "game developer jobs"? -> it gives tons of options, like this, for example: https://www.indeed.com/q-Game-Developer-jobs.html
You can also google for specific engines, like "unity3d jobs", there's a lot of jobs out there.

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.

It was more for an idea of what he is testing.

I'm only doing unit tests, I don't currently have any game-testing frameworks, though I would definitely want to have something like that eventually. What I would like to have in my fantasy game testing framework:
- Very stupid bot: it would randomly left/right click in various locations in the screen, trying to make weird things happen.
- Stupid bot: it would randomly trigger interactions with objects in the screen, trying to make weird things happen.
- Scripted tests: either by triggering interactions directly or using programmatic mouse clicks, and assertions will be made against pre-made screenshots (no clue on how to test audio).
- Benchmark tests: will make sure there are no performance regressions.
- Tests should be able to run in a docker container in some kind of headless OpenGL window, so it can run from the build server.
- Tests should record a video so we'll be able to see what went wrong.
- Dumb & Dumber bots should record all clicks and allow playback to reproduce errors (which can't be perfect because of timing, but might be useful on occasions)
- Dumb & Dumber bots should be generic and configurable so that they could be used by game developers to test their game.
- If we have the money, then we'd like to run the tests on xamarin test cloud which runs the tests on a lot of different real mobile devices, which will help us find issues with specific devices.

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

Could this editor change by Tzach be made currently? Like, by you? Like, for money?.... :3

I could try, lol, but I will have to give most money to tzachs, because it's his code.

Works for me

Seriously, though, I remember it had a lot of rough edges and I had concerns about usability (and like you said, it was mostly untested), so if you really want to take a go at it you'll probably need to invest a fair amount of time (so you should probably keep most of the money ).