Difference between revisions of "Inner Space 2"

From Lavish Software Wiki
Jump to navigation Jump to search
 
(12 intermediate revisions by the same user not shown)
Line 18: Line 18:
 
Believe it or not, I listen to comments on what is good or bad about Inner Space. Here's what irks people.
 
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.
 
* 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.
* Lord of the Rings Online "is not supported" due to use of a .NET launcher. It works fine on some systems, but not on others. A loader can be used for systems it does not work on.
 
: '''Important update: Development of the Inner Space 2 launcher has identified the fix for this problem. Lord of the Rings Online should work fine with Inner Space 2. The Inner Space 1 launcher will be updated with this fix after it is properly tested.'''
 
 
* 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 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)
 
* LavishScript objects are relatively difficult to define (in C)
 
* LavishGUI is a pain in the ass to create UIs in
 
* LavishGUI is a pain in the ass to create UIs in
 
* Relay system is difficult to work with
 
* Relay system is difficult to work with
* Relatively hard to pass data to new sessions (e.g. have a script launch a session, passing in some required session-specific data)
 
 
* Difficult for new users to learn to use properly
 
* Difficult for new users to learn to use properly
  
Line 31: Line 28:
 
: Sorry, this won't be implemented. But look at the bright side, you could make a titties skin!
 
: Sorry, this won't be implemented. But look at the bright side, you could make a titties skin!
 
* A new presentation layer - LightShadow
 
* A new presentation layer - LightShadow
* .NET 3.5 support - Risky
+
: '''Implemented'''
: This should work in IS1, according to LightShadow. I haven't tried it myself.
 
 
* Backwards compatibility - Amadeus
 
* Backwards compatibility - Amadeus
: Sorry, no promises here. It will be vastly different
+
: 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
 
* Versioning support (e.g. ability to launch a prior version of an app) - Singularity
 
* Built-in screenshot (full and partial) functionality
 
* Built-in screenshot (full and partial) functionality
Line 40: Line 36:
  
 
=== Highlights ===
 
=== Highlights ===
; A few things to note about Inner Space 2 that were not available in IS1
+
; 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 application developers. 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 is designed to allow tight integration for [http://en.wikipedia.org/wiki/Independent_software_vendor 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 launching mechanism includes improved support for launching .NET applications. This means that games like Lord of the Rings Online may be officially supported by IS2, and this support should soon be retroactively supplied to Inner Space 1!
+
* IS2's modular design allows ISVs to develop custom implementations of various engines, such as user interface or binds (hotkeys).
* IS2's modular design allows 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 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 ==
 
== Project Timeline ==
Line 55: Line 53:
 
: Minimal alpha build ready for internal testing.
 
: Minimal alpha build ready for internal testing.
 
* April 2008
 
* April 2008
: Development of WinEQ 2 successor (referred to as Cerberus, but this may not be the final product name) using the Inner Space 2 kernel begins. This accelerates the development of IS2's kernel integration features, and will take care of WinEQ users who have been waiting a while for new features and fixes.
+
: 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
: 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 Cerberus -- e.g. window management, input bindings -- followed by other systems as per demand
+
* May 2008-April 2009
; Projections for 2008
+
: Inner Space 2 postponed. Inner Space 1 updates performed to leverage existing architecture. ISBoxer Suite created on IS1 platform.
* May-June
+
* April 2009
: Web site and auth server updates to be completed in preparation for new product betas
+
: Inner Space 2 engine development resumed. Joe Multiboxer development to resume soon.
* June-July
+
* 2010
: Minimal beta build of Inner Space 2 ready for public testing.
+
: Various segments of the IS2 core feature set are ready, including support for DirectX11, Peer-to-Peer communications, and the virtual file system
: Beta build of Cerberus ready for public testing.
+
; Projections
* August
+
* Early 2011
: Cerberus 1.0 to be released
+
: Joe Multiboxer beta
: Inner Space 2.0 to be released
+
* Mid 2011
 +
: Inner Space 2 alpha
 +
: Inner Space 2 Engine available for licensing
 +
 
 +
=== Track Inner Space 2 Progress ===
 +
* Check the regular updates on [http://twitter.com/LaxLacks Lax's Twitter feed]
  
 
== Discuss ==
 
== Discuss ==
 
Join discussions of Inner Space 2 on irc.lavishsoft.com in #innerspace2
 
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.

Latest revision as of 18:01, 29 November 2010

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.