Authors: Lawson English, Jeremy Roschelle, and othersFrom: Lawson English <english@primenet.com>
Subject: Re: SOM & OpenDoc Games: Can this be done?
Date: 26 Apr 1996 23:14:02 -0700
Several years ago, I read a quote by the president of the company that
makes Sim City where he said that Maxis would be working to establish
OLE-based protocols for new Sim City-like games.
When I first started reading about OpenDoc, I started to get excited by
the idea of component-based games. I've checked with some of the OpenDoc
gurus at Apple and they have told me that the current version of OpenDoc
allows one to create inter-parts communications extensions that operate
within an order of magnitude of the speed of a C++ V-Table method call.
SOM, I believe, allows for even faster access if you create SOM libraries
to communicated with each other without the overhead of OpenDoc (I
understand that Cyberdog's non-human-interface modules are all SOM parts
instead of OpenDoc parts, so even internet access can be done fast enough
using SOM).
A friend and I have created a company (Newt, Inc) to work on such a concept.
Given the overhead (or relative lack of overhead) of OPenDoc parts
communications, just about ANYTHING in a game could be put into a sperate
part, as long as the method call wasn't in the innermost loop.
Among the more obvious things that you can do with component based games:
*Create flight simulators that are component-based (there is a
DoD-sponsored mailing list that discusses this issue, and other
training-related component simulators, although I don't know how to
subscribe)
*Create Maarthon-like component games where substantial parts of the
rendering engine are components (goggle-parts, anyone?).
*Create Doom/Marathon-like games where just about everything:
characters, maps, rendering engines, map-displays, motion detectors,
vehicles, monsters, travel-methods (magic carpets flight simulators in
Marathon 3, anyone?), dungeon-display, tactical and
strategic AI, plot implemntation, etc.
are OpenDoc parts.
*Etc.
Our immediate goals at Newt include creating a proof-of-concept game, and
our medium-term goals include helping define industry-wide (Maxis was
talking totally proprietary!) protocols that would allow
games-parts/components to talk to each other properly.
Our long term goals are based on our forecast that 10-30 years from now,
component-based games will be so mature and sophisticated that they will
form part of a new literary artform.
We foresee a time in the not to distant future when an aspiring "writer"
will grab a bunch of prototype freeware components off of the internet
and start playing around with games concepts. More enhanced/faster
commercial/shareware parts could be licensed/written for the final
version, but the freeware versions would be enough to create a
prototype/proof-of-concept.
Educational, adventure, romantic, mystery, etc., genres could ALL be
combined in innovative and unimaginably fun ways once this concept matures.
Helping create the foundations of The literary artform of the 21st
Century seems like a worthwhile lifetime achievement to moi.
Anyone want to join us?
Marlin Meier <mwm@roadnet.ups.com> wrote:
: In the book "The Essential Distributed Objects Survival Guide"
: there is a picture. The caption says that this is Sim City if
: it were an OpenDoc game. The picture looks like a real city!
: There is no explaination in the text about what they could mean
: but I assume they mean that each building could be an OpenDoc
: part. As could be each street, tree, car, etc.
: What I am wondering is at this point in time could there be a
: city simulation game like this? I think there could, but to go
: further, could each indivual building actually exist on a server
: on the internet so that you could enter a building and there
: incounter other people, enteract, etc.
: There was a science fiction book call "Snow Crash" that had an
: internet world like this. A lot of the action in the story took
: place in this world.
: So what do the OpenDoc, CORBA experts think. Could this be done
: now? If not, why? What more would need to be done to make this
: possible?
: Marlin Meier
--
-------------------------------------------------------------------------------
Lawson English __ __ ____ ___ ___ ____
english@primenet.com /__)/__) / / / / /_ /\ / /_ /
/ / \ / / / / /__ / \/ /___ /
-------------------------------------------------------------------------------From: jeremy@soe.berkeley.edu (Jeremy Roschelle)
Subject: Re: SOM & OpenDoc Games: Can this be done?
Date: Sun, 28 Apr 1996 10:23:20 -0800
In article <4lsdva$8gm@nnrp1.news.primenet.com>, Lawson English
<english@primenet.com> wrote:
>Several years ago, I read a quote by the president of the company that
>makes Sim City where he said that Maxis would be working to establish
>OLE-based protocols for new Sim City-like games.
To the best of my knowledge, Maxis is still working on this at the San
Mateo research outfit.
>When I first started reading about OpenDoc, I started to get excited by
>the idea of component-based games. I've checked with some of the OpenDoc
>gurus at Apple and they have told me that the current version of OpenDoc
>allows one to create inter-parts communications extensions that operate
>within an order of magnitude of the speed of a C++ V-Table method call.
>
>
>SOM, I believe, allows for even faster access if you create SOM libraries
>to communicated with each other without the overhead of OpenDoc (I
>understand that Cyberdog's non-human-interface modules are all SOM parts
>instead of OpenDoc parts, so even internet access can be done fast enough
>using SOM).
A bit of confusion here. There is no difference between an ODExtension and
a SOM library. They both work the same way; ODExtension is a class
packaged in SOM.
Yes, you can have communication at the speed of normal v-table dispatch.
My colleagues and I have written some educational simulations already that
simultaneously update a moving particle, a digital meter, a graph, and
vector controllers. Each is in a separate part, and the viewers view the
current (dynamic) state of teh particle. There is no problem with speed --
CopyBits is orders of magnitude more expensive than any communication
operation we do.
>A friend and I have created a company (Newt, Inc) to work on such a concept.
Cool!
>Anyone want to join us?
Keep me posted, especially if you games have educational applications
(like SimCity!)
jeremy
http://www.slip.net/~jeremy
From: st942593@pip.cc.brandeis.edu (Cpt Kangarooski)
Subject: Re: SOM & OpenDoc Games: Can this be done?
Date: Tue, 30 Apr 1996 21:09:43 -0400
In article <4lsdva$8gm@nnrp1.news.primenet.com>, Lawson English
<english@primenet.com> wrote:
-Several years ago, I read a quote by the president of the company that
-makes Sim City where he said that Maxis would be working to establish
-OLE-based protocols for new Sim City-like games.
-
-When I first started reading about OpenDoc, I started to get excited by
-the idea of component-based games. I've checked with some of the OpenDoc
-gurus at Apple and they have told me that the current version of OpenDoc
-allows one to create inter-parts communications extensions that operate
-within an order of magnitude of the speed of a C++ V-Table method call.
-
-
-SOM, I believe, allows for even faster access if you create SOM libraries
-to communicated with each other without the overhead of OpenDoc (I
-understand that Cyberdog's non-human-interface modules are all SOM parts
-instead of OpenDoc parts, so even internet access can be done fast enough
-using SOM).
-
-A friend and I have created a company (Newt, Inc) to work on such a concept.
-
-Given the overhead (or relative lack of overhead) of OPenDoc parts
-communications, just about ANYTHING in a game could be put into a sperate
-part, as long as the method call wasn't in the innermost loop.
-
-Among the more obvious things that you can do with component based games:
-
-*Create flight simulators that are component-based (there is a
-DoD-sponsored mailing list that discusses this issue, and other
-training-related component simulators, although I don't know how to
-subscribe)
-
-*Create Maarthon-like component games where substantial parts of the
-rendering engine are components (goggle-parts, anyone?).
-
-*Create Doom/Marathon-like games where just about everything:
-
- characters, maps, rendering engines, map-displays, motion detectors,
- vehicles, monsters, travel-methods (magic carpets flight simulators in
- Marathon 3, anyone?), dungeon-display, tactical and
- strategic AI, plot implemntation, etc.
-
-are OpenDoc parts.
-
-*Etc.
-
-
-
-Our immediate goals at Newt include creating a proof-of-concept game, and
-our medium-term goals include helping define industry-wide (Maxis was
-talking totally proprietary!) protocols that would allow
-games-parts/components to talk to each other properly.
-
-Our long term goals are based on our forecast that 10-30 years from now,
-component-based games will be so mature and sophisticated that they will
-form part of a new literary artform.
-
-
-We foresee a time in the not to distant future when an aspiring "writer"
-will grab a bunch of prototype freeware components off of the internet
-and start playing around with games concepts. More enhanced/faster
-commercial/shareware parts could be licensed/written for the final
-version, but the freeware versions would be enough to create a
-prototype/proof-of-concept.
-
-Educational, adventure, romantic, mystery, etc., genres could ALL be
-combined in innovative and unimaginably fun ways once this concept matures.
-
-
-Helping create the foundations of The literary artform of the 21st
-Century seems like a worthwhile lifetime achievement to moi.
-
-Anyone want to join us?
sounds quite interesting. let me address it on two fronts.
front the first
---------------
Its a VERY good idea, using OpenDoc parts as game parts... one I hadn't
considered, despite working on a game myself, where we're using components
and a "microkernel" application to keep track of everything. Since we're
still in quite early stages of programming, I'll have to let the
programmers know that this might be unnecessary. Time is not a great
concern of course... we're looking at a number of years as is.
As an aside, heres an idea for a net browser that I don't especially mind
sharing, as it's slated as a possible thing AFTER the damned game. A
browser where each html tag is a part... really this is more of a plug-in
approach to things, but it would finally allow a browser to do just what
you wanted (for instance I loathe <META> and <BLINK>. sadly, theres little
I can do about them.)
front the second
----------------
I hate to say this... but games are probably not going to be a literary
medium of any class for quite a while. Not because of technical reasons
really (although one plays into that) but for human ones. My game has the
B-Tree from hell, for decision making, and tends to be cruely recursive,
branches in large numbers (at least as high as twelve), and working around
this is prooving a large stumbling point. But it has revealed that WRITING
the thing (my job) is a hell of alot harder than writing a book, or play
or poem. storytelling as a dry linear thing is considerably easier... just
keeping track of all the parallel threads is killing me...
now interactive storytelling isnt new though. really NONinteractive
storytelling is. In an oral society, the audience would provide instant
feedback. But when youre removed from the audience (consider real RPGS and
computer RPGS) severe limitations arise. You can't completely veer off in
new and unexplored directions, even if that's what your audience wants...
text games were alot closer to this... you could TRY to do things (Who did
wierd stuff in Sierra's games that still had the wonderful parser? who got
funny responses?). In fact, with text, you often COULD be totally
nonlinear, as any moron who can program can usually describe the twisty
little passages all different. Graphics, Video and animation all hinder
this. Sadly, you can't sell text anymore (which isn't stopping me from
also including a text version). someday there'll be a storytelling AI that
can accept wierd things by the players, and that can spontaneously create
settings. Plots, I expect, will remain outside of its grasp, but hopefully
there'll be a library of plots from it to pick appropriate things...
Anyhow, don't let me stop you. I pride myself on holding lots of
contradictory ideas and positions at once... which is why I'm trying, with
my game, to show that games ARE a good method for storytelling, just as
good as tv, books, plays, poetry, song, and comics. which have mostly had
problems with acceptance in the past too (studying literature, you'd be
suprised that prose is now dominant, and poetry no longer considered THE
main way of telling things. funny, huh?)
in any case, it certainly sounds neat. lemme know, as things happen, eh?
-cpt kangarooski
-CGS
-st942593@pip.cc.brandeis.edu
-<*>
From: VanCLy@ix.netcom.com (Van Chinh Ly)
Subject: Re: SOM & OpenDoc Games: Can this be done?
Date: 27 Apr 1996 06:20:21 GMT
In <4lqkcp$8q@news.roadnet.ups.com>, mwm@roadnet.ups.com (Marlin Meier) writes:
>In the book "The Essential Distributed Objects Survival Guide"
>there is a picture. The caption says that this is Sim City if
>it were an OpenDoc game. The picture looks like a real city!
>There is no explaination in the text about what they could mean
>but I assume they mean that each building could be an OpenDoc
>part. As could be each street, tree, car, etc.
>
>What I am wondering is at this point in time could there be a
>city simulation game like this? I think there could, but to go
>further, could each indivual building actually exist on a server
>on the internet so that you could enter a building and there
>incounter other people, enteract, etc.
>
>...
>
>So what do the OpenDoc, CORBA experts think. Could this be done
>now? If not, why? What more would need to be done to make this
>possible?
>
>Marlin Meier
>
Yeah. It's possible. Each building or structure can essentially
be a part. They probably won't be overlapped, though--more like
adjacent. And I think, at this point, the performance may not be
very good.
Come to think of it, it should not be difficult to do at all, but
performance is another thing, though.
Van
p.s. I am not an OpenDoc or CORBA expert; I am reading the same
book this very moment. :)