Systematic Gaming

January 31, 2009

Game-Tool Communication

Filed under: game programming, workflow — Tags: , , — systematicgaming @ 12:20 am

Modern games are extremely content heavy – most of the people on a game team are part of the art or design departments.  The larger a the team get the greater the portion of content producers becomes, and the trend will only continue.

So what does this have to do with game systems programming?

The more content you game has the better your tools have to be.  The best tools are robust, efficient and as seamless as possible.  The key to a seamless workflow is close integration with your tools and game engine.

There are basically two ways to accomplish this:

  • Direct integration of the game engine with the tool
  • Remote integration via a communication layer

Direct Integration

Essentially, direct integration is embedding you game engine into a tool.  How much you embed – just the rendering engine or the entire game – depends on the tool and the level of integration you need. Direct integration can provide the most seamless experience, since the tool is essentially running the game.  Changes in the tool can quite easily be immediately updated in the engine.  However this often incurs a great deal of engineering time. Consider the amount of effort required to implement a full-blown 3D editing package on top an entire game engine.

Often direct integration is reserved for custom tools that create and edit custom data.  For example it’s very common to have a particle effect tool that uses the game’s rendering engine and allows effect artists to view their changes in real-time.  However, embedding a game engine with a 3D package like Maya is a nearly impossible engineering feat.

Direct integration is often only really useful on games with a working PC version.  Many console-only games have some running PC version – often not near shipping quality, but functional.  The GUI limitations of console platforms means that they don’t make very good editing environments.  Real-time editing is usually reserved for some basic debug menu functionality.  Also screen space is limited on TVs, a problem PCs don’t suffer from.

Remote Integration

Remote integration refers to having a tool communicate with another process which may or may not be running on another device like a console.  The key point is that the tool and game engine are in separate processes, meaning you can’t just start poking at memory to change stuff.  You need a method of communication and a protocol for communicating.

The simplest and most common way is a simple IP connection between the processes.  This works well because TCP is well supported on most platforms so it’s fairly portable.  Not all consoles have a network interface suitable for development usage, usually they do support some sort of data connectivity and you can often implement a IP-like layer yourself.

Remote integration requires effort to expose the engine’s internals to the communication layer.  Each feature you want to integrate will usually need some sort of communication code.  The amount of effort directly depends on the level of integration desired.  Setting a specific variable can be done easily by sending a simple message (e.g. “SetColorRGB(1, 0.5, 0.3)”). If the engine has a scripting system already it may be best to simply integration your communication layer on top of the scripting engine, allowing you to script the game remotely.

It gets more complicated when you want real time data from the game displayed in the tool.  Networking often doesn’t have the bandwidth or latency to keep up with a 60fps engine.

Direct or Remote?

So how do you choose to integrate a tool direction or remotely?

Often you don’t have a choice – the tool may not support the level of customization required, this is common for 3rd party tools.  Even if you can integrate directly, you may choose not to because it’s just too much work.  Unfortunately some 3rd party tools don’t really support any customization, so integration of any kind is a moot point.

For first party tools you of course have the freedom do what ever you want.  So how do you decide?  Here are some of the main factors I take into consideration:

  • What data does the tool work with?
  • Who is the main user of the tool?
  • What platforms are you targeting?
  • How much effort is required?

The data a tool operates on is important – tools that work with large data sets like textures and models can be difficult to use through remote communication efficiently.  If a tool works on small data sets, like character attributes (hit points, damage), a remove communication can work quite effectively.  Where a directly integrated engine can update textures directly, a remove tool may have to settle for sending a “reload” message to the engine, and have the engine do the heavy lifting.

The user of a tool is also very important.  Some users require faster feedback than others.  Designers who are trying to balance your game will probably want real-time tuning of data.  However modelers don’t usually need that kind of instant feedback.  Not that it wouldn’t be useful, just not really needed.

The target environment is important, if you’re making a console-only game then you don’t care too much about tuning your windows build.  Sure, it should be a reasonable representation of your game, but what really matters is your final target platform.  Generally if you’re focused on console development, you want to manipulate your core data on the PC and be able to tune and adjust values on the console.

Of course effort of integration is very important.  A complex feature may need a very complex communication protocol to allow remote integration.  A old, or 3rd party tool may require a great deal of effort to directly integrate with a newer game engine.

In general – you want direct integration when dealing with large data sets or intensive operations.  For example a custom map editor works well with direct engine integration.   You can see changes to levels in real-time and with may game engine features instantly available.  For tuning simple values – like AI parameters or material and simple graphical settings – remote integration works well, and is very console friendly.

In the end…

The only thing that really matters is you have a solid, seamless way of interfacing your tools to your game.  Direct and remote integration and just the two basic approaches.  It’s quite feasable and common to have some support for both – like a PC tool that’s directly integrated with your engine and able to communicate remotely with your console version. Both your tools and workflow must be constantly evolving and improving and game-tool integration is a key component.

Advertisements

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: