You should embed a tiny web server in your game engine.
It doesn't need to ship with the game, of course; this is a development tool. If you're into letting people mod your work, though, consider leaving the server active.
Don't roll your own. That takes too much work and is a security liability. There are plenty of tiny HTTP servers available in the open source world, in virtually any relevant language you can name; pick one and go with it.
What does this server do, you ask? Simple. It provides a window into the game world that can rival even the best IDE debugger's offerings. It gives designers and content creators a way to iterate on their work almost instantly instead of spending hours in the build/test/tweak/rebuild cycle. And it offers a mechanism for directly manipulating your game state for easy experimentation and exploration.
Sound fantastical? Too good to be true? Read on!
Debugging Unhinged
Ever wanted to dump a list of every NPC in your game and view its current state? Done. Stuck on a bug that only repros after several hours of play on someone else's machine, who doesn't have a debugger installed? No problem! Just dump the relevant data through your web server and you can diagnose it right at their desk. Frustrated by the difficulty of reading complex data structures in your debugger's interface? Worry no more; you can output the data you want and view it in any way that makes sense to you. No messing with visualizers or other IDE extensions.
The Ultimate Iteration Tool
This was actually my original motivation for building one of these suckers. Suppose you're working on tuning a game feature, and you need to edit a few numbers repeatedly. Make a tweak, test the changes, tweak some more, rinse, repeat. If you have to run through a build cycle every time this tweaking happens, you're in for a lot of pain.
Worse, you will lose context every time you wait on a build. Even if all you need to do is restart the engine or reload a level, your brain will stop processing the task at hand and get distracted a tiny bit (or a lot). If you could edit those numbers and instantly see the game change in response, you can keep that feedback loop tight and fast.
The best part? Iterating instantly means you'll not only have time to try a lot of ideas, but you'll find that over time it changes the kinds of ideas you have in the first place.
This is powerful.
OK, OK, sign me up. How do I do it?
Pick some lightweight HTTP server code. Plunk it into your engine and set it up to listen on some innocuous port (I like 8088). You're going to need to implement three things: the landing page, the "features", and the web-facing UI.
First, the landing page. This should just be a list of things you can go do in the game. As you add features, it should grow. (Hint: generate this page dynamically. Trust me, it's cooler that way.) This is the first thing a user sees when hitting your web page, and should help guide them into what they want to see or do.
Secondly, the features. This is the bulk of the work. In my system, I have a simple central API where I can register a "web console feature." This is basically just a set of callbacks. When someone opens the web page for the game, they click a link for a feature, and the appropriate callback is invoked.
Each feature is just a well-defined unit of functionality, such as "list all NPCs" or "drill into detail on a specific NPC" or "show me the stats of all the weapons in the game" or whatever. From the code side, the implementation is easy enough, but once you start wiring this up, chances are you'll get addicted to it and find yourself wiring up more and more code to the system.
Now for the UI bit, and the secret sauce. Don't generate HTML in your web server. Instead, generate XML documents. This allows you to keep the code that emits the web page constant, as long as the data it puts out remains in the same form. When you want to actually use this XML, then you write a simple XSLT layer that turns it into something pretty.
This last bit of separation is crucial. It means you can update your view of the game data without rebuilding any engine code. It also means that you can have a web dev or someone else comfortable with XSLT and HTML build the UI for you. You can even do fancy JavaScript, CSS, and whatever else your browser supports. Just remember to keep the original data in simple XML, so that the UI layer can be upgraded at any time, without touching the engine itself. This is especially vital on larger teams where you don't want to constantly make updates to the "NPC code file" every time you change the color scheme of the UI.
Bonus Mode
Here's a handful of ideas to run with, that make this system really shine:
- Give each game object a unique ID. Offer a URL that lets you enter an ID and see details about the corresponding game object.
- Attach state information as well as static information. Don't just say this NPC has 50 hit points, show his max as well. Hell, show his entire character sheet or whatever.
- Don't forget this doesn't have to be read-only. Letting people edit the game via the web console is insanely powerful and a great time-saver.
- Mock up a rough draft and hand it to a Web UX designer to build a really shiny product out of it.
- Try to make URLs stable and easy to share between developers.
Do all this stuff, and I promise your team will love you. YOU might even love you, I don't know. Either way... enjoy your new fame and glory!
Have to sign this.
My game implemented a webserver and it was one of the most useful things I have added to my engine in the recent decade.
Additionally , using HTML5 canvas + Javascript + Ajax helps a lot to rapidly implementing really useful tools just by using your common webbrowser.