The Goals of Spine

Spine is a software system that enables the construction of distributed, interactive, immersive applications. As such it must provide services that contribute to fulfilling this purpose. This page details the major functional goals of the Spine project.

Primary Goals
  1. Enable development of digital worlds
  2. Be Complete
  3. Be Easy
  4. Be Functional
  5. Be Portable
  6. Be Modular
  7. Be Safe
  8. Be Fast
  9. Be Educational

1. Enable development of digital worlds

Spine must provide the most basic of functions needed to immerse a computer user in a virtual world or scenario.

Using Spine should also be easy and hassle-free. Spine will achieve this by being simple, consistent, and well documented, while providing access to the major computer technologies needed to flexibly portray complex, immersive scenes.

2. Be Complete

Of course, no software is ever finished, but Spine must successfully fulfill it's role as a backbone upon which to flesh out your application. It must allow the developer to build immersive computer programs while minimizing the time they have to think about low-level specifics or platform quirks.

Spine must attempt to be a total solution, offering components to perform all commonly-needed low level tasks, freeing the developer to think about programming training simulations or virtual castle dungeon games.

3. Be Easy

Easy to learn

Spine must be very approachable with an obvious, discoverable set of components and utilities that solve the most common problem people are likely to face when building immersive applications.

No crazy defines, constants, build switches, dependancy problems, or cryptic method names - Spine must have a small, logical set of main components that use consistant class design and naming schemes.
Spine interfaces will be black-boxes with obvious pushbutton-like functionality.

Not only must Spine be easy for it's users, but it must also be easy for it's developers - at least initially. The internals of Spine will be developed along the lines of "do the simplest thing that could possibly work", so speed and efficiency might be sacrificed for obvious implementations and readable code, until usage requirements become more clear.

Easy to setup

Spine must not be difficult to install, configure and integrate. It must use minimal, basic linking procedures, and have as few dependancies as possible.

Spine must be a nimble, self-contained toolset that can be moved around easily, but this is offset against it's large problem-space and diversity of function. It will be a challenge to keep it small, but that is no reason not to try. If the full SDK becomes too large for example, it could be offered complete or piece-wise, at the downloader's discretion.

Easy to integrate

Spine must enable painless integration of multimedia immersion technology to application software and tools. Spine must be as "embeddable" as possible, in order to maximize the number of potential points-of-presence.

Spine must leverage powerful and trusted industry-standard libraries, selected for platform-independance, simple build procedure, liberal licensing, small size and reputation for reliability and stability.

4. Be Functional

Spine must be capable of a maximum variety of functions and purposes. Spine is an attempt at a total solution, in order that developers need not require any other tools (other than a compiler) to implement a wide variety of application types and styles.

Spine should maximize usage of current computer hardware and software capabilities within the mainstream sector of development. This means that Spine might not offer total control of the absolute bleeding edge in current graphics card technology, but it will endeavour to remain within a stable mainstream bracket of capability and consumer acceptance, in order to maximize usage.

5. Be Portable

The system and it's components should be easily implemented on multiple platforms. Major operating systems like Linux, BSD and Windows should be supported. Following a cross-platform design ethic is a major strength, promoting seperation of concerns and broadening knowledge.

6. Be Modular

The various Spine components or parts should be useable standing alone (where this is logical) and fit together smoothly and securely.

7. Be Safe

Spine will as much as possible, be built on common, proven, existing API's to maximize standardization, robustness, and user interest.

Spine will include built-in text and file-management components, as well as hassle-free resource management.

8. Be Fast

Spine system should be fast enough to provide realistic operation on mid-range computer equipment, particularly laptops.

The Spine scene system is only a very thin wrapper over DirectX or OpenGL, so more experienced developers with an understanding of computer hardware and lower-level systems will be able to tweak the performance of their worlds by using well-documented scene-management techniques.

9. Be Educational

Spine must be educational in all possible respects (it's development has been so far...). Spine source code, design documentation, reference manuals, infrastructure and website must be written and presented in a fashion that makes learning easy and approachable. Spine must be easy to discover and be easy to maintain.
Spine must be able to teach others as much as it has taught me.


[Prev]        [Next]



Back to Top