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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.