What would be the best ways to communicate this type of data?

[hellrazor]

I'm trying to make a turn-based game, and I'm trying to figure out how to communicate between the game and the graphics. Something along the lines of:

• Game tells graphics "It is Billy the NPC's turn. Billy the NPC moves over here and turns to face this way. It is now Tom the Monster's turn. Tom the Monster attacks John the PC and rolls an 18 and hits John the NPC. John the PC takes 8 points of damage from Tom the Monster's attack. It is now John the PC's turn."
• Graphics tells game "John the PC casts Spaceballs the Spell on Tom the Monster."
• Game tells graphics "John the PC's Spaceballs the Spell hits Tom the Monster. Tom the Monster makes a fortitude save of 13 and fails. Tom the Monster takes 12 points of Hurty damage and dies."
• Graphics tells game "John the PC's turn is over."
• Game tells graphics "Billy the NPC goes over this way and blotterizes his kajiggers. It's now John the PC's turn."
• Graphics tells game "John the PC moves over to this area."
• Game tells graphics "Load this area" and somehow hands over the map's data to the graphics

The real intention is that the game tells the graphics what is going on, and the graphics tells the game what the player wants to do, and I don't exactly know what the best way to go about this is. I was thinking maybe keeping them in seperate processes and using pipes to communicate the actions and chunks of shared memory for the map data and such.

I'm working with C in Linux (at the moment).

 

[Aquinus]

I was thinking maybe keeping them in seperate processes and using pipes to communicate the actions and chunks of shared memory for the map data and such.

I wouldn't start micro-optimizing quite yet. Stick with your one process and if performance drops you can then think about how to speed it up. How far is your application, what do you have already?

 

[hellrazor]

It's to the point where I need to see what I'm doing (AKA I've got the map system, do I'll be starting the menuing system, and while I'm doing that I'll be working with characters), but I do want the graphics and the game to be as seperate as possible so I can get the game working and then just churn out different graphics libraries (nCurses, SDL, SFML, maybe OpenGL) for it.

 

[hellrazor]

It seems I've just mastered pthread.h if that's any help.

 

[librin.so.1]

• Graphics tells game "John the PC casts Spaceballs the Spell on Tom the Monster."
• Graphics tells game "John the PC's turn is over."
• Graphics tells game "John the PC moves over to this area."

I don't think the graphics portion should do this. The engine itself should keep track of these things.
While the graphics just draw what the engine tells it to. And informs the engine it finished some marked animation sequence (e.g. a square-to-square walking animation that is marked, so the graphics inform when it finished this sequence, while the engine waits for the graphics to do so while doing other tasks. When the engine receives "I finished this walking thing" it already knows what it asked the graphics to do and continues from there, along with knowing it is now safe to issue other "major" commands to the graphics)
In other words: the game engine tracks things while the graphics are "dumb" and just do what told to do and only inform when it finishes things so the game engine can sync with it.

At least that's the structure I imagine.

 

[hellrazor]

That's not quite what I'm asking.

 

[Kreij]

The graphics don't tell the game anything. The game simply displays the graphics.
Everything is done in the game code, and then displays the graphic results.

 

[librin.so.1]

That's not quite what I'm asking.

I know.
The thing is, the way You put it, the system would be so overly complicated I don't think it would be feasible, let alone efficient.
Thus, unless You describe/show us something of what You already have and describe what You still need to do in better detail, I'm afraid there's very little help we can provide.
IOW: "Help us help You"

 

[hellrazor]

The graphics don't tell the game anything. The game simply displays the graphics.
Everything is done in the game code, and then displays the graphic results.

How is the game supposed to know what the player wants to do? The graphics would have to handle what the player is clicking on, selecting, etc. since the game won't be able to tell what the mouse is over.

 

[librin.so.1]

How is the game supposed to know what the player wants to do? The graphics would have to handle what the player is clicking on, selecting, etc. since the game won't be able to tell what the mouse is over.

No.
The game engine tracks where everything is. And the game engine receives human input. And then things like this come into play [indirect hint] Hitbox.
Really, graphics just draw. And maybe informs the engine when it finishes doing things.

 

[hellrazor]

How is the game supposed to know what the mouse is over if the graphics draw it?

....I'll put it this way, here's is what the game outputs (to the screen) in the middle of a battle:

So assuming that the game DOES take user input, how is the game supposed to know that your mouse is over a character, or that you clicked on a tile, or that you selected a menu entry, or that you pressed the "End Turn" button?

 

[temp02]

Picture this:
Any character/object in the game has a set of polygons (or equation for ray-marching) that makes it up (visually/physically), a position in space (X, Y, Z) and a orientation (looking at). When the player presses the WASD keys it changes the players character X,Y,Z position, when the player moves the mouse it changes the Yaw,Pitch,Roll orientation. Now if you cast an ray starting at the player character position with the same orientation has the player character and intersect that ray with all the polygons that make the objects displayed on the screen and then select the first one (actually you should z-sorting before hit-test, and also use hit-boxes like spheres or later on cuboids for each object as an optimization) you get the object the player is looking at.

Take a look at some, very simple yet very good, NeHe OpenGL tutorials to get a glimpse of what you gotta do.
And yet, game engines track everything, and a lot more that what is visually drawn on the screen.

Good luck.

 

[librin.so.1]

That depends on how You handle the input. And on many, many other things.
But really, it's hard to suggest anything solid till we know more about Your engine.
One suggestion that might be gold for one WIP game, could be a "red herring" for another...

 

[hellrazor]

Picture this:
Any character/object in the game has a set of polygons (or equation for ray-marching) that makes it up (visually/physically), a position in space (X, Y, Z) and a orientation (looking at). When the player presses the WASD keys it changes the players character X,Y,Z position, when the player moves the mouse it changes the Yaw,Pitch,Roll orientation. Now if you cast an ray starting at the player character position with the same orientation has the player character and intersect that ray with all the polygons that make the objects displayed on the screen and then select the first one (actually you should z-sorting before hit-test, and also use hit-boxes like spheres or later on cuboids for each object as an optimization) you get the object the player is looking at.

Take a look at some, very simple yet very good, NeHe OpenGL tutorials to get a glimpse of what you gotta do.
And yet, game engines track everything, and a lot more that what is visually drawn on the screen.

Good luck.

You seem to be under the assumption that the game is going to be some action-oriented shooter. It's a turn-based, tile-based RPG.

That depends on how You handle the input. And on many, many other things.
But really, it's hard to suggest anything solid till we know more about Your engine.
One suggestion that might be gold for one WIP game, could be a "red herring" for another...

Okay, this is going to be long and dry.
The game is responsible for:

• Keeping track of where every character is in tile coordinates. If you want to go more in depth on the coordinates, read this.
• Keeping track of the statistics, attributes, abilities, and skills of each character and making sure nothing against the rules happens.
• AI.
• Event tracking (progress on a quest etc.).
• Loading map data, save data, etc.
• Generally managing the campaign.
• Sending relevant data to the graphics (the coordinates of each character, what the player can see currently, menu options, etc.)

The graphics are responsible for:

• Displaying characters and critters and tiles and effects and crap to the screen.
• Managing user input (the player clicked on this button, etc.) and telling the game what action the player is trying to do.
• Managing the camera
• Loading and unloading art, etc.
• Unloading maps and data and crap that were sent to it from the game.

So let's go through a turn of battle:

• Game to graphics "It's John the PC's turn, awaiting input"
• Graphics centers on John the PC
• Player clicks on move
• Graphics tells game "The player wants to move"
• Game decides that that's legal (John the PC isn't paralyzed or anything)
• Game to graphics "That's fine, the player can select any one of these tiles (where John the PC can move)"
• Graphics highlights the tiles where John the PC can move
• The player decides he wants John the PC to move outside of his range, clicks on a tile that is outside of the list of tiles that the game sent to the graphics
• Graphics to game "He selected this tile here"
• Game decides that that tile wasn't an option, doesn't change John the PCs coordinates
• Game to graphics "Not gonna happen, try again"
• Graphics tells the player he's an idiot and to try again
• The player chooses a tile that is on the list of tiles that the game sent the graphics
• Graphics to game "He selected this tile here"
• The game decides that's just dandy, walks John the PC to the selected tile.
• Game to graphics "Here's an update on the situation: John the PC has moved through these tiles and currently resides here, and John the PC can see this, that, the other thing, and Tom the Monster. Here's what you need to know about Tom the Monster (he looks like this, his name is Tom the Monster, he's on this tile, etc., etc.)"
• Graphics shows a little animation of John the PC walking through the tiles he moved to, changes what the player can see, shows this, that, the other thing, and Tom the Monster lurking in the darkness
• The player decides he wants to go after Tom the Monster, decides to open his spellbook
• Graphics to game "What are John the PC's spells?"
• Game to graphics "These are his currently available spells"
• Graphics shows a menu or whatever of all of John the PC's spells
• John the PC clicks on Spaceballs the Spell
• Graphics tells game "He wants to cast Spaceballs the Spell"
• Game decides that that's just fine, reads up on Spaceballs the spell
• Game to graphics "That's fine, he can choose Billy the NPC or Tom the Monster"
• Graphics highlights Billy the NPC and Tom the Monster
• The player clicks on Tom the Monster
• Graphics to game "He chose Tom the Monster"
• Game decides that's OK, rolls to see if Spaceballs the Spell hit Tom the Monster. It succeeds. Rolls Tom the Monster's Fortitude save to see if it negates the spells effects. Tom the monster fails his Fortitude save.
• Game to Graphics "Spaceballs the Spell hits Tom the Monster"
• Graphics shows a little animation of Spaceballs the Spell hitting Tom the Monster
• Game rolls for damage. It does umpteen Hurty damage, the game decreases Tom the Monster's HP.
• Game to graphics "Tom the Monster takes umpteen Hurty damage"
• Graphics shows a little animation of Tom the Monster taking umpteen Hurty damage
• The player clicks on the "End Turn" button
• Graphics to game "John the PC ends his turn"
• Game to graphics "It's now Tom the Monster's turn"
• Graphics centers the camera on Tom the Monster
• Game decides that Tom the Monster wants to run up to John the PC, does pathfinding, etc.
• Game to graphics "Tom the Monster runs through these tiles and ends up here"
• Graphics show a little animation of Tom the Monster running through the tiles
• Game decides that Tom the Monster wants to break John the PC's face, rolls to see if Tom the monster hits. He misses.
• Game to graphics "Tom the Monster tries to break John the PC's face, but misses"
• Graphics shows a little animation of Tom the Monster trying to break John the PC's face, and John the PC dodging the attack.
• Game decides that Tom the Monster is done with his turn.
• Game to graphics "It's now Billy the NPC's turn"
• Game decides that Billy the NPC should run over somewhere out of sight of John the PC
• Game to graphics "Billy the NPC runs through these few tiles, and then disappears out of the sight of John the PC"
• Graphics shows an animation of Billy the NPC running through a few tiles, then disappearing
• Game decides that Billy the NPC wants to blotterize his kajiggers. Since Billy is out of sight of the player, it doesn't tell graphics.
• Game decides that Billy the NPC's turn is over.
• Game to graphics "It's now John the PC's turn"

 

[temp02]

The same basic logic/math still applies, you just ditch one of the coordinates.

Also you seem to be joining both game output (display) and user input. Both should be separated "components". Parsing user input should be just a layer on top of the already coded game actions for lets say a bot, the same applies for the game output.
bot:

move to this tile;
no can do;
bot selects another tile;
move there then;
ok, bot moved;

player:

[color=blue]player clicks on x,y;
translate coordinate to tile;[/color]
move to this tile;
no can do;
[color=blue]print "stupid" on screen;[/color]
player selects another tile;
[color=blue]player clicks on x,y;
translate coordinate to tile;[/color]
move here instead then;
ok, player moved;
[color=blue]print "you moved";[/color]

What I'm trying to say is, create procedures for each action on the game, taking actors (such as player, be it a bot or human, and tiles or coordinates) so that if you need to add extra functionality or modify the existing one you just need to override the existing functions.
What would happen if you decided to introduce a framework like SLD into the mix to replace your "graphics" core, would you need to change the interface of the game core? (you shouldn't have too)

Now, if you are referring to IPC for passing information between game/engine components my advice would be to use none (except for critical sections and synchronization ofc). It would require you to create a protocol, and all the extra code would introduce no improvement (except for Sockets that if used properly could make your game playable on a remote client, just like X11).
Just make your engine run at a certain rate, the user input should make "hard calls" to a input queuing system that is visited on each iteration by the core, and the visual/audio part of the game should just "ask" the core what to render as fast as it can and nothing more (apart from storing animation time/frame ofc).

 

[SaltyFish]

Somebody else working on a turn-based hexagonal grid RPG? Oh snap!

At its heart, it's really just the game portion. It could be contained entirely as a text based game like many earlier PC games. The graphics is just a user interface and embellishment. What you're trying to think of as "Managing user input (the player clicked on this button, etc.) and telling the game what action the player is trying to do" is mostly a "GetCursorPosition()" call and comparing the results with other visual elements (both the menus and the game world).

• Game engine reads first entry in turn queue. It finds out it is John the PC and tells the graphics to center the camera on him.
• Graphics engine centers camera on John the PC.
• The game checks what actions are valid for John the PC, if any.
• The game tells the graphics to generate an action menu pertaining to John the PC and gray out any invalid options. This menu can be worked by keyboard, but I'm going to assume you want mouse cursor interactivity.
• Player mouses over the "Move" button and clicks it. Here you will need to check the mouse cursor position and compare it with the location of the menu buttons. For easy checking of this, you might want to give your buttons a glow when they're moused over.
• If the action is invalid (already grayed out, but the player clicked it anyway). The game either ignores it or returns a message stating why that action is invalid.
• If the action is valid, it proceeds. In this case it's a move command. Game engine runs a call to check for all valid movement locations and tells graphics to highlight them.
• Player clicks on a location. Again, check mouse cursor position and what, if any, hex is selected.
• Check validity of destination hex. Since all legal moves have been highlighted, it's an easy check. If invalid, either ignore or return a message saying it is out of movement range.
• If destination is valid, proceed. Tell graphics to process the object "John the PC" with a walk animation and give it the list of hexes to traverse to make a path to the destination.

You'll notice I've done checks earlier to make the menu more informative and less redundant checking. Also, from what you've described, it seems a bit like Elven Legacy and/or Fantasy Wars (due to the whole sight thing) combined with an character queue-based SRPG (Sacred Blaze, Wind Fantasy 6, Phantom Brave, Final Fantasy Tactics, etc.).

The other thing is to tell the game to wait while the graphics are doing their thing. For example, waiting until the walking is completed before bringing up the action menu again. You could have a fancy cursor following the mouse pointer. But then again, if you can get that working, the rest of this should a breeze.

EDIT:temp02 got it. You're trying to combine the game logic with the graphics display. Do the game logic first. The graphics is just for user (player) convenience. It should reflect that by simply embellishing game actions.

 

[hellrazor]

The same basic logic/math still applies, you just ditch one of the coordinates.

Also you seem to be joining both game output (display) and user input. Both should be separated "components". Parsing user input should be just a layer on top of the already coded game actions for lets say a bot, the same applies for the game output.
bot:

move to this tile;
no can do;
bot selects another tile;
move there then;
ok, bot moved;

player:

[color=blue]player clicks on x,y;
translate coordinate to tile;[/color]
move to this tile;
no can do;
[color=blue]print "stupid" on screen;[/color]
player selects another tile;
[color=blue]player clicks on x,y;
translate coordinate to tile;[/color]
move here instead then;
ok, player moved;
[color=blue]print "you moved";[/color]

What I'm trying to say is, create procedures for each action on the game, taking actors (such as player, be it a bot or human, and tiles or coordinates) so that if you need to add extra functionality or modify the existing one you just need to override the existing functions.

But the game relies on the graphics to draw and create a menu - menus are totally out of the game's domain. So the graphics asks the game "what are some actions John the PC can make?" and the game says "move, attack, cast spell, dance like an idiot, etc." and then the graphics would display that choice to the player however it wants to, probably a menu. So then the graphics would have to manage the mouse and keyboard because the menu (or however it displays the choice) is entirely the graphics' creation. The game doesn't tell the graphics to display a certain menu, or a text box, or whatever - it doesn't ask the question, at best it tells the graphics that it needs a certain kind of input, and the graphics takes care of giving the game what it needs.

What would happen if you decided to introduce a framework like SLD into the mix to replace your "graphics" core, would you need to change the interface of the game core? (you shouldn't have too)

No, it shouldn't. That's why I'm trying to make the graphics handle the user input, so that the graphics can handle it however it needs to. An SDL graphics portion could make menus that are like Neverwinter Nights' radial menus, an ncurses one could just print off the options in a sub-window and tell the player to choose a number that correspond to that option. The game doesn't care how the questions are asked.

Now, if you are referring to IPC for passing information between game/engine components my advice would be to use none (except for critical sections and synchronization ofc). It would require you to create a protocol, and all the extra code would introduce no improvement (except for Sockets that if used properly could make your game playable on a remote client, just like X11).
Just make your engine run at a certain rate, the user input should make "hard calls" to a input queuing system that is visited on each iteration by the core, and the visual/audio part of the game should just "ask" the core what to render as fast as it can and nothing more (apart from storing animation time/frame ofc).

The improvement that it would introduce is abstraction. I could write a million different graphics portions for it and as long as they can interact correctly with the protocol it doesn't (shouldn't) matter which one you want to use - and that's what I'm going for, because I'm quite inexperienced with a lot of graphics libraries and if I want to learn SFML I could just write a graphics portion using that and *bam* I already have a working game for it. Easy, peasy. Maybe some other week I want to dabble in some OpenGL, all I'd have to do is write enough to get it to interact with the game correctly and all of a sudden I have a fully functional game to work with.

The other thing is to tell the game to wait while the graphics are doing their thing. For example, waiting until the walking is completed before bringing up the action menu again. You could have a fancy cursor following the mouse pointer. But then again, if you can get that working, the rest of this should a breeze.

Or I could just keep them as seperate processes (or maybe just threads) and make the graphics maintain a queue of the actions. So if the graphics is animating Tom the Monster walking over this way, the game doesn't have to wait for anything (since it already knew where Tom the Monster was long before it told the graphics) and could just start going through the AI. The game only ever really needs to wait for the user because it can't just start running AI for a character the user controls.

EDIT:temp02 got it. You're trying to combine the game logic with the graphics display. Do the game logic first. The graphics is just for user (player) convenience. It should reflect that by simply embellishing game actions.

Yeah, something like that but I don't want to write a whole bunch of game logic if I can't use it because the graphisc isn't giving me a menu to tell the game to run that part of the logic.

I guess maybe I could just write a simple terminal thing to tell me what the game would tell the graphics, and then just write back what the graphics would have told the game or something.

 

[Aquinus]

The improvement that it would introduce is abstraction.

Some things don't need to be abstracted. I think I understand what you're trying to get at. Graphics don't need to be abstract because once you choose a graphics library to handle all of your 3d rendering, it's extremely unlikely that you will need to support a second plug-able renderer.

I think we need to be perfectly clear about one thing: The game computes everything, not the renderer.

The graphics are strictly OUTPUT. The game creates the information that tells the graphics what to put out to the screen. So you look for the user input inside the game and when it comes you have the game update the graphics to change what the user sees, the graphics doesn't work independent of the game. The graphics doesn't handle input or entities as complex as your describing. When anything "happens" in the game, it's not the graphics processing it.

So tell me one thing. If the graphics/render handles the input, how the heck is the game going to know about it?

Yeah, something like that but I don't want to write a whole bunch of game logic if I can't use it because the graphisc isn't giving me a menu to tell the game to run that part of the logic.

I guess maybe I could just write a simple terminal thing to tell me what the game would tell the graphics, and then just write back what the graphics would have told the game or something.

I do not recommend doing this. You need a renderer because you only want to tie up the graphics device when you're ready to render. Prepare everything ahead of time and then tell the Renderer, which knows how to ouput graphics, to do it all at once. This can't be done in parallel (not efficiently if done safely,) where other parts of your program can. By doing them together your obfuscating your code, making it harder to read, and taking more time to render each frame.

 

[librin.so.1]

Yet again, the engine should keep track of everything it needs to run correctly. You should heed Aquinus' advice. What He tells The Good Stuff™.

And to illustrate a little better, to what degree the engine should handle&track things:
Imagine all the graphics/drawing functions are stubs. The engine should still be able to track and handle enough things, that playing such a "blind" game would be possible - everything's running correctly and the engine handles the input on the [empty] game screen according to where the things should be it they were drawn.

 

[hellrazor]

Some things don't need to be abstracted. I think I understand what you're trying to get at. Graphics don't need to be abstract because once you choose a graphics library to handle all of your 3d rendering, it's extremely unlikely that you will need to support a second plug-able renderer.

But that's what I'm trying to do! I want to be able to write a renderer and have an entire game pre-built so I don't have to rewrite loading and saving and keeping track of characters and AI and game rules and crap every time I want to learn a graphics library. All I have to do is get it to play nice between the player and the game and *voila!* I have an SDL or OpenGL or SFML or ncurses interface for a game that's already been built. And look here, since the game doesn't get changed even my saves are still valid!

I think we need to be perfectly clear about one thing: The game computes everything, not the renderer.

The game's job is gameplay and nothing else. The graphics' job is interfacing with the player and nothing else. Menus and windows and buttons are interfaces, not gameplay - so what do they fall under? Graphics.

The graphics are strictly OUTPUT. The game creates the information that tells the graphics what to put out to the screen. So you look for the user input inside the game and when it comes you have the game update the graphics to change what the user sees, the graphics doesn't work independent of the game. The graphics doesn't handle input or entities as complex as your describing.

Wrong. The game tells the graphics what kind of input it needs (usually "What is John the PC going to do this turn?") the graphics is then responsible for making sure that it can provide that input to the game. The game does not ask "where is the mouse?" because it is totally irrelevant to the characters or rules in the game.

So tell me one thing. If the graphics/render handles the input, how the heck is the game going to know about it?

That's the graphics' job. To create and manage interfaces, and then to tell the game what the player wants John the PC to do.

I do not recommend doing this. You need a renderer because you only want to tie up the graphics device when you're ready to render. Prepare everything ahead of time and then tell the Renderer, which knows how to ouput graphics, to do it all at once. This can't be done in parallel (not efficiently if done safely,) where other parts of your program can. By doing them together your obfuscating your code, making it harder to read, and taking more time to render each frame.

The graphics maintains a queue of all rendering information that is needed during that turn. It draws what the game tells it is going on. If the game says Tom the Monster walks over to this tile, the graphics does whatever it wants to to display Tom the Monster walking over to that tile. If the game tells the graphics a whole load of actions, the graphics keeps them in a queue and deals with them in order. The graphics prepares everything and worries about what's being drawn.

And to illustrate a little better, to what degree the engine should handle&track things:
Imagine all the graphics/drawing functions are stubs. The engine should still be able to track and handle enough things, that playing such a "blind" game would be possible

The game keeps track of characters and their actions, the map (including what random junk is scattered about), the AI, and relevant game-related data operations (like loading and saving game states). The graphics' job is to be an interface between the player and the game. The graphics is the interface, ALL of the interface, and the ONLY interface. The player and his peripherals does not ever communicate with the game. The game does not give a flying shit about the mouse or the keyboard - it wants to know what the player wants John the PC to do, and a mouse does not fall under what the player wants John the PC to do.

everything's running correctly and the engine handles the input on the [empty] game screen according to where the things should be it they were drawn.

Where things are (or should be) drawn is none of the game's concern. The game does gameplay and where a menu is on the screen is not gameplay. Where a character or menu or something is drawn on the screen is purely interface-related information, and graphics is the interface. Therefor the graphics keeps track of menus and where things are drawn.

 

[librin.so.1]

This is how You describe what You need:

Spoiler

And this is the sane way to do it (highly simplified and many things not shown) :

Spoiler

Seriously, man, graphics only draw things, just get over and deal with it.

P.S. I am not sure if I put everything correctly in these graphs, but You should get the idea.

 

[hellrazor]

Honestly, I like the first one better.

 

[librin.so.1]

Honestly, I like the first one better.

Yeah, it does look much more simple
'cept that it isn't and it probably won't work!

FWIW, it is technically possible. But it would be extremely complicated. And I also suspect You would have such a bad performance [methaphor]it would get on a train and ride all the way to the land of "so bad, it's funny.". But would not stop there and go further and then enter into the land of "so bad, it's simply sad."[/methaphor]
You would either have to do most of Your graphics on the CPU, or have ridiculously large amount of crosstalk between the GPU and the CPU, along with introducing MANY stalls in the GPU, and introducing a lot of points for silly bottlenecks.
Did I mention it would be extremely complicated.
I wouldn't be surprised if You have to somehow route a lot of graphics functions as GPGPU functions just to be able to supply the required data to the CPU.

IOW: Don't reinvent the wheel.

 

[hellrazor]

How so? A thread for the interfaces (mouse, keyboard, menus, windows, etc.) and a thread for rendering under the graphics process should be perfect, the two threads could talk to each other incredibly fast because they're both in the same process and the two processes (game and graphics) don't need to talk all that incredibly fast to each other through the pipes because communication between them is few and far between, and any large data can stored in shared memory (the game could tell the graphics what the shmid is through the pipes, and the graphics would be responsible for the memory chunk).

It's perfect.

 

[librin.so.1]

Spoiler

You know what? From what You are telling, You seem to know well enough of what Your game needs. We are no longer needed. Just go and finish Your game...
...When You do, sharing the results would be swell!