Content Development

From Second Life Wiki
Jump to navigation Jump to search

Development Use Cases

If SL actually is going to expand and become something like a 3D web, it must have much better content creation capabilities. This page is for use cases dealing with content creation.

General Development Comments

Protocols, API's and 3rd Party Tools

The strength of the web for development has been the availability of open, extensible protocols which allow a wide variety of individuals and organizations to build contents and tools for building content, and it seems likely the same model is the most viable for greatly expanding SL. This means that 3rd parties must be able to develop tools and extensions to the basic platform supplied by LL which requires that the development API's and protocols need to be open and extensible. LL's expertise and value added isn't in building such tools in any case.

Debugging Sim

A lot of these use cases seem most practically implemented by being able to put one or more sims onto a local machine and running them in a debug mode. This is analogous to how web apps and pages are developed. They are not put up onto the public web until they have been completed. Development is done on local instrumented systems.

Such a DSim could have a limited number of objects and scripts it supports so it's possible to run multiple ones on a single local desktop machine, but it must behave identically to the real grid. It probably isn't necessary (and may not be desirable) for it to be connected to the grid. Individual uses cases have comments on what seems likely to be required to support them.

Use Case: Programmed Object Creation

  • Creator wants to build a family of complex objects
    • Creator builds or buys and uses appropriate builder tools to develop the object framework for the family of objects.
    • Other members of the object family are built by using the first as a component or template for building others and letting the builder tool compile the rest.
    • Design changes can be done by modifying the initial object framework and using the builder tool to recompile the family members.


  • 3rd party tools need to be able to be built to do complete programmable object creation.
  • As new objects become available, they shouldn't break code designed to build existing objects.
  • DSim
    • Displays objects as created including flexies, sculpties, physics, linking, etc.
    • Accepts full object definitions as a specification written by a 3rd party tool, e.g. XML

Use Case: IDE based script development

  • Creator wants to develop scripts in a productive IDE
    • Auto-completion needs to be updated whenever the scripting API changes
    • The IDE needs access to a current version of the compiler for whatever language(s) are supported.
    • Debugging needs to be integrated into the development environment.
    • Context dependent help should be available and automatically linkable to one or more wiki's.


  • Again, this is probably only practical if IDE's can be built by 3rd parties and run off-world.
  • The language definition for the IDE needs to be kept updated and easily downloadable.
  • The actual current compiler must be able to run off-world and emit code that can be run.

Use Case: Script Debugging

  • Creator wants to debug scripted objects
    • Uses debugging tools integrated with the IDE.
    • Sets up the starting environment to run the test or reloads a saved starting environment.
    • Instruments the code with logging and breakpoints.
    • Runs the test, inputting events
    • Observes the results in an environment similar to the Grid.
    • If a breakpoint is hit, examines of variables, object states, immediate history
    • After a breakpoint, the simulator state can be restarted and single stepped.
    • Ideally edit and continue could be supported


  • Again, this is probably only practical if 3rd parties can build the debuggers, so the off-world sims need a well defined API to access both debugging information and to do things like take a state snapshot, restart from a saved point, and stimulate event firings.
  • DSim
    • Access to script variables in multiple scripts and objects
    • Breakpoints - hopefully programmable so external debuggers can examine the overall state and only actually break if a set of conditions are met.
    • Single stepping sounds like it would be tied to the simulators state change clock - I don't know enough about how this works to comment further.
    • Access to object states (positions, rotations, physics, phantom, links, etc.)
    • Pause and restart the simulation to allow debugging and other processes to examine the states without them changing.
    • Event generation under programmed control

Use Case: Regression Testing

  • Creator wants to test changes to existing scripted objects
    • Uses tools possibly integrated with the IDE and debugger.
    • Reloads a saved starting environment.
    • Instruments the new code with logging which can be compared to the base case run data by the testing package while running.
    • Runs the test with a stream of programmable event stimulation and/or interactions with other objects.
    • If a regression event triggered by the test package occurs, the simulation freezes and allows examination of variables, object states, immediate history


  • This is probably very similar to the requirements of the debugger
  • DSim in addition to the debugger requirements
    • Mechanism for coordination between the state of the objects and the event stream being passed in. That is, the tester can tell the objects have gotten to a known state before sending in the next set of events and the sim will wait for it to notice that and react. Likely this is similar to the debugger breakpoint and restart.
    • Ability to rerun from a known starting state but with new objects and scripts.

Use Case: Vehicle Development

  • Creator wants to build a vehicle that can cross sim boundaries and avoid banned areas and other security issues
    • Uses Building, and IDE tools
    • Creates a test environment with varied terrain, weather, banned plots, sim crossings, etc.
    • Operates the vehicle in the environment under debug control including catchable events for hitting region or plot based error conditions.


  • This definitely requires use of more than one sim.
  • DSim in addition to the debugger requirements
    • Terrain editing.
    • Subdivision of the land into plots with different ownership and security settings.
    • Weather control
    • API / Protocols for interacting with the debug environment if sim crossings, and security settings events occur.

Team building and scripting systems of objects

Needs work