Messages

Coincidentally, I started giving out alpha keys in the AGS discord yesterday evening.  Take a look at the following and if you're still interested let me know and I'll send you a key:  https://clarvalon.com/documentation/gettingstarted

Same goes for anyone else who may be interested - I'm ideally looking for AGS users who are comfortable using Visual Studio.  It would be good to start getting the tools into other people's hands and start canvassing feedback etc.  I will use this to help prioritise bugfixes, enhancements, documentation etc.  Thanks!

Progress has been slow since the turn of the year, but I've finally addressed a thorny issue that has been a problem for a long time.

The previous serialization library, protobuf-net, had no officially supported solution for pre-generating the serialization routines, required for platforms that only allow for AOT (ahead of time) compiled programs instead of JIT (just in time) like iOS and UWP.

The MessagePack format has been around for a long time, but the MessagePack for C# library has recently come on leaps and bounds after being adopted by a Microsoft employee for use within Visual Studio itself.  Among it's features are the ability to pre-generate serialization code as an MSBuild task, essentially making the process invisible.  This is especially important as ideally users shouldn't have to care about the mechanics of how their game loads and saves.

Initial benchmarks looked good, and tests on real world examples even better.  I've now incorporated MessagePack into the XAGE pipeline and while there is more testing to do, it's looking like I'll be pulling protobuf out entirely. 

Combined with CoreRT, the startup times are so much better, and general performance and memory usage is also good.

Earlier versions of XAGE were built upon Monogame which supported Android (see Awakener).  However I've since switched to FNA, which does not yet officially support Android.  iOS should be fine and Mac should also be supported long term now FNA (as of yesterday) can use a Metal backend renderer.  Hoping to get my hands on some apple hardware in the new year to test it all out.

I've summarised current XAGE platform support here: https://clarvalon.com/documentation/supportedplatforms

Getting started with XAGE in two minutes ... ish:

Not yet - I had initially planned to have three demo games available on github but I may rethink this to get something out sooner.  I'll update this thread when it's available.

A few evenings ago I spent an hour making a basic game from scratch for my kids.  I don't do these dogfooding exercises often enough as generally I'm focused on ports.  It exposed a few bugs and gaps that I need to address (e.g. creating default cursors, ensuring at least one room exists etc).  The editor UI gets the least amount of love so it needs a few rounds of polishing before I'd inflict it on anyone else 

Development continues apace in all areas, with particular focus on improving the developer experience by tightening the change & test loop.  I detailed some of the more recent engine optimisations here:  http://clarvalon.blogspot.com/2019/11/putting-lipstick-on-sisyphus.html

Packaging games as single executable files is a nice novelty.

v0.7 has been released on github:

• Audio - Supports both old (Music/Sound) and new (AudioClips).
• Audio - Optionally uses ffmpeg to convert all AGS audio to .ogg.
• WalkableAreas - Optionally uses potrace to vectorise.

Bitbucket dropping mercurial support gave me the nudge I needed to move all my code repositories over to GitHub and, more importantly, presented an opportunity to rethink how everything was structured.  As part of this process I've been considering how best to package up the Editor in such a way that it's both easy to distribute and update.

The final release candidate for .NET Core 3 - the underlying tech which XAGE is built upon - is expected to go live tomorrow.  While there are still some issues around the new publish options I've had some success with trimming the DLLs to reduce the size, and creating a self-contained single executable:



Having uploaded a handful of prototype/showcase games there already, itch.io seemed the logical choice to host XAGE Editor itself.  The tools are great but the biggest selling point is the itch.io client's auto-update mechanism.  Users who prefer to update manually will also be able to do so.



Once things are a bit more stable I'll share a few pre-release keys with anyone interested in trying it out, before making it publicly available.  The plan is to have a handful of small sample games on GitHub that XAGE Editor will be able to download or clone, to make it easier for new users to jump right in and get a feel for the workflow.

Yep - I plan out putting together some documentation & tutorials when the tools are released.  There's some stuff on youtube already but it's pretty out of date.

Edit:  Just saw your edit   I'm in the middle of a commercial port at the moment (L&F was a palette cleanser) but the plan is to put the tools out once there's a commercial game in the wild, to prove the viability of the engine.  Hopefully by then all licensing will have been figured out.

RE: Website - thanks.  The search functionality isn't quite 100% yet as I built it myself (the site itself is hosted on bitbucket so is entirely static).  I should probably get a proper domain at some point.  I just really like being able to update it using standard version control software.

Figured it was about time I started a thread about the general state and progress of my engine, XAGE.  It's been quietly in development for a long time now - much too long really - though a lot of ground has been covered in the last 18 months inparticular.  It's approaching a point where it may actually stop being vapourware and become a thing people can get their hands on.

Established general-purpose engines like Unity have proven C#'s suitability for certain types of games, and as a language it shares much in common already with AGS Script.  The aim of XAGE is to find a niche somewhere inbetween, using a lot of similar paradigms AGS does for creating adventure games (including the same script API), whilst also allowing developers to script and test and profile their game using the latest version of the cross-platform .NET Core framework within Visual Studio.  Somewhere there's a venn diagram of people with those two interests and hopefully the intersection isn't a picture with just my face on it.

As a recent test case, I ported AGS game Last & Furious over to XAGE.  This was a reasonably challenging port, with 21 modules of varying degrees of complexity, but this could be converted mostly automatically once I'd implemented all the necessary missing engine functionality.  I wrote a little about it here:  http://clarvalon.blogspot.com/2019/08/last-furious.html - hopefully this showcases the current state of the engine.

While it's nice to be involved in the conversation, I don't think a subforum for XAGE can be justified at the moment.  Maybe when it is publicly available and if there is sufficient interest.  I can see a case being made for MonoAGS however.

XAGE has been in development for an embarrassingly long time.  There are two main reasons it hasn't been public for most of this duration:

1)  Several major refactoring efforts have finally coaxed the engine and tooling towards a place I'm happy with.  This would have been a nightmare for anyone actually using it however, as their game project would periodically been affected by many breaking changes.  It's an unreasonable burden to place on a developer who just wants to focus on their game.

2)  My current workload is such that I just don't have the time to manage a support queue.  The work as part of the above have made it easier to introduce change however, so once we reach a certain level of maturity then I'll be comfortable with a public release.  Still aiming for this calendar year.

I don't want to mislead on engine maturity however - most recent ports I've attempted have gotten the games playable but still quite broken.  They have improved over time as I've implemented more and more missing engine functionality, but there's still a lot of work to do.  I am hoping to shortly start work on porting a commercial game, which will help give everything a proper workout and layer of polish ahead of release.

The momentum around MonoAGS is interesting to see, and it's clear a lot of effort has gone into it.  I wish the project well!  One main area we differ is that XAGE aims to more closely mirror the AGS scripting API, so that it should be reasonably painless for existing AGS developers to make the switch.  We'll see how well that pans out in reality.

At work currently so haven't checked it, but try this - Link.

I've added links to some older versions of the plugin on the other thread.  Hopefully you can get some use out of it.

Not sure of the specific version but here's one I found on my dropbox dated 2013 - Link.

I've also compiled it from source, the very last version before the output format was changed to .apha (pre github repo) - Link.

If the output from either isn't suitable then next step would be to fork the repo on github and change to whatever format you need.  This is an AGS Editor plugin so uses C#.

Earlier versions of the AGSExportPlugin would dump all hotspots, regions, walkable areas et al out to individual PNG files.  It now uses a different format but this could be forked to output to whatever format was needed.

This would be incredibly useful for XAGE, a test AGS game that used all existing engine functionality.  It wouldn't necessarily need to be split into individual tests and assertions, it could instead be long cutscenes that performs various actions and then outputs the results to file.  This could then be compared side-by-side with the equivalent XAGE port output to more easily identify missing (or broken) scripting functionality.

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. 

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.

This plugin has now been open sourced - see edit to original post.

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