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(a)gmail.com>
wrote:
On Tue, 31 Jan 2023 at 21:32, Will Senn
<will.senn(a)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