Messages

I personally prefer VS Code to MonoDevelop, but VS Code looks to be much harder to do in practice.

As a quick proof of concept I hooked up VS Code (running in 'Zen Mode' to hide some of the UI elements) to the main panel and was able to debug my C# game solution directly within my editor.



I can absolutely see the appeal of this approach, preventing the need to switch between applications (in my case, XAGE Editor and Visual Studio) as well as reducing the initial download size.  However it's only really useful if:

• VS Code can be customised and bundled without limit.  EDIT:  Looks like it's MIT license if you build it yourself.
• It's possible to better hide the VS Code UI (i.e. suppress shortcuts) so it feels like one application rather than two glued together.
• Some of the VS Code limitations can be worked around - for instance, it doesn't seem to be performing incremental builds for some reason, so it's a bit slower than Visual Studio to start the debugger.

A better, but far more complex approach, would be to rip out the code editor and debugger and integrate it properly.  Sounds like a lot of work though.

[OpenTK:]

Bit late to this thread but there's a frightening amount in it that's directly related to what I've been working on, especially in the last six months.  It seems like there's a lot of common ground between MonoAGS and XAGE, so thought I'd chip in.  I tend to neglect my development blog, so apologies for linking to so many individual tweets:

OpenTK:  Not sure I'd recommend this as the back end.  MonoGame previously used it but instead switched to SDL2, at least for the desktop platforms (following in FNA's footsteps) as it is better supported and more actively developed.  That's my layman understanding anyway.

ProtoBuild:  I stopped using this due to lack of .NET core support.  It's planned but I didn't want to wait.  Besides, the new .csproj options, where items are included by default, somewhat negates the need for protobuild as it's fairly trivial to automatically create the .sln and .csproj files you need.

C#:  XAGE automatically creates and updates a bunch of back end base classes - some are static wrappers to the engine via an interface and the rest are dynamically created based on the game project.  The Editor can then automatically create or jump to the C# methods that act as your game events.  I've illustrated this process via a clunky .gif here.  There are some workarounds under the hood as C# script is somewhat stricter than AGSScript, but from an end-user point of view it can feel pretty familiar to AGS depending on your engine API.

.NET Core:  The introduction of .NET Standard 2.0 massively improved the core landscape.  Ethan Lee's MonoKickstart bundler for Linux & Mac seemed to work fine, but getting mono to play nicely with mkbundle, to create standalone executables, was a nightmare.  Eliminating Mono is nice and being able to use dotnet publish seems to work pretty well.

IDEs:  Seems strange for anyone to get hung up on Visual Studio, given the Community Edition is free for small teams and hobbyists.  As per above, you can create an interface between an editor and Visual Studio without too much work.  Maybe it's because the minimum download size is large.  There are also other IDEs that are compatible with .NET Core, as mentioned, Visual Studio Code which is also cross platform.

Protobuf:  Good choice - it is very good for engine game state serialization.  Much faster than everything else I've tried.  Here's an old comparison with XML.

Dear ImGui:  Second the vote for this - it's extremely easy to use.  I recently plugged this into the debug build of XAGE.  There's a nice C# wrapper here that is MonoGame and FNA friendly.

AGS.Plugin.ExportToXAGE.dll  Recently I was kindly given the source to an AGS game that uses runtime plugins, the first time I've encountered this.  As a result, I've been making some recent changes to this editor plugin.  The code in the original thread is quite old.  I could provide a more recent version, though it's a bit messy as it uses remote links to classes in other projects.

Thanks for the feedback.  I see XAGE as complementary to AGS, rather than a direct replacement.  AGS has its own path, whether that involves ScummVM or one of the other routes that have been suggested since being open sourced.

With regards to licensing, nothing has really been decided yet, but my preference is to keep it free to use for non-commercial use.

Figuring out how to monetise the engine, if at all, hasn't been a priority - it's only as we approach release that I'm forced to put some thought into it.  I realise that pitching a paid product to a community who are mostly used to working with free tools was always going to be a tough sell (I'm hoping that cross-platform support, along with the familiar AGS-inspired C# API is that selling point).  The main purpose of the post was to gauge people's preferences to each of the options, whether up-front licensing, revenue share, crowdfunding etc.  I have pretty low expectations about ROI, so ultimately I want to determine what's the best way forward for any potential users and myself.

I am hesitant to charge up front as, frankly, I don't like the idea of anyone being left out of pocket.  My preference would only be to collect revenue from people who are generating their own profits using my engine.  But plenty of developers are also not keen on the Unreal style revenue share model, which I can also understand.

Your suggestion for using commissions for enhancements may work (e.g. adding shader support), though I wouldn't want to charge for bugfixes.  Perhaps the best way forward is to release everything in an alpha state with a non-commercial license and figure out the commercial licensing later once (or if!) someone wants to sell their game.

I'm hoping to launch XAGE this year, hopefully before my daughter's 10th birthday as that would represent a decade of vapourware.

Here are some ideas I'm mulling over: gamedev subreddit

Feel free to add your 2p either on reddit or here.  Given that XAGE supports converting AGS projects I thought it may be of some interest.

I don't have much to add other than to empathise with CW's position - it's difficult to maintain a constant level of motivation while sinking years of effort into a long term project.  The difference here is that CW also has the added weight of expectation from an active community.

While it's fair to say that my own engine has converged with AGS further, especially in the last twelve months, it still only supports a subset of functionality and almost certainly will never be a full reimplementation.  There's lots to do and never enough time!

XAGE is still quietly in active development but Silverlight has been dropped from the list of supported platforms.  It required a lot of work to keep in sync with the others and when Microsoft dropped support a few years back there seemed little point continuing.  There is potential for HTML5 support in future using JSIL but this is hypothetical.

Back in 2010 I ported Ben Chandler's AGS game Awakener to XAGE.  In 2014 I've ported it a second time, to prove and showcase some new enhancements and the new direction for the engine.  The details of this have been blogged and demoed in a short youtube video.   

• Windows:  http://clarvalon.itch.io/awakener
• Android:  https://play.google.com/store/apps/details?id=awakener.awakener (no Ads, no IAPs)

I picked up Blackwell games for android last week and they work really well.  The improved portability of AGS somewhat makes an original goal of mine redundant, though focus has now shifted onto XAGE's pure C# scripting and Visual Studio integration.

If anyone has the time to try the above out I'd appreciate any feedback or bug reports.

XAGE has been offline for a long while now as I've been re-working some of the core parts, and the supporting tools need work to bring them in line with the new approach (heavy Visual Studio integration).  The compiled exporter plugin is available here:  AGS.Plugin.ExportToXAGE.dll

Alternative to Tween:  Set up some code to record the cursor position whenever it changes, stamped with the frames elapsed.  Use this to record yourself perform the cursor actions and dump this data into a file (x, y, elapsedFrames).  Then load the data in for the tutorial and play it back, updating the mouse position at the required frames.

A more advanced version would capture and simulate mouse clicks.  One drawback is that any GUI changes would require you re-record your cursor movements again, though in theory you could manually edit the data file.

[RPG?]

My 2p - I'll preface this by saying I think that, given they're primarily the work of one man, AGSScript and AGS Editor are terrific.  Writing your own scripting language and IDE with high-level features like Intellisense is no mean feat.  The sheer number of games produced using AGS is testament to that.

BUT:  For people with a programming background, who are used to using best-in-class languages and developer tools, it can be a little frustrating.  Granted I've written little AGSScript personally, but even in that time I've had to implement unusual workarounds to bypass the shortcomings of the scripting.  And as someone who regularly converts to a somewhat stricter language (C#), things like AGSScript's laissez-faire approach to static typing can be a pain.

BUT:  A counter-argument would be that you have to keep AGS's primary purpose in mind (highlighting mine):

What if i wanted to do this 1000 times for my RPG?

It lowers the barrier for entry for making Adventure Games significantly.  Having the scripting so tightly coupled with the editor is likely part of its success in bringing people in from a non-programming background.

I was asked for the source code so here it is in case anyone else can make use of it:  Clicky

Warning - hastily written, badly maintained code alert!

De-coupling the scripting from the game engine via an interface would seem to be the option providing the most flexibility going forward.  I've done something similar with XAGE:  http://youtu.be/0Ke49lJ8R94

The argument could also be made that having AGS Script tightly integrated in the IDE is one of AGS Editor's strengths.  As it stands, AGS is a tight, standalone package.  Potentially, beginners may be confused or deterred if forced to maintain their game scripts outside of the main IDE.

Horribly broken at the moment, but Android has finally joined the XAGE Party: 

One approach might be to provide an interface for the AGS engine for the scripts to hook into, de-coupling them completely.  This will leave you free to re-implement the engine in Java or whatever language you fancy.  That's how AGS conversions are handled in XAGE, which is (mostly) able to fully compile the AGS scripts into .NET dlls, though getting to that stage has been a little fiddly and required a handful of tricks to overcome the idiosyncrasies of the AGS scripting language.

Can't say it has happened before, but I do enjoy coming across forum threads where my name is put forward as a potential recipient of money

In all seriousness, as Ben mentioned there may be more immediate & worthwhile causes to be raising money for.  I have however recently been discussing eschewing the license model in favour of crowdfunding, so it's an idea I'm open to in future.

As Mark knows, over the last few months I've been re-writing the scripting system in XAGE to use pure C# rather than XML.  As a main focus has become porting AGS games, I've written an interface to the engine based entirely on the AGS scripting language, of which 20% of all properties and methods exposed have already been implemented (28% if you exclude functions marked as obsolete):  http://www.clarvalon.com/XAGE/XageProgress.png

Inevitably this means the two engines have converged further still, though under the hood they're quite different beasts.

.NET is not being abandoned - the new Metro UI just fragments the framework one step further.  The best write up on it I've read is on Miguel de Icaza's blog.

Apologies for resurrecting an old thread, but I've a follow up to the previous posts on my blog that may be of some interest:  http://clarvalon.blogspot.com/2011/09/new-direction.html

The gist of it is this - I've had a rethink with regards to the AGS to XAGE conversion process.  XAGE no longer uses it's proprietary scripting system and is instead being updated to use C# as a scripting language.  As part of the working prototype I've captured various standard AGS functions via a C# Interface and I'm now in the process of implementing them within the XAGE Engine.

I feel like I've addressed all the initial pitfalls of the technique detailed above, though if anyone is aware of any potential (or glaring) obstacles I've overlooked then I'd be glad to hear them before I plough the next few months of my life into this.

Superb, exactly what I needed.  Thanks guys.

Hi,

I was wondering whether there exists a full list of properties and functions (including parameters) available within AGS.  I'm not able to find anything on the site (search on the forums seems to be broken at the moment) and there doesn't seem to be anything like this on the wiki.  The AGS Editor help file is a great resource and does seem to cover everything, though I'm having to manually cut and paste each item which is rather time consuming.

e.g. a list similar to below would be fantastic:

Properties
int Character.x;
int Character.y
int Character.z
...

Functions:
Character.ChangeRoom(int room_number, optional int x, optional int y)
Character.ChangeRoomAutoPosition(int room_number, optional int newPosition)
Character.ChangeView(int view)
...

Thanks,
Dan