Michael Bayne
03dab36e3e
queue up an invoker unit which would go off and do some database stuff and then by the time it came back and was ready to publish its results to a distributed object, the object in question would have been destroyed for any of a variety of fairly natural reasons (client disconnected or logged off, game was abandoned, dog ate homework). One "solution" to this problem would be to litter our games' code with thousands of calls to isActive() in the handleResult() methods of our invoker units. We've done a bit of that in Yohoho but I've resisted starting down that path in our other games. Another solution would be to create an Invoker.Unit wrapper that takes a reference to the distributed object (or objects) that it will be modifying and have the common unit code check that the object(s) in question are still alive at the end of the asynchronous operation and not call handleResult() if they are not. This has numerous problems: what do you do if one object is alive but not another, how do you incorporate this functionality in with the numerous other Invoker.Unit derivations we have that simplify our lives in other ways (without getting crazy and starting to use something like AOP), do you silently abort the operation or log something? So instead, I've come around to the idea that this is simply a dirty fact of life in asynchronous programming and the fact that we can accept modifications to distributed state after the distribted object in question is dead is a good thing. We used to log a warning every time this happened and freak out even more substantially if one tried to start a transaction on a dead object. Now we will simply log an informational message (I don't think this sort of thing should be silently ignored because there are some cases where it is an indication of incorrect code, those are simply more rare). We will also allow a transaction to be started on a dead object and when the transaction is committed, all the events involved will be dropped just like a single modification would have been dropped on that object. This allows the most sensible thing to happen which is any results that are published to still live objects will actually be published and results published to dead objects will be dropped without making a big fuss. Since a dead object by definition cannot have subscribers, no one could possibly have cared about the dropped events anyway. Also widened. git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4545 542714f4-19e9-0310-aa3c-eee0fc999fb1
The Narya library
-----------------
The Narya library provides various facilities for making networked
multiplayer games. It's various packages include:
* geom, util, io - basic tools for doing networked I/O, data structure
manipulation and some geometry math
* resource - tools for bundling, deploying and managing media (images,
sounds, etc.) with a game
* media - a framework for doing "active" rendering in Java
* media.image - tools for loading, caching, manipulating and displaying images
* media.sound - tools for loading, caching, and playing audio
* media.animation, media.sprite - works in concert with the active
rendering system and provides tools for defining and manipulating
sprites (graphical entities that follow paths) and animations
(graphical entities that affect the display in other ways)
* miso - a framework for defining and displaying isometrically rendered scenes
* presents - a framework for distributing information among a server and
networked clients
* crowd - builds on the presents framework to create the notion of
bodies and rooms and provides chat infrastructure
* whirled - builds on the crowd framework and defines a scene graph with
portals to move between scenes and provides hooks for distributing and
updating scene data (for example isometric rendering information) over
the network
* cast - a framework for defining and using recolorable, composited
characters with different poses and actions
* parlor - builds upon the crowd framework to create the notion of a
game with players and provides tools for making turn based games
* puzzle - builds on the parlor and media frameworks to provide tools
for implementing puzzle games in a networked environment
* micasa - builds on the parlor framework to provide lobbies and
matchmaking for multiplayer games
Documentation is somewhat sparse at the moment, but inspection of the code
in the tests/ directory shows examples of use of many features of the
library.
Building
--------
Building the library is very simple. First ensure that the necessary third
party jar files are available either in the lib/ directory or in the
system wide jar file location specified in build.xml. See lib/README for a
list of the necessary third party jar files and how to get them.
The library is built using ant, a modern build tool available from The
Jakarta Project. If you aren't already using ant for other projects, it
can be found here:
http://jakarta.apache.org/ant/
Invoke ant with any of the following targets:
all: builds the distribution files and javadoc documentation
compile: builds only the class files (dist/classes)
javadoc: builds only the javadoc documentation (dist/docs)
dist: builds the distribution jar files (dist/*.jar)
Distribution
------------
The Narya library is released under the LGPL. The most recent version of
the library is available here:
http://www.threerings.net/code/narya/
Contribution
------------
Contributions to Narya are welcome. Control of the CVS repository is
presently in the hands of mdb@threerings.net, who should be emailed about
submissions. Soon we will be migrating to Subversion and making the
repository publicly accessible. For now, source releases are available at
the above website.
Contact Information
-------------------
Narya is actively developed by the scurvy dogs at Three Rings Design,
Inc. Contact Michael Bayne <mdb@threerings.net> with questions, comments
and other wordly endeavors.
$Id: README,v 1.1 2004/08/27 17:44:44 mdb Exp $