SOAP is the packaging, and it is XML. However, the whole content of that xml can be a single string with your message if you want it to be. It is not like you have to build a sophisticated xml or something. Example here
That still doesn't look like the script in a D&D game.
Anyway, if you don't want it, then indeed pipes ... if you want something simple.
The simplist solution that correctly solves a problem is always the best.
You must have a handshake logic(which is basically a client registering into DM) and then a logic for message synchronization like this:
1. client locked in waiting for input
2. server sends current map to client and locks for response
3. client does all internal strategy logic and sends response and locks again
and so on.
(It's been a while since I haven't worked with piped on linux systems
Actually, this is the part i haven't looked into enough. I'm not sure how the executable the player runs will either start the server if it hadn't been already and be the UI. The only difference between the player's client and that of the moster's should be that the player has a UI and no AI (though, both could be hacked in/out) so monster clients should be able to spawn a server equally. Or, i could go the rout of every client not spawned by the server spawns a UI which only draws the screen for NPCs, and accepts input for players then passes that input to the client.
Another solution that actually uses sockets underneath is RPC (remote procedure call). ...
That might be interesting to learn about... Not for this project's current state, but in the future. But it'd be easy to just send a large char holding more or equal to twice the largest (implemented) command.
1. I have heard very good things about http://www.zeromq.org/
. What is neat about that is it is a message passing framework which can be used for IPC or
cross-thread communication or
That looks really, really interesting. I especially love their political diatribe in the introduction: http://zguide.zeromq.org/chapter:all
Does it require that the client and server both use its library? It'd be interesting to write/rewrite DMs and clients in different languages, using different libraries. (That way, i could test it out on a working system instead of building the game around it.)
3. I think the basic thing you're trying to do is not a good idea. I do not understand what you are gaining by separating out these components into actually separate processes. The only advantage I see to this is to create the possibility of some of these components running on different machines. And even this is something that only makes sense in certain limited ways (i.e. allowing players to connect their own entities to the world is neat, but having your own hosted in-game elements be on different machines is pointless). If your goal is to have the different components of the game (engine, maps, line of sight) be abstract and separable, that's great! There are several good ways to accomplish this goal that do not require the abstract elements to be in different processes, and putting them in different processes opens you up to an entire class of concurrency-related bugs that there is no justification for living with in a turn-based rpg.
As i said, the goal is to learn, not to create a rogue. Therefore, it's irrelevant whether i fail or succeed, it's flawless or buggy. Also, the idea that a program should be monolithic, bloated, and do everything is one i cannot get behind. Programs should be small, do their thing, and do it well. They should work together with well-defined interfaces that allow parts to be modifiable and interchangeable without leading to system instability. Not only is this a concept that seems to no longer be taught, but no longer fallowed as many of the programs we use are incredibly bloated, monolithic, and do everything, but nothing well.
But since i was taught to build monolithic programs and games are rarely done in any other way, i thought it'd be a neat experiment. Besides, the features i've been thinking about, like connecting multiple players, are side-effects of doing it this way, not goals.