At the same time, real-time (or almost real-time) live updates to the game are extremely important. What this (or any other) remote channel allows you to do is to change any content through any editor you want, and send it to the game to hotload (whether it’s just a ping saying reload a file from disk, or actually sending all the binary data). Maybe you can get away with just updating some files and have the game monitor them, but that’s a pretty coarse method for data that could be pretty small (especially if you’re using some sort of pak files). In other words, there’s nothing stopping you from getting the best of both worlds and hooking up the remote tweaking to your tool of choice and edit any data on the fly.

The programmer thinks “it’s just take me a few lines of code to expose the entire game tree to be tweakable”. After that each new editing feature always seems like a just few more lines of code. The program never realizes the fact that basing editing on the game engine was the path to bad tools, inflexible tools in the first place.

I’m not saying you want your game editor to replace Photoshop and Maya. I’m saying that a game editor that is as powerful at editing games as Photoshop is editing images and Maya is editing 3D is what you want. I’m saying the path starting from tweakable game data is NOT the path that will get you there. In fact that path that will lead you to keep thinking you have good tools when in reality you’re seriously hobbling your designers because right from the start.

If you want good tools to edit “game parameters, debugging info, AI options, data relationships” and other game data you have to start from the “how should I design the tools to make the data editable” and not “how should I tweak the final game data”. The tools you end up with should have the layers and other abstractions that let designers create these AI options and data relationships with as many tools at their disposal as Maya gives for 3D and Photoshop gives for images.

But there’s another side to it.

Think of it this way. Let’s say you wrote a program to display an image. Assume the images are rgab 1 byte per channel. I’m sure that’s a pretty simple program regardless of how you imagine writing it. Consider this your “image display engine”. Now, following the logic above, you could make an in game tool to edit that image. You might have options to draw a single pixel at a time, select a color, maybe something larger than 1 pixel, draw with the joypad. Or you could do this remotely. You write a front end, and edit, now at least you can use the mouse.

Following that plan, how long would it take get to the power of Photoshop? Without going through every detail I hope it should be pretty clear that if you want Photoshop, you don’t start with an image displaying engine and start tacking on features.

To get the power of Photoshop you have to design an editor, not an engine. An editor is designed for ease of editing. An engine is designed for speed of display or play. You’re not going to get layers, blending effects, layer styles, undo, 9 kinds of plugins, text layers, vector layers, importers, and all the other thousands of Photoshop features that make artists so productive by starting with the image displaying engine.

The same is true of games. All these game editors that start with the game and then add editing on are starting from the wrong place entirely. This why editors like Unreal, Unity, etc are not even close to the level of sophistication as Photoshop, Maya, XSI etc. They were never designed first and foremost as editors, they were designed as games. They don’t have the tens of compounded layers that let the designers build things in editable components and then “bake it” into game data the same way photoshop takes 50 layers and bakes it into a jpg.

It’s that “designed for editing” that makes “editors” like Photoshop, Maya, XSI, Illustrator, so powerful and let’s them make artists so productive. And, it’s that lack of “designed for editing” that makes tweakers based on the game engine a path that eventually leads to a deadends and poorly designed tools.

Actually, I just talked to Charles and we’re going to open source the server and the client and hopefully other people can help with native Mac (or Linux or whatever) client implentations.

The previous tools that @fcycles built for working on the GP2X he went the opposite direction and it was all built inside a library that we link against when building an apps. But it was pretty low-level, you could switch the different resolutions supported by the graphics on the fly, display different hardware register and poke to them, it was just missing a Machine Language monitor ;-p. Yes input were limited to using joypad and buttons, and if you plug in a dev board you then had access to the keyboard to type in command.

You could see here how our tools look like in action on the actual hardware .
http://twitpic.com/tajpw

petal/spring_dampening, "Spring dampening", float, 0.00, 1.00, RW
petal/texture_mask, "Petal mask", int, 0, 9, RW
petal/color0a, "Starting inner color", color, RW

Notice there’s even a RW parameter I forgot to mention. You can tag variables as Read/Write or Read-Only, so it’s clear which ones the client can modify.