Inter process communication C# <--> C++ for game debugging engine.

I did this a couple of years ago. Script debugger was written in C#, and ran on PC; script runtime was written in C++, and ran on everything we supported at the time -- PC, PS3, Xbox360, Wii, DS, PSP and PS2.

Whatever you're targetting, I'd recommend putting in some kind of layer so that the debugger and runtime are insulated from the underlying protocol. Keep the API calls where you can keep an eye on them! This //leaves your options open, and (if done right) simplifies the code at both ends. Some kind of packet-based system, with packets of 1K or less, maps tolerably to just about anything. (Transmission of >1K can be accomplished at a higher level, using only the public API.)

If you're only targetting PC, I recommend TCP/IP. It's network-transparent, everybody is familiar with its IP addresses and ports, it's no harder to use API-wise than named pipes.

For a next gen title, if you want to strike a good balance between cross platform compatibility and ease of coding, TCP/IP is still the way to go. Works on PC, Xbox360, and PS3.

(Regarding named pipes, SN's Target Manager will give you named pipe support for PS3 and PS2, as I recall, and it goes via the dev LAN port rather than the game LAN port, but Xbox360 doesn't support it at all. So it might be worth supporting it -- and it's your only option in PSP, if I remember rightly! -- but it's not a universal panacea.

Personally, I stopped after implementing TCP/IP support, and I'm quite glad I did! As a summary, the Wii and DS are both horrid, but in different ways, and unlike anything else. The PSP only supports named pipes, for some unknown reason. The PS3 and PS2 support TCP/IP, but only via the game LAN port. (The dev LAN port works differently. Don't use it. Ask your producer for more network cables and save your sanity.) The Xbox360 supports TCP/IP, but only if you're using the debug libraries, and only via the game IP. (The debug IP works differently. Don't use it.)

In short -- whatever you do, you'll need that insulating layer.

Named pipes work in XP, and in .NET 2 (via PInvoke) - so they're a good option always.

Reed Copsey 2010-04-09 00:11:56

And, hell, on Unix, too, since nobody brings it up.

Jon Purdy 2010-04-09 00:19:11

Can't you take this a step further and, in the C# implementation, implement this with WCF using named pipes?

Jaxidian 2010-04-09 00:31:32

+1. for me WCF over named pipes.

kenny 2010-04-09 01:04:39

Named pipes it is. Thanks fellas.

Andy 2010-04-09 13:45:51

Fortunately I'm targeting PC with both applications. I think I'm going to go with named pipes, and implement the insulation layer like you suggested. Now--What's the best way to implement such an insulation layer? I don't want to write one version in C++ and another in C#. Is there an easy way to use C++ code in C# without having to load it from a dll?

Andy 2010-04-09 13:45:32

You can't get away from the DLL, but you could write C++ code, and use as-is in the game. Then write a shim in Managed C++, and compile that (and the C++ code) as managed C++ project for use in the debugger solution. That should be easy enough, and work fairly transparently. (For my part I just wrote the code twice, once in C++ and once in C#, and it wasn't too bad. I don't like to share code between game and tools if possible, the code just ends up getting pulled in 2 competing directions at once.)

brone 2010-04-09 21:36:32

ansaurus

tags:

views:

answers:

Inter process communication C# <--> C++ for game debugging engine.

related questions