1 / 64

Implementing Scheme in a Virtual World

Implementing Scheme in a Virtual World. Lance R. Williams Dept. of Computer Science University of New Mexico. Outline. Introduction to Second Life Motivation (Scientific, Educational, and Artistic) Overview of Scheme Overview of Linden Scripting Language A Heap Consisting of Many Objects

lot
Download Presentation

Implementing Scheme in a Virtual World

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Implementing Scheme in a Virtual World Lance R. Williams Dept. of Computer Science University of New Mexico

  2. Outline • Introduction to Second Life • Motivation (Scientific, Educational, and Artistic) • Overview of Scheme • Overview of Linden Scripting Language • A Heap Consisting of Many Objects • A Heap Implemented as One Object with Many Parts • A Bytecode Compiler for Scheme • Future Work

  3. Second Life • Massive multiplayer online game (MMOG) • At any given time, about 50,000 players are online • Immersive 3D environment where players are represented by avatars

  4. Second Life (contd.) • Objects in the virtual world are subject to a rudimentary physics which includes gravity, transfer of kinetic energy, friction, and inertia • The representation of the virtual landscape and its contents and the simulation of their physics are performed by a network of servers • Views of the virtual world from the vantages of individual avatars are rendered on users’ clients

  5. Second Life (contd.) • Not a game in the conventional sense because it has no explicit goals. • Players interact with each other within a virtual world of their own creation. • Players create objects, e.g., clothing, buildings, vehicles, guns, which they sell to each other for virtual money.

  6. Scientific Motivation • Second Life supports a programming model where a large number of scripts execute in parallel and asynchronously. • Communication between scripts is by means of message passing. • Large distributed computations can be implemented and visualized

  7. Scientific Motivation (contd.) Second Life is an ideal testbed for exploring: • Parallel algorithms • Distributed sensor networks • Swarm robotics • Emergent behavior and self-organization • Self-replicating machines • Artificial intelligence • Artificial life

  8. Educational Motivation • The use of virtual environments in teaching is most useful when immersion in an actual environment is impractical. • Teaching in a virtual environment for its own sake makes little sense.

  9. Educational Motivation (contd.) • Second Life is unique among MMOG’s because the players themselves create the content of the virtual world they inhabit (at least partly) by means of computer programming. • Second Life is especially well suited to teaching computer science because inside the virtual world, algorithms and data structures are reified.

  10. Artistic Motivation • In almost all interdisciplinary work, methods from computer science are applied to help solve a problem important in the other discipline. • Methods from other disciplines are rarely applied to solve problems in computer science.

  11. Artistic Motivation (contd.) • The use of computers in the creation of art is widespread. • However, there is a lack of art which explores ideas from computer science itself.

  12. Scheme • A small and elegant dialect of Lisp developed by Sussman and Steele in 1975. • Programs are represented as lists • Lexically scoped • Dynamically typed • Functions are first-class • Optimization of tail recursion

  13. Functional Programming • Programming without side effects or mutation • No assignment or variables • Programs are definitions of the solutions to problems not sequences of statements which transform state • Scheme is good for functional programming because functions are first-class and tail recursion is optimized

  14. Fibonacci Series in Scheme 21 (define fib (lambda (n) (if (< n 2) n (+ (fib (- n 1)) (fib (- n 2)))))) 13 3 2 5 8 35

  15. Building in Second Life • Objects are constructed from elemental shapes called prims • Basic prims include cubes, spheres, cones, cylinders, prisms, pyramids, and torii • A much richer set of elemental shapes can be derived by transforming basic prims via scaling, clipping, twisting, drilling, etc. • Composite objects can be assembled by grouping multiple prims into linksets

  16. Scripting in Second Life • Behaviors beyond those due to simple physics are achieved by adding scripts to objects • Scripts are small programs written in Linden Scripting Language • Scripts are compiled by the client • Scripts are executed asynchronously and in parallel on the server • Scripted objects communicate with each other and with avatars via message passing

  17. Linden Scripting Language (LSL) • An object is composed of one or more prims • A prim can contain one or more scripts • A script is composed of one or more states • A state is composed of one or more event handlers • Event handlers are code fragments which specify how a script will respond to an event in a given state

  18. LSL (contd.) • Examples of events include state_entry(), touch_start(), listen(), timer(), on_rez(), and money() • Event handlers can contain calls to both user defined functions and to functions from a standard library • Examples of library functions include, llGetPos(), llSay(), llRezObject(),llGiveInventory(), and llGiveMoney()

  19. LSL (contd.) • In most other ways, LSL is pretty ordinary • Its syntax, operators, and control structures are similar to C • Standard datatypes including integer, float, and string • Specialized datatypes include vector for representing positions and velocities in 3D, and rotation

  20. Limitations of LSL • No pointers, mutable arrays, or structures • Scripts must run within 16K of space including stack, heap, and bytecode • A non-homogeneous list datatype is provided, but lists cannot contain lists • No function pointers

  21. Limitations of LSL (contd.) • Calls to some library functions, e.g.,llSetPrimitiveParams(), result in deliberate delays, e.g., by 0.2 second, of the calling script • Excessive use of other library functions, e.g., llRezObject(), can result in silent failure • These limitations combat lag and act as a grey goo fence

  22. Elevator This script moves the prim which contains it (and any avatar which happens to be sitting on it) up one meter each time the prim is touched: default { touch_start(integer count) { llSetPos(llGetPos( ) + <0,0,1>); } }

  23. Red-Green This script toggles between two states. In the default state, the color of the prim containing the script is set to red. default { state_entry( ) { llSetColor(<1,0,0>); } touch_start(integer count) { state green; } }

  24. Red-Green (contd.) In the green state, the color of the prim containing the prim is set to green. state green { state_entry( ) { llSetColor(<0,1,0>); } touch_start(integer count) { state default; } }

  25. Interprocess Communication • Between scripts in different objects on an open channel using the llSay() function to send and listen() to receive • Between scripts in prims within the same object on a private channel using the llMessageLinked() function to send and link_message() to receive

  26. Actor model • A model of concurrent computation developed by Hewitt in ‘73 • An actor is a process • Actors execute asynchronously and in parallel • An actor can send/receive messages to/from other actors • An actor can create new actors • LSL is an implementation of the Actor model

  27. Scheme Interpreter • The interpreter consists of the parser, evaluator, printer, and garbage collector: parser evaluator printer garbage collector

  28. Scheme Interpreter (contd.) • Each component is a recursive procedure which accesses the heap in dozens of places. • There is no way that a program this complex will run in 16K of memory: heap COLLISION 16K stack bytecode

  29. Big Problem • The parser, evaluator, printer, and garbage collector are recursive processes which access the heap in dozens of places. • There is no way‡ to suspend execution after the llMessageLinked( ) function call and then resume it from inside the link_message( ) event handler. ‡Ironically, this would be easy in Scheme since it has first-class continuations.

  30. A Back Channel • There are many functions in LSL which allow a script to change the attributes of the prim which contains it, e.g.,llSetPrimitiveParams( ), llSetColor( ), llSetPos( ), llSetName( )… • However, there is only one function which returns an attribute of any prim in a linkset, llGetLinkName( ).

  31. A Back Channel (contd.) • llSetName( ) and llGetLinkName( ) can be used to construct a communication channel between a process which cannot be suspended and resumed and objects in the world • This communication channel can be used as the interface for a distributed heap

  32. A Heap Consisting of One Object with Many Parts link_message( ) prim 2…N llMessageLinked( ) llGetLinkName( ) main process prim 1

  33. S-expression Representation 14 bits (car) 32 bit integer 14 bits (cdr) 4 bits (type)

  34. Bytecode Compiler • The evaluator can be replaced by a bytecode compiler and virtual machine: parser bytecode compiler virtual machine printer

  35. Based on compilation model described in Dybvig ‘91 accumulator (acc) environment pointer (env) program counter (pc) evaluation frame stack (frame) argument stack (args) apply argument assign close constant frame halt refer return test Virtual Machine bytecodes

  36. Bytecode Compiler (contd.) (define sqr (lambda (x) (* x x))) COMPILATION {close ((x) . {refer x {argument {refer x {argument {refer * {apply}}}}}}) {assign sqr {halt}}}

  37. Bytecode Compiler (contd.) • Unlike the previous evaluator, the virtual machine is not recursive…so the system stack does not grow • The virtual machine uses its own stack and this can be stored in the distributed heap • This permits much larger programs to be run

  38. A Heap Consisting of Many Objects • The purpose of this entire exercise was to write a distributed implementation of Scheme. • Why not start by distributing the heap among different objects in the world? • One object per s-expression? • Communication via llSay( ) and listen( )?

  39. A Heap Consisting of Many Objects listen( ) [ on_rez( ) ] fish (one of many) llSay( ) [ llRezObject( ) ] llSay( ) listen( ) link_message( ) prim 2 llMessageLinked( ) llGetLinkName( ) ring main process prim 1

  40. S-expression Representation 10 bits (car) 10 bits (car) 32 bit integer 10 bits (cdr) 10 bits (cdr) 10 bits (self) 4 bits (type)

  41. Distributed Virtual Machine • A strategy for distributing the stack and heap among multiple objects has been described • However, the evaluation process itself runs inside of a single object…it is not distributed at all • How can the evaluation process also be distributed?

  42. Continuation Passing Style • Represent the bytecodes of the compiled program as objects • Add a listen( ) event handler to each bytecode object which performs the appropriate transformation of the virtual machine state • Encapsulate the virtual machine state in a message, i.e., a continuation, which is passed from bytecode to bytecode using llSay( )

More Related