0

I've got a project to create a that in some way abstracts the UI from the engine and the engine from map creation, line-of-site, etc. To narrow the focus, i first want to just get the UI (player's client) and engine working.

My current idea is to make the client basically a program that decides what one character (player, monsters) will do for its turn and waits until it can move again. So each monster has a client, and so does the player. The player's client prints the map, waits for input, sends it to the engine, and tells the player what happened. The monster's client does the same except without printing the map and using AI instead of keyboard input.

Before i go any futher, if this seems somehow an obfuscated way of doing things, my goal is to learn, not write a roguelike. It's the journy, not the destination.

And so i need to choose what form of fits this model best.

  1. My first attempt used pipes because they're simplest and i wrote a UI for the player and a program to pipe in instructions such as where to put the map and player. While this works, it only allows one client--communicating through stdin and out.
  2. I've thought about making the engine a daemon that looks in a spool where clients, when started, create unique-per-client temp files to give instructions to the engine and recieve feedback.
  3. Lastly, i've done a little introductory programing with sockets. They seem like they might be the way to go, and would allow the game to perhaps someday be run over a net. I'd like to, if possible, use a simpler solution, and since i'm unfamiliar with them, it's more error prone.
  4. I'm always open to suggestions.
SplinterOfChaos
  • 469
  • 3
  • 12
  • Having each monster use a client makes your work harder, what benefits do you expect from this approach ? – tomdemuyt Feb 13 '12 at 16:39
  • I expect to learn how to do it. I also expect to have fun doing it. If you tell me i'm making it unnecessarily hard for myself, it'd be the same as saying "stop having fun". – SplinterOfChaos Feb 13 '12 at 18:43
  • Good enough, my next question is, what language/platform are you planning to use ? – tomdemuyt Feb 13 '12 at 22:56
  • My home is in C++ but i've recently taken a fondess towards C, which required me to unlearn most of what i was taught about what makes good/bad code. The beauty of this is that each component could be written in a different language, using different libraries, as long as the interface remains the same. To avoid pre-mature optimization, it might be best to use Python for the initial code. I don't have a Windows box so it's linux all the way. BTW, i X-posted to Tigsource and the discussion's much further along there: [tig post](http://forums.tigsource.com/index.php?topic=24364.0) – SplinterOfChaos Feb 14 '12 at 00:13

1 Answers1

0

I've been playing around with using these combinations for a similar problem (multiple clients talking via a single daemon on the local box, with much of the intelligence shoved off into the clients).

  • mmap for sharing large data blobs, with unix domain sockets, messages queues, or named pipes for notification
  • same, but using individual files per blob instead of munging them all together in an mmap
  • same, but without the files or mmap (in other words, more like conventional messaging)

In general I like the idea of breaking things up into separate executables this way -- it certainly makes testing easier, for instance. I think the choice of method comes down to usage patterns -- how large are messages, how persistent does the data in them need to be, can you afford the cost of multiple trips through the network stack for a socket-based message, that sort of thing. The fact that you're sticking to Linux makes things easy in terms of what's available -- you don't need to worry about portability of message queues, for instance.

This one's also applicable: https://stackoverflow.com/a/1428542/1264797

Community
  • 1
  • 1
stevegt
  • 1,644
  • 20
  • 26