I remember reading someone say on gamedev.net that at some point everyone tries to write their own UI system, and usually gets it wrong. Apparently he’s right (or at least about the first part), because I’ve gone ahead and written a menu/UI system. While it initially started out as part of the engine/framework I’ve been working on for my game, as I worked on it I decided it might be better off if I decoupled it from the rest of the engine components and made it a standalone library/editor package so that other people could make use of it.
While designing and implementing I had these goals in mind:
- Keep it simple! Make menu elements useful by default, but don’t cram in tons of functionality with limited use. Just let them be flexible enough so that they can be customized for unusual cases.
- Cross-platform, with a focus on Xbox 360. Should look identical on both, and expose the same functionality regardless of input method.
- Page-based layout. A few of the other GUI packages out there seem to be aimed at recreating WinForms using XNA…and I think that’s silly. You don’t want sizeable windows for a game (or at least not most games), you want menus that are logically divided up into pages that you can switch between.
- A PC-only editor application that lets you visually design your menus. The core library should be aware of the fact that it can run in a designer, and provide support for this.
- Free and open-source!
What I ended up with is the CPX Menu System. It actually came out better than I expected…the editor is very stable and works pretty nicely. It could use somore more fancy features (like tools for lining up menu items), but it definitely WORKS and I’m happy about that. As for the menu item types included in the library itself…it’s pretty bare-bones but you can still do a lot with them. I mean personally for my game I wouldn’t really need a whole lot more than what I put in the sample app.
Probably the biggest weakness it has working with content is a bit awkward. Early on a I struggled a lot with trying to come up with a good way to handle it…and I don’t feel like I ever really came up with a killer solution. As of right now the way it works is that the editor app itself does not build any content at runtime. This isn’t so nice, since you have to have Content compiled ahead of time before you run the app. The upside is that editor doesn’t depend on the content pipeline assemblies at all, so you can run it on a PC that doesn’t have the full XNA GS install. Probably the easiest way to manage content is to just add all of your menu content to the CPXMenu project’s Content project. If you do that, then you will always have the content available for the editor and your game (assuming you’re always building the editor in VS and running it that way). Otherwise you can tell the editor to look for content in a specific path whenever it loads a project. This is what I did for the sample app: it has its own Content project with some custom textures, so I set the editor to look in the output folder for that project.
I guess that’s it for now…at some point I suppose I’ll announce it on Ziggyware. Maybe after I add some documentation explaining how to use the damned thing. In the meantime, here’s some screenshots of the sample app and the editor: