It's coming up to 18 months since I started work on XAGE. During that time the focus of development has shifted so much, it seems like a good time to recap how XAGE began, where it currently is and where it is going.
The Past:
The original project started as an effort to get my own adventure game on the Xbox Live Indie Games channel (then 'Community Games'). After a few months work the engine was in a playable state and, using Monkey Island 2 placeholder artwork, I was able to hardcode a small demo room. It was obvious that I needed to develop a tool to enable me to quickly create all the game content from scratch, whilst the engine itself essentially operated as an interpreter (similar to SCUMM).
Soon after the original Editor had been created, it struck me that other people may be interested in the tools I was creating. Posting in a handful of forums prompted a positive response, and I started to receive emails with comments, suggestions and general feedback - all of which has been incredibly useful and a good source of motivation. And thus, the Xna Adventure Game Engine was born.
From that point on, focus shifted from the engine to the editor itself. Numerous revisions and improvements have meant that the editor is fairly straightforward and easy to use. I took a look at the competition - AGS, Wintermute and later Visionaire2D, all of which have their strengths and weaknesses. I found myself most drawn to AGS, of which I already had a passing familiarity, as it had a lot of similarities and it seemed to have the most active and friendliest community.
As development progressed I began to think more long term about possible game projects. As I'm a slow and clumsy pixel artist, I felt that it may be a better use of my time to instead think about converting existing games to XAGE for release to the Xbox. I contacted the author of a short AGS game tentatively asking what he thought of the idea, and again the response was favourable. I have since spoken to two others, and been contacted by about a dozen or so more developers, some indie, some commercial. It is pleasing that through only a few forum posts, blogs and youtube videos XAGE has caught the attention of the handful of people I had hoped it might. I have a good idea of who I'd be interested in working with in the future and there are no end of interesting games to port.
Along the way I discovered the open source Silversprite project, and in an afternoon had XAGE up and running in a web browser. This has added a complication insofar that all new functionality has to be supported across all three target platforms - Windows PC, Xbox and Silverlight. On the other hand, it broadens the scope of compatibility to otherwise C# unfriendly platforms such as Linux and Macs.
Eager to put the maturing Editor through it's paces, I spent four or five weeks making my own short game, The Fourth Wall, for Microsoft's DreamBuildPlay competition. It was a useful exercise, leading to a lot of bugfixes, as well as proving (to me and the four or five people who played it) the viability of the engine.
The next shift in development focus came when I discovered that it was possible to automate a large part of the work when converting an AGS game to XAGE, drastically reducing the work required for the end user. Numerous improvements later and I am now tweaking and altering a few outstanding aspects of XAGE's design in order to aid the AGS conversions. This has only been possible by using the few Open Source AGS games available, and more recently Awakener.
The Present:
I'm working on getting Awakener to convert as accurately and simply as possible. I'm having to plumb in new functionality to support this, such as local script variables, script paramaters, GUI customisation etc. This is a lot of work, but the end result will be worth it, vastly improving the feasibility of running complete AGS games on the Xbox.
The Future:
The roadmap on this blog is periodically juggled and amended. Once the work on Awakener is complete, I'll look at other AGS games to help finalise the XAGE GUI design. ETA for this is 8-12 weeks depending on how much time I get to spend.
Following that there will be three main milestones:
- Rework The Fourth Wall to work with the latest version & release to XBLIG.
- Release XAGE v0.5 (or whichever version is current) as Beta on a swanky new, dedicated website (i.e. begin the PR).
- Identify & negotiate rights to the first AGS game to be released on the Xbox360.
So ... there you have it. I'd like to thank everyone who has shown an interest in XAGE so far - your support and encouragement has always been appreciated. To that end, XAGE will always remain completely free for non-commercial use.
11 comments:
Hi, I'd love to know some things..
Let's say that this is the script issued when a user clicks to pick something up:
hero.WalkTo(x, y);
hero.Inventory.Add(someProp);
scene.Remove(someProp);
How are all these events 'queued'? I mean WalkTo needs to be run until it's completed and THEN the prop gets added to the inventory.
I'd also like to know how dialoges are queued etc
The individual actions within the script are run sequentially. Some Actions are instant (adding inventory, changing an object's display name etc.) and others aren't (walk to, talk to, pause, run custom anim etc).
Currently, the actions that aren't instant will halt the script until they are complete. In the future they will come with an optional flag (much like AGS's anim blocking technique) in order to say whether the script is halted or not. This will allow for two characters to be walking/talking at the same time within the same script.
It's also possible for an object or character to initiate its own script in order to run their own set of actions independently (see the blog post about clouds - slightly outdated but still relevant).
Hope this answers your question. I'm not sure what you mean about dialogue queues.
Thanks for your fast response! :)
Yes that was an interesting post... but I still don't get how the clouds movement doesn't halt the players walking or.. one cloud halting the others clouds movement.
Also in hero.WalkTo(x, y); how do you determine weather or not you've reached the destination and what happens when you do? There has to be a method somewhere that takes care of which animation to use (depending on which direction the players moves in) etc. I'd love to know how that method looks like :)
It's great to see how far you've come in 18 months.
I look forward to see what the next 18 months holds!
Just look at that counter! (9779).
To quote the book.."Two to the power of nine thousand seven hundred and seventy six and falling.."
Thanks Ben. DN: I'll get that number down eventually!
@Anonymous: Each cloud objects runs its own script to move it. XAGE pretends to be multithreaded (it isn't really, but close enough) in that the general update thread iterates through each object and determines whether that object has a script running, and whether that script needs to advance to the next action.
As these scripts only reference one specific object, they do not interfere with each other. That's why the player character is able to walk around and do his own thing without the clouds affecting him. I should probably explain this in a diagram when it comes to writing the documentation.
As for walking, yes, this is hardcoded as a few C# methods. Room traversal is, algorithmically, one of the most complext things in XAGE but once broken down into smaller problems is actually quite straightforward.
On a simple level, first the start and end point have to be determined (player's current position and destination). From this you can work out the vector, and from that you have the player's direction (XAGE currently only supports four directions as most adventure games only use four, but will eventually support diagonals too). You can then determine whether the end point is more than a stepsize away from the start point - if so, move the player a step towards the end point and update the walking animation.
On a more advanced level, you need to factor in things like scaling and pathfinding. XAGE uses a series of geometric walkboxes, and when one is created or edited XAGE Editor generates a new WalkBox Matrix. The matrix contains information on the most optimal way of getting from any walkbox to any other (generated using the A* algorithm).
The engine itself uses this matrix in order to determine which boxes the player's start and end point are in, and therefore can figure out which waypoints to use along the way (if any).
Ah, thanks! That's just what I wanted to know!
Sorry to bother you with all these questions :P
No problem. I'm happy to answer questions, as it gives me ideas about what I need to cover for the documentation.
What about a dialog between A: the hero and some NPC and B: between a NPC and another NPC. Whose the "parent" of the dialog-script in these cases?
Keep up the good work, I will probably want to use XAGE in the future. (Most likely when you start charging for it and I no longer have the money to pay for it)
Keith
btw in case you didn't know Uhfgood's Game Reviews is now Indie Flux at http://indieflux.com
@Uhfgood: XAGE will always be free to play around with. I won't be recommending anyone buy a license (when the time comes) until they've already finished or are closed to finishing a game they want to distribute commercially. Good luck with the new site.
@Anonymous: The parent object (i.e. the script runner) for a conversation is always the player character. A 'conversation' in XAGE is where the GUI presents the player with a number of dialogue options. This only ever happens when the player is actively involved, and as such there's no such thing as a conversation between two NPCs. It's simple enough to have two NPCs talking back and forth within a single linear script, and any object can be the parent to that script.
Post a Comment