There are a few things missing, and you might notice that Guybrush walks backwards (sprite flipping is not yet supported), but the library can only mature. Performance isn't stellar but with some optimisations in both XAGE and SilverSprite, I can really see it being comparible to the original formats.
The best part is that Silverlight is not specific to Windows, and there will be no dependancy on the XNA runtimes. This means that there is the possibility that XAGE could offer broad multi-platform support, something I've seen developers of commercial AGS games bemoan. The list of platforms are as follows:
Executable:
- Windows PC (XP/Vista/7)
- Xbox 360
- Mac OS X
- Linux
- Windows Mobile 6
- Symbian (Nokia)
EDIT: I've just read up on Silverlight v3 which is currently in Beta. Apparently there will be options for developers to allow users to store the SL apps offline and be run outside of a browser. This is all very good news - essentially as good as native support for these platforms but with minimal effort. It will be interesting to see how this all pans out and how well XAGE can exploit these features.
4 comments:
The idea that we could develop a game and abstract away the plumbing of deploying to a console or browser is amazing. More impressive than what many of the web 2.0 sites deliver in my book.
Absolutely. I never would have thought I'd be able to target more than two platforms using C#/XNA. There are undoubtedly quite a few wrinkles in the SilverLight version of the XAGE build, but that's partly down of lack of maturity and optimisations. Targeting multiple platforms makes XAGE more complicated to develop, but not overwhelmingly so. It's worth the effort.
I've been able to get the latest version running OOB (out of browser) using the SilverLight 3 beta. Once S3 comes out of Beta the next step would be to get some screengrabs of XAGE running on XP, an Xbox 360 and a Mac side by side. I think that would help tremendously in drumming up interest for the launch of v1.0.
P.S. How are you getting on with v0.3?
For v0.3, I'm running through the exercise of how I'd use XAGE to build every room I'm planning on making. It has been smooth sailing so far.
I see your roadmap lists dynamic walkboxes, could you explain more about what you were planning? I can think of a couple related features I'd use: 1) ability to toggle walkboxes on & off from scripts 2) walkboxes triggering a script. Maybe it's possible to do this and I just haven't found it yet.
These are post v1.0 wishes in my book anyhow, but still curious what your plans were.
There's a few things with WalkBoxes that I've fixed already for v0.4, and there's still stuff left to do. I'm taking the approach of implementing features as and when I need them for my game, as it makes it easier to test in a real-world situation, though I'm happy to fix or add new features that others need. I still need to add the following for WalkBoxes:
1) As you mention, the ability to set an initial on/off status for each WalkBox (and amend this via scripting). This would be handy in rooms where there's an obstacle to overcome (e.g. a toll booth).
2) As you mention, the ability to run scripts based on the player entering a walkbox (e.g. for an ambush situation). It's possible to achieve a similar effect using an invisible room object but it wouldn't work nearly as well.
3) XAGE Editor needs to make creating WalkBoxes easier. The selection pixel will be changed so you can more easily see which corner you're selecting, plus it needs to show which walkboxes any given box is currently connected to.
4) Not directly related, but the selection box for an NPC walking across the room needs to be updated. The walk to x,y position is calculated on the fly and this is currently pretty inefficient and almost always inaccurate (you can see this by enabling Debugging - D on the keyboard).
All in all, it needs to be easier to create room WalkBoxes in XAGE Editor, and it needs to flag up potential problems with the WalkBoxMatrix (e.g. unreachable boxes), generation of which is completely abstracted away from m the end user).
With luck I'll get some of the above done for v0.4 (all before v1.0). By the way, Z-Positions have now been removed as they were somewhat redundant. The drawing order is now completely dictated by a an object's Y position, as its possible to do everything you need with the Y position and an animation frame's hotspot.
Apologies for the long comment - I find writing things out helps me think them through and it's useful as a point of reference.
Post a Comment