Minority Opinions

Not everyone can be mainstream, after all.

Client-Server Solitaire

leave a comment »

I’ve enjoyed quite a few video games, though I my tastes run a bit more esoteric than average.  Recently, I’ve been getting into Dwarf Fortress.  After a significant time on Nethack, and a fair amount on SimCity, the fortress mode has been interesting.  Unfortunately, the interface is terrible.

Perhaps counter-intuitively, I’m not complaining about the ASCII art.  After Nethack, it’s a huge step forward to see so many things that look like what they represent.  Granted, the full Unicode suite could be even more exciting than code page 437, but it takes an interesting direction and pushes it to the max.  It also lets you use graphics, if you’re inclined, though that takes a bit of setup.

Instead, I’m annoyed with the way you use the program.  To look at everything in a location, you need to use several separate menus: k, v, q, t, i, and perhaps something I’m forgetting.  Even that can entirely miss something; there’s absolutely no way to see what a goblin in a cage is holding, except through the big list of absolutely everything on the map.  Frequently, while in one menu, you find yourself needing information only available in another menu, with no easy way to get between the two.  For example, I find myself wanting to know whether a particular piglet is male or female when deciding where to pasture it; there are three ways to get that information, but none of them are accessible from the pen/pasture menu.

Certain situations are so horrible that they have inspired helper programs.  Dwarf Therapist is almost required for any sort of labor management, primarily because it lets you see a dwarf’s skills and set labor preferences on the same screen.  The fact that it shows multiple dwarves at once is pure gravy.  Quickfort helps mitigate some of the busywork involved in making a place livable, but it’s limited to the same interface as the player.  The dfvdig utility bundled with dfhack is invaluable for letting your dwarves take as much as they can find of a certain mineral, instead of watching and designating every step individually.

This has culminated in a desire by certain players for a client-server type of interface, where the main programmer can take complete control over the back end while letting the players use their own front ends.  It’s not a new idea; the same thing was floated for Nethack a while back.  I’ve seen it used successfully for other games, too.  A clean separation of user interface from game logic can make programming maintenance much easier, down the road.  However, it can also be a royal pain in the neck.

I’ve worked on a network game, where each of several players use their own programs, talking to the same central server.  The separation of user interface from game logic was absolutely required, from a security standpoint.  In effect, though, the network API becomes a user interface, from the server’s point of view.  Even more unfortunately, it quickly becomes locked down, lest you break the ability of all old programs to talk to newer servers.

In a single-player game, it feels so much easier to let the interface reach into all the bits of memory it needs.  When the two are bundled together, it seems natural to change each to fit the requirements of the other.  Yes, there’s still an internal interface design, but it’s much more fluid and organic than a network or library API.  This can only be even more true when there is a big pile of information to be passed back and forth; a single model in memory serves much better than trying to set up a mirror model on the other side of a pipe.

Another potential issue arises when running the game.  As an explicit client-server model, you need a pair of programs to run at the same time, with a known communication channel.  There are several ways to do that, but none of them are nearly as convenient as running a single program.  The best alternative, then, is to create the “server” as a shared library, but that limits the front end to a single “client” program, whereas a true server could allow several utilities (or players) to run in parallel.

On the other hand, perhaps the benefits could be worthwhile, particularly for new projects.  Given the tendency of programs to collect alternative front ends for various platforms, a common library encapsulating the logic may help ensure that everyone sees the same game.  Starting with a client-server model may help your game go multiplayer someday.  Perhaps the ability to easily rewrite the back end could help you take advantage of multi-core processors.

Then again, all of my recent projects have been in Python, so what do I care?


Written by eswald

13 Sep 2011 at 9:36 pm

Posted in Technology

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 )

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s