Inner Space 2

From Lavish Software Wiki
Jump to navigation Jump to search

Introduction

Why Inner Space 2?

Inner Space is a good thing, right? And why mess with a good thing? There are inherent flaws in Inner Space, and I intend to solve them. It's supposed to be a development platform, but developers are turned off by things that are difficult to develop with, such as LavishScript or LavishGUI. New technologies have been added to Inner Space since its inception that move in the right direction (such as .NET support), but advancement is held back by backwards compatibility and the continued use of conflicting old technologies. New users are also turned away by the relative difficulty of learning to use the system. The default UI, which although it is 100% customizable but never has been customized, is not geared toward helping them figure things out.

Inner Space 2 will first and foremost solve the main problems for both developers and users. Anything less would be unacceptable.

What will happen to Inner Space 1?

The original Inner Space will remain as is. It will be feature frozen after the release of IS2, and will only receive bug fixes and other maintenance updates. Most customers will not even realize these changes are taking place.

Features

The complete initial feature set is yet to be determined, and this section is a work in progress. Your input may be valuable!

IS2 will work essentially the same as IS1. There will be a main program (known as the Uplink in IS1, though this confusing term will be dropped in IS2), and this will be used for configuration and launching new sessions. Most of the core of IS1 will be reused -- Virtual Input, D3D8, D3D9 support, much of the IS1 Kernel -- this also means that development time required to complete this new project is fairly low. But these are the parts that have little wrong with them. The core of IS2 will, however, be modified to be more modular. For example, a developer will have direct access to the Direct3D9 display device object if he so desires. That developer could create his own user interface module, that allows WinForms to be displayed in the game's D3D window. Or he could create a radar application, unhindered by the restrictions of LavishGUI.

IS2 will also feature a sort of marketplace, with both free and pay services. Developers will be able to share their work through this common interface, which will serve as a package updater (so that finding, downloading, and updating extensions and apps is less painful), and an authentication system for their products. Extensions, for example, will be able to be locked such that only authorized users can access them.

Gripes about IS1

Believe it or not, I listen to comments on what is good or bad about Inner Space. Here's what irks people.

  • Configuration UI is hard to use, partly because of LavishGUI bugs, and partly because I hoped someone else would eventually create their own configuration UI to share. Nobody did.
  • LavishScript is "slow", among other things. LavishScript was never intended to be a replacement for real languages. I needed a command interpreter for the console.
  • LavishScript objects are relatively difficult to define (in C)
  • LavishGUI is a pain in the ass to create UIs in
  • Relay system is difficult to work with
  • Difficult for new users to learn to use properly

Feature requests

  • "TITTIES!" - Adadada.
Sorry, this won't be implemented. But look at the bright side, you could make a titties skin!
  • A new presentation layer - LightShadow
Implemented
  • Backwards compatibility - Amadeus
Note: Backwards compatibility with Inner Space 1 is planned to be provided through a compatibility layer
  • Versioning support (e.g. ability to launch a prior version of an app) - Singularity
  • Built-in screenshot (full and partial) functionality
  • Remote (web) management - crazyhorse

Highlights

A few things to note about Inner Space 2 that are already in testing that were not available in IS1
  • IS2 is designed to allow tight integration for ISVs (application developers outside of Lavish). For example, it will be possible to create a custom launcher by loading the IS2 kernel and instructing it to launch a session (e.g. a game instance to host an IS2 instance), and may have any data transferred to the new session at launch. It will be possible to make an application use Inner Space 2 behind the scenes, instead of requiring the end user to learn to use Inner Space. The minimal loader presently used for testing is written in C# and can launch any process as an IS2 session with only a few lines of code.
  • IS2's modular design allows ISVs to develop custom implementations of various engines, such as user interface or binds (hotkeys).
  • IS2 uses Unicode encoding wherever possible, so as to avoid the vast majority of conversion and localization issues present in IS1.
  • IS2's default input binding system is more robust than the system in IS1, and includes the ability to bind axis and directional pad controls.
  • IS2 provides a new display overlay system that allows rendering of sprites (specifically textured quads at the moment) and text, with full transformational control (rotation, scaling, etc). This system is independent of any GUI-specific technology, and can in fact be used alongside GUI modules for rendering above or below the GUI (or both).
  • IS2 will provide a default GUI module, without requiring developers or end users to commit to a specific GUI technology. Multiple GUI modules can be used together, for example CEGUI and the new LavishGUI can operate side by side in the same IS2 instance.

Project Timeline

History
  • September 2007
Planning stage begins.
  • Early 2008
Development stage begins.
  • March 2008
Minimal alpha build ready for internal testing.
  • April 2008
Development of non-critical IS2 feature set (all of which can be omitted from an IS2 configuration) begins, starting with systems to be used by Joe Multiboxer -- e.g. window management, input bindings -- followed by other systems as per demand
  • May 2008-April 2009
Inner Space 2 postponed. Inner Space 1 updates performed to leverage existing architecture. ISBoxer Suite created on IS1 platform.
  • April 2009
Inner Space 2 engine development resumed. Joe Multiboxer development to resume soon.
  • 2010
Various segments of the IS2 core feature set are ready, including support for DirectX11, Peer-to-Peer communications, and the virtual file system
Projections
  • Early 2011
Joe Multiboxer beta
  • Mid 2011
Inner Space 2 alpha
Inner Space 2 Engine available for licensing

Track Inner Space 2 Progress

Discuss

Join discussions of Inner Space 2 on irc.lavishsoft.com in #innerspace2

Investor Information

Lavish Software is actively developing Inner Space 2. Several ISVs have contacted us to share their interest in developing commercial applications with the Inner Space 2 engine in a transparent fashion. Lavish is working hard to expand the Lavish Software team and advance and market our technology.

Lavish is also interested in hearing from ISVs that may be willing to purchase Inner Space 2 engine licenses in advance at a discounted rate (yet to be determined). This type of license will be available via contract on a per-product basis, for application integration, and will not require end-user accounts with Lavish Software.