Michael Bayne
e5acc3e45f
objects (DSet, arrays) in a DEvent (which should not change as a result of other events being applied) and those in the object itself (which do change and evolve as events are applied to the object). This is important both because the DEvent is passed on to another thread for delivery to remote clients, thus changes to the values in the event could take place before they were serialized and sent over the network, and because compound events are applied to an object before they are sent to the other thread for delivery and thus, for example, setting a DSet and then adding a few entries to it in a compound event would result in the DEvent copy of the DSet becoming corrupted. Two problems remain (note, neither of these are new, the one issue introduced when I rewrote the DObject stuff is fixed by these checkins): 1. Object subscription requests are supposed to deliver a snapshot of the object at the point in the event stream at which the subscription request was processed, but presently we pass only a reference to the object off to the networking thread which means that before the object is serialized and sent to clients, subsequent events could be applied to it and then those events would be sent to the client as well resulting in funny business (probably nothing more than duplicate DSet entry warnings, but imagination and Chapter 17 tell us that worse things could happen). 2. The use of Streamable instances could result in badness. If a field in a Streamable is modified and the whole Streamable set() back into the object to broadcast the update, then further changes were made to the Streamable before the attribute change event was serialized and sent over the network, the second modifications would be reflected in the event triggered by the first modifications. The first problem may be solvable (albeit inefficiently) by serializing the DObject on the event dispatcher thread and sending that serialized copy off to the network thread for delivery to the client. It would be much less efficient as we would be unable to make use of the client's already "primed" ObjectOutputStream which may have already mapped many of the classes in the object to two byte codes, but object subscription is fairly uncommon compared to delivery of events, so inefficiency might not be a big problem in this case. The second problem might be solved by requiring that all Streamable implementations implement clone() and then cloning any Streamable attribute just as we do an array or DSet during an attribute, array element or DSet entry change. This would be a more significant performance hit as well as require a review of all of our Streamable classes (to determine if they need a custom clone() implementation), and it has up to now not actually manifested as a problem. In any case I'm not going to tackle either of these remedies at the moment because I'm on vacation, dammit. git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3294 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 $