[TUHS] Re: Unix game origins - stories similar to Crowther's Adventure

[segaloco via TUHS <tuhs@tuhs.org>]

[-- Attachment #1: Type: text/plain, Size: 3336 bytes --]

In the annals of UNIX gaming, have there ever been notable games that have operated as multiple processes, perhaps using formal IPC or even just pipes or shared files for communication between separate processes (games with networking notwithstanding)?

Reason I ask is I've been thinking about the feasibility of such an architecture, what with perhaps a "system server" process that reads various IPC for messages from a "game" process and then internally translates those into X11 calls, OpenGL, etc. Could even be multiple servers for different concerns (display, audio, input, networking obviously).

This would be similar to a multi-threaded engine except that we're using system processes and IPC rather than threads and synchronization primitives (on some implementations, these may converge pretty heavily). An added benefit I could see would be having the one server running with the ability to arbitrate multiple games through the same pipelines. Think something like SDL but running as a server taking IPC calls to do things instead of just a library being called in the same process space. This is probably a bit more Plan 9-ish that UNIX-ish, but would be an interesting use of the system architecture.

A compelling argument for not doing things this way would be platform lock-in, as sure other operating systems would probably provide similar enough process and IPC mechanisms to achieve the same end result, but no such thing would exist on the preponderance of embedded platforms running no OS, such as cartridge-based consoles. Still, I could see such an architecture begetting clean separation of system interfacing from game logic which would then lend itself well to library-ization of the system server part in embedded cases where it has to be directly entered rather than IPC'd to from yonder process. There is then of course the performance hit of communicating between the different components via IPC rather than it all being self-contained, but as we all know, an increase in maintainability and code clarity sometimes makes a little performance and/or size hit worth it.

Anyone know of anyone doing this back before id, Unreal, and Unity cornered the game engine market?

- Matt G.
------- Original Message -------
On Wednesday, February 1st, 2023 at 9:52 AM, Henry Bent <henry.r.bent@gmail.com> wrote:

> On Tue, 31 Jan 2023 at 21:32, Will Senn <will.senn@gmail.com> wrote:
>
>> All,
>>
>> I just saw this over on dragonflydigest.com:
>>
>> https://0j2zj3i75g.unbox.ifarchive.org/0j2zj3i75g/Article.html
>>
>> It's an article from 2007 about the history and genesis of the Colossal Cave Adventure game - replete with lots of pics. What I found fascinating was that the game is based on the author's actual cave explorations vis a vis the real Colossal Cave. Gives you a whole new appreciation for the game.
>
> My uncle, Richard Zopf, did extensive exploration of Mammoth Cave with Will Crowther. My understanding is that Colossal Cave was truly impressive in its ability to replicate the real situations that the cavers faced, especially given the limitations of the storage and processing abilities of the machines at the time. To my mind this stands well apart from the more rudimentary early computer games which were very math/logic driven vs. the concept of an "open world" exploration.
>
> -Henry

[-- Attachment #2: Type: text/html, Size: 5123 bytes --]