Re: Plugging in Sockets
William Taysom <[email protected]>
| Newsgroups | gmane.comp.breve |
|---|---|
| Message-ID | <[email protected]> |
Steve wrappers for something like SmallSockets: http://smallsockets.sourceforge.net/ would be ideal. I imagine a Breve simulation in which objects can be controlled remotely (perhaps responding when their iterate method is called). One might enable the Controller to make socket connections or be a server for connections. As a fun example, set up a breve server simulation a computer. Then allow other breve client simulations to connect to the server (either on the same computer or a different one). The server communicates state information to the clients which interpret this information in any way they see fit. Have the client send some messages back to the server, like, I don't know, which keys are being pressed in the client simulation. Use that info to control the velocity of objects on the server. Send info on the general location of objects back to the client. Have the client interpret that information in space. Add guns and explosions. Call the thing "UnBreve 2004!" - OR - For something a little more original, begin with an average a-life simulation Breve style. You can have that simulation host connections and also connect to other simulations which are already running. Connecting creates a little black sphere in the simulated world. For lack of a better name, lets call it a "worm hole". If a Mobile "accidentally" wanders into said worm hole, it is serialized, sent across the socket connection to the other simulation, and removed from the original simulation. On the far side of the socket, the Mobile is de-serialized into the simulated world. -- This would be a great way to send living Mobiles to friends! - OR - If one is truly ambitious, one might take the above mentioned scenario and add a few things. Simulation environments might provide constraints on the number and kind of Mobiles that it supports. If a Mobile does not meet the requirements, it will be freed. It's resources reclaimed. From there, one might add a parameterization of the shape and behavior to Mobiles -- call it a phenome if you will. Interacting with other Mobiles or Stationaries could affect the phenome of a mobile. Including a case where one of the mobiles is freed after the interaction. We might say that the free mobile was "eaten." Mobiles might also include parameters which are specified at creation. One might call such parameters a genome. There might be a protocol which allows a new a mobile to be added to the simulation based on genome of another Mobile which is already in the simulation. In addition, there might be protocols though which the genomes of two Mobiles can be crossed to produce a new Mobile with a somewhat different genome. One might call a protocol of this kind "sex." Regardless of what one does with the sockets, making it easy to set up connections could be a very good thing for Breve. Just some thoughts, William On Jan 27, 2004, at 10:42 AM, jon klein wrote: > > On Jan 26, 2004, at 9:11 PM, William Taysom wrote: > >> Dear Brevers, >> >> I am curious to know if any of you have worked on adding support for >> socket communications within Breve. I've noticed that there is >> already some support for accessing URLs. We have been looking for a >> simulation engine for several applications (think remote controlled >> Navy bots) and after looking at a number of possibilities (including >> the Quake and Unreal engines), we believe Breve would be ideal for >> the task given it's simplicity, portability, and ease of use. The >> only thing Breve seems to be missing is Sockets. So if any of you >> have already looked into this, we would be interested in knowing what >> you've found. > > I know that this has been done a number of times for proprietary > applications, but I don't know that anybody has made a general-purpose > socket class. > > A fair amount of socket-related code already exists in breve, so > working it into a general-purpose class shouldn't be too difficult. > If you let me know what kind of features you'll need, I'd be happy to > add some basic socket support to the next version. > > - jon klein > > _______________________________________________ > breve mailing list > [email protected] > http://www.spiderland.org/mailman/listinfo/breve _______________________________________________ breve mailing list [email protected] http://www.spiderland.org/mailman/listinfo/breve