Difference between revisions of "Content Development"

From Second Life Wiki
Jump to navigation Jump to search
Line 1: Line 1:
= Development Use Cases =
= 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 Comment on API's and 3rd Party Tools ===
The strength of the web for development has been the availability of open, extensible protocols, 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. To do that in this context, 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.
== Programmed Object Creation ==
== Programmed Object Creation ==
* Creator wants to build a family of complex objects
* Creator wants to build a family of complex objects
Line 6: Line 9:
** Design changes can be done by modifying the initial object framework and using the builder tool to ''recompile'' the family members.
** Design changes can be done by modifying the initial object framework and using the builder tool to ''recompile'' the family members.
=== Comments ===
=== Comments ===
* Practically, this is probably only possible if 3rd parties can freely build and sell development tools that will run off world. In any event, LL's expertise and value added isn't in building such tools.
* Practically this probably requires an off line building capability.
* Furthermore this means that the external object definition interface must well defined and open ended, e.g. XML so it can withstand updates.
* To allow linking, physical, flexie and things like texture and sculptie animation, the probably needs to be part of the ''debugging sim'' discussed below.
== IDE based script development ==
== IDE based script development ==
* Creator wants to develop scripts in a productive IDE
* Creator wants to develop scripts in a productive IDE
Line 27: Line 30:
** At a breakpoint, the simulator state can be saved for immediate or later restart.
** At a breakpoint, the simulator state can be saved for immediate or later restart.
=== Comments ===
=== Comments ===
* This probably requires some kind of debugging sim that can be loaded on a local machine.
* This probably requires some kind of debugging sim that can be loaded onto a local machine, although having a debugging API partially available on the LS grid so the client could get information about objects running in ''real'' SL would be very useful. It is essential that this be the actual sim code so the behavior of the objects in debugging actually represents what will happen in ''real'' SL, bugs and all.
* 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.
* 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.
* The sim needs to
* A debugging sim (or sim mode) would need access and control over multiple scripts in multiple objects:
** Access to script variables
** Breakpoints - hopefully programmable so external debuggers can examine the overall state and only actually break if a set of conditions are met.
** Access to object states
** Pause and restart the simulation to allow debugging and other processes to examine the states without them changing.
** Event generation under programmed control

Revision as of 07:53, 21 September 2007

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 Comment on API's and 3rd Party Tools

The strength of the web for development has been the availability of open, extensible protocols, 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. To do that in this context, 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.

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.

Comments

  • Practically this probably requires an off line building capability.
  • To allow linking, physical, flexie and things like texture and sculptie animation, the probably needs to be part of the debugging sim discussed below.

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 current.

Comments

  • Again, this is probably only practical if it can be built by 3rd parties and runs 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.

Testing, Debugging

  • Creator wants to build repeatable test cases for 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 with programmable event stimulation and/or interactions with other objects.
    • If a breakpoint is hit, the simulation freezes and allows examination of variables, object states, immediate history
    • At a breakpoint, the simulator state can be saved for immediate or later restart.

Comments

  • This probably requires some kind of debugging sim that can be loaded onto a local machine, although having a debugging API partially available on the LS grid so the client could get information about objects running in real SL would be very useful. It is essential that this be the actual sim code so the behavior of the objects in debugging actually represents what will happen in real SL, bugs and all.
  • 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.
  • A debugging sim (or sim mode) would need access and control over multiple scripts in multiple objects:
    • Access to script variables
    • Breakpoints - hopefully programmable so external debuggers can examine the overall state and only actually break if a set of conditions are met.
    • Access to object states
    • Pause and restart the simulation to allow debugging and other processes to examine the states without them changing.
    • Event generation under programmed control