AgateLib

hmm.. apparently Axiom has support for deploying to both the XBox and Linux. I am not sure if they considered the potential licensing issues though.

I think distribution refers to the publishing entity in this case. Meaning, you don't have to go through X-Box/Windows Live to get your application published.

In other words, I could go through Valve's Steam marketplace to sell my Windows-only game provided I don't include any of their libraries that they deem non-distributable outside of their channel. The game is still Windows-only though, which doesn't violate the "you can only use this to develop for Microsoft platforms" clause.

From what I've seen, the incentive is you don't have to be careful about what .dll's you include. The use of game studio is required to release on XBox or Zune. Does that portion of dependency constitute "development"? You'd have to prove that you used Game Studio only to develop the XBox/Zune bits, and any refactoring you did that touched other platforms were done with MonoDevelop or notepad or something like that...

I'm not sure how enforceable that point on the EULA is anyway. That's almost like Adobe forbidding someone from loading a .jpg in another painting program if it was originally created in Photoshop. Of course, I wouldn't want to be the little guy challenging Microsoft on it. Wouldn't be the first time one has lost that battle.

Yeah, that's right, I remember coming across that part of the docs. I am not sure exactly what it means. Quoting from the Creator's Club FAQ:

Who owns the IP rights to the game I create? Can I distribute my game on non-Microsoft services?
You own the complete IP rights to your game, and you are free to distribute through any service of your choosing. However, we may provide incentives for exclusive distribution through Microsoft services.

This makes it sound like you can deploy on other platforms, as long as you don't use the XNA game studio to develop the game. So maybe you could develop the game without game studio, and when it's done, port it to the XBox using game studio.

Hey Kanato:
I looked at XNA Game Studio today out of curiosity, and there may one good reason NOT to support XNA in there..

Namely this item in their EULA:
d. Use Specific to Windows, Zune and Xbox 360. You may not use the software to develop programs that run on any platform other than the Windows, Zune or Xbox 360 platforms.

Now the terms seem a little ambiguous. If the game written with AgateLib was only intended for the 360/Zune, then I imagine you haven't broken the agreement. But if you have a game that runs on other platforms like Mac or Linux, and then you attempt to use Game Studio to port/bind AgateLib to have it run on a 360/Zune, have you violated the agreement because the game exists on other platforms? Or maybe ports aren't even an issue here, and the point is moot.

Most XBLA titles are written in native code and under a different agreement, so games co-existing on PS3 are probably not problematic. But since the creator's club is an exclusive club to XBox, does this imply they are trying to make software created with this ALSO exclusive?

So the big question is... if the tremendous effort to implement XNA into AgateLib this turns out to be something you can't reuse on other platforms, is it still worth while? For me, it wouldn't be, but I could see how someone else might find a simplified interface to XNA a worthwhile thing.

Silverlight (or simply, all things WPF) use retained mode rendering. If you were to compare Silverlight to a standard game loop, all Silverlight client code occurs in what would be the game loop's equivalent to an "OnUpdate" event. You modify parameters on your display's object graph, but the results aren't reflected on the spot.

Once your code leaves the call stack, the Silverlight framework takes over and performs all the system level operations such as rendering, remote server WCF calls and so on (so, in other words, all web service calls are asynchronous as a result).

For example, if you have your client code tell a textbox or something to turn invisible, it doesn't do so immediately like it would with a Winform user control. The rendering code that makes it disappear doesn't execute until the call stack ends and returns to the Silverlight framework's main loop.

The gain here is "over draw" is significantly reduced. However, if you're used to Winform or immediate mode rendering (such as what you are doing), the seeming asynchronous behavior takes a bit to get used to.

I guess I was more concerned with resolution independence where the changes aren't significant, but enough to be noticeable. Such as moving from standard resolution to high definition. It would be nice not to hard code an application to a particular screen resolution and then have it stretch, black bar the sides or scroll when an HD resolution is selected. I was suggesting taking the DVD/Home movie approach of making the game ALWAYS in widescreen, and have it scale down to those situations. Plus, what resolutions are available from card to card isn't always reliable. I believe some games in XBox Live Arcade center the application against a static wallpaper (which might also be a good work around). In this case, you would have to enforce a minimum resolution, and then center the playfield area when the resolution is bigger. And I suppose the good news here is that it falls out of scope of AgateLib. The client code could deal with this when it does it's rendering.

I do agree that a game moving from PC-based to a hand-held device/console might be a little jarring in terms of scaling of images and input (though I've heard some of those hand helds have some pretty impressive resolutions even on a small screen. My Zune certainly does.) Except for the extremely simple applications, I'd suspect you wouldn't be able to do a "code once-deploy everywhere" thing with hand held platforms with other parts of your code either. There is a memory footprint consideration in console-ish applications that would have to be managed more than we normally do on the PC.

Then again, if 2D vector graphics were supported (such as those you see in Corel Draw or Illustrator), then it becomes more 3D-ish in terms of the way the visuals are rendered, and scaling probably becomes important and manageable across ALL platforms again. "Castle Crashers" on XBox Live Arcade is a good example of this. It's very 2D in nature, but it almost looks like filled vectors in it's implementation.

Yeah, I agree with you that targeting XNA for XBox support is still worthwhile, but the whole content issue would require a significant amount of work which I haven't been able to invest yet. Perhaps I should make this my next priority, since it will require a fair amount of redesign anyway. It would be interesting to know more about what needs to be done to target Silverlight and see if these features can be integrated. One thing, AgateLib does not have any concept of an object graph, this is basically left to the user to keep track of, and AgateLib basically operates like an "immediate mode" renderer, so to compare with WinForms it's more like using Drawing.Graphics to do rendering. How does one do rendering in Silverlight?
(One downside of XNA development for Windows is there is no access to any Direct3D 10 features, which is due to the hardware limitation of the XBox, so you're stuck with shader model 3.0 in the foreseeable future.)

Right now, the basic feature needed for resolution independent rendering is available, though relatively untested, with the Display.SetOrthoProjection method. The "unprojection" of mouse input coordinates is not implemented, but could be done so easily. But images scaled down can look as almost bad as images which are scaled up. The best solution is to have a version of each image for several different target resolutions. I'd also like to target devices like the GP2x and the OpenPandora, which have much lower resolutions and memory than PC's. The only way to reasonably deploy a game on both the desktop and a handheld device like this would be to design your resources for each platform. On top of that, one would probably need larger fonts at smaller resolution, so the playfield would have to be redesigned, and more issues crop up, etc. Then scaling graphics to a different aspect ratio may end up looking weird too. So, I don't know.. I don't really see resolution transparency as being a very useful feature. It solves a few minor problems if you're targeting resolutions that are fairly close, but I don't see it as offering any solution for the real problems that come with targeting largely different resolutions. Resolution independence works well in 3D, because when you scale up edges become sharper.

Agon:
Yes.. it will be quite an effort. To be honest, the content development is the biggest challenge of the entire project. I do have access to all of that hardware, and I'm also lucky enough to have access to some pretty talented people both in terms of artistic and technical ability. Cross platform development isn't unmanageable if you can keep the platform specific bits abstracted away from your main application. This is exactly what has been done with the AgateLib framework.

Kanato:
Thanks for your response. I figured that XNA (at least for the closed platforms) wouldn't be nearly as straight forward as the other base frameworks that are available. I still think the advantages are pretty significant though. Even if the build and execution flow had to follow a different pattern, I personally think that is a small price to pay for using nearly all of your game assets and code to get to that platform. Not to mention, I'm sure XNA will eventually be the pattern of choice for Windows development in the future. I would't be surprised if it comes to the point where coding directly to DirectX might be unnecessary, and Microsoft will herd game developers of any flavor toward XNA. They've already done this with WPF on the win form side.

I do agree the concept of "code once, deploy many" with the program managing all of the intricacies of platform independence and late-binding the necessary libraries is very appealing. However, I think beyond the core platforms you currently support, that this becomes a harder promise to keep. Utilities (or solution templates in visual studio) could be developed to set up the projects appropriately for those that don't follow your standard "late binding" model.

In terms of the challenges you identified for content pipeline and such, could you do a dependency injection type thing to create an abstraction layer for the storage? For the platforms capable of supporting tar/zips, those could be the persistence mechanisms on those platforms. For XNA, that storage mechanism could be Microsoft's proprietary pipeline gizmo that you talked about. I imagine some sort of converter would have to be involved to get stuff in one format over to the other. Or if Microsoft's pipeline API could be utilized on the OpenGL side, maybe that's how a developer should store the data if s/he decides that Xbox is one of the platforms desired for deployment. (Much like you've decided to favor HLSL and opt for a conversion to the GLSL counterpart)

On the Silverlight side...
I have done a fair amount of Silverlight development. You will likely see some familiarity in it to XNA's patterns. In fact, there is a library that allows one to convert 2D XNA code over to a Silverlight application with a little tweaking. And just like what you said about XNA, separate projects are required for Silverlight as well. Both of these frameworks hit a different version of the CLR, which at least in the case of Silverlight, is a subset of the 3.5 framework.

In Silverlight, you really do not have a whole lot of control over the rendering as much as you do over the object graph that is the basis for the render. So doing Winform control type behavior is a bit more difficult there (or at the very least, doesn't behave the same way as traditional winform controls do) No rendering is performed at all until your methods exit and control returns to the Silverlight processing loop.

In short, games developed with the intention of hitting Silverlight or XNA would be at a better advantage if the gotchas were known ahead of time and the game was written to accommodate them. I don't think the limitations of these platforms extend the other way so much. So I'm not certain that developing for those limitations would hinder targeting the OpenGL or DirectX adapters. I'd say the language sub-setting is probably the biggest hurdle to look out for.

As far as the resolution independence thing goes...
That java framework I mentioned implemented the resolution independence with a relatively small tweak. It was accomplished by splitting the resolution into two concepts. You have the resolution of the playfield (think of it as a stage in an auditorium), which is of a fixed size regardless of the monitor or screen resolution. All game logic utilizes this resolution when doing it's various processes and graphics are drawn with that size in mind.

The screen resolution is the resolution that varies. Compressing the playfield down to fit into the screen resolution is an operation that OpenGL can accomplish in hardware by adjusting the zoom on the viewport, or at least I believe that is the way this was handled in the java framework.

Of course, the input API's for the mouse would have to change a little bit as well.

You do have a good point about how some graphics scale better than others. I'd say this is one of those "gotchas" similar to developing for XNA and Silverlight. If you know the issues up front, it can be avoided pretty simply (i.e. make sure your graphics look good at the highest resolution you want to support)

So I'm glad you like AgateLib :)

I'm sort of on the fence about developing an XNA driver for AgateLib. My initial research (found here) revealed several disadvantages which will be annoying to deal with. First off, one doesn't get the same kind of platform-independent support that is available for Windows, Linux and Mac OS X. You can develop an AgateLib app on any of those platforms and it should run on any of the others, perhaps with some minor testing/fixes. To develop an Xbox application, you have to be on Windows with Visual Studio and XNA Game Studio installed, you have to make separate project files for your application, and you have to use the content pipeline for accessing images, audio and font files. AgateLib recently added support for reading images from compressed tar.gz and zip files, but this won't be compatible on the XBox. Also, it turns out the XBox does not allow any late binding of assemblies.

I was thinking SilverLight would be neat too. I have not really done any research into what it will take to go this direction. I've also been interested in supporting OpenGL ES, so devices like the OpenPandora and the GP2X Wiz could be supported. OpenTK (the .NET OpenGL bindings) recently gained support for OpenGL ES so this is a possibility.

As Agon said, the MPL allows usage of AgateLib in a closed source commercial application. The only stipulation is that if you make changes to AgateLib, you release those changes to the public. (For the most part, you shouldn't need to as most things you would want to build off of are public in the API.)

Yeah, I've thought a lot about the resolution independent problem, especially with monitors with different aspect ratios becoming common. It's not an easy problem to solve. For 2D games especially, since many 2D games have some sort of pixel art graphics that are best rendered pixel-perfect, which is the exact opposite of resolution independent. This sort of thing might require lots of small changes to different areas of AgateLib.

So a 2D arcade "space" shooter with lots of effects and a story :D .
Targeting so many platforms is really hard for one developer, isn't it?
You would need to have all the hardware for this platforms...

My particle system is available to the public. It sits in a branch on SVN.
But its not finished.

Hi Agon.

Nice to meet you, and thanks for the clarification on the license.

As far as the type of game I want to develop, I'm not entirely sure how much information you want there.

The game I want to make (from a creative point of view) would best be described as story-driven and somewhere between a casual game and a traditional arcade game such as what you would find on the Xbox Live arcade or Valve's Steam distribution channel. The game play as it is now would be somewhat familiar with to those who've played Geometry Wars, with a few twists here and there.

From a project management point of view, I want to keep it small and reasonable, yet (hopefully) professional in it's presentation. I'd like to distribute it commercially if I'm able to get it to that level of polish. Specifically to the PC/Netbook/Mac/Linux realm as well XBox and Zune. Mobile platforms might be possible too if I can keep the scope under control.

That said, I'm a software architect my trade, and have worked on and successfully delivered many projects with fairly significant budgets. So, I'm hoping the knowledge I've gained by that will keep me from falling into the trap of over-ambition that many would-be game developers seem to fall into. :) Further, It's been awhile since I've done anything outside of the realm of web development and Silverlight that is cross platform. I'm hoping this will be a good experience on that front as well.

Anyway.. Thats probably all I can and should say for now on my personal project. Not because I'm worried about secrecy, but because at this point it's not more than vaporware sitting in a notebook next to me on the desk. :)

I imagine your particle system will come in handy for me should you make it available to the general public. Good luck with that.

The only thing I can think of off the top of my head that would be a nice extension to AgateLib as it is now would be to introduce the concept of resolution independence in terms of rendering as well as scaling the input appropriately. Also the ability to have an overlay layer for rendering heads-up displays and such would be good too. I was previously using an LWJGL-backed java-based 2D library called Slick that was able to do this, so I imagine it would be something that could be implemented in AgateLib with a similar amount of effort. This functionality would allow the underlying game logic not to have to worry about various monitor sizes. Standard resolution monitors would render the game in a black-barred wide-screen format (with the overlay rendering on the bars when needed), and HD/widescreen televisions/monitors would render fine as well. This is a design challenge that affects both PC and console-based platforms.

Unfortunately, I'm not sure of the scope of what this type of extension would be yet (i.e. Is it something that could sit on top of the existing AgateLib framework, or if it would have to go deeper into the "driver" implementations)

A Silverlight backend would be nice, indeed.

The license is Mozilla Public license which allows using AgateLib in a commercial application.
Wiki: http://en.wikipedia.org/wiki/Mozilla_Public_License

I suggest you write your game and if you miss a feature in AgateLib you can add it if it fit in.
I'm doing this for example with the a particle system. AgateLib has no particle system and Im adding one to it.

What kind of game do you want to develop?