/Report  

Situation Assessment Diagnostic and proposition for a course of action

Preliminary work for an Unstable Space Release August 2007 version: 1.0 Author: JBureau

Scope of document

Status on current activities being held

  • Team building
  • Situation assessment information collection activity
  • Document inventory
  • Features list build-up

Report on findings after :

  • Situation assessment information collection activity
  • Existing design documents review
  • Exchanges with team members

Make a diagnostic Propose a strategy Propose a Course of Action

  • With a preliminary time table

Team members’ list

Current Team Members' List:

  • Baxter, Kevin
  • Bureau, Jacquelin
  • Day, Duncan
  • Freise, Jon
  • Maness, Shane
  • Walker, James
  • Wallace, Jasper
  • Williams, Jesse

Two (2) additional names were brought by Duncan

james >> any news on if these guys should be added into the access lists for the wiki and svn?

jesse >> No, neither of them should be added at this point.

  • Someone knows these guys ?
  • Is it pertinent to add them to the team ?

Also who knows / be able to reach these ones ?

Situation assessment information collection activity

Most (if not all) team members wrote me something on a form or an other. Thanks all for your collaboration and time investmentThere is a consensus amongst team members

  • The passion is still alive and kicking
  • Everyone have a passionate real “Second Life” to take care as well
  • The project seems to have lost itself in the maze created by the multiplicity of features
    • Many changes were induced by technical limitations of POG languages
    • Some most desirable features requires majors changes in key functionalities
    • That is… scope creep.
  • Let’s get back to basics
    • Adventure and combat backed up by an improved EoC platform, GUI and AI
    • The whole being supported by a simulation “engine”, fuelling new an challenging adventures that should enables the player to “hack and slash” and build a fortune in order to settled back for a while and look the world from a long-term perspective

Infrastructures and supporting environments

During the last week Joco brought up a wiki. Alongside of already existing

The wiki should be our main collaborative tool and way to exchange information, thoughts and contribution

  • Email become cumbersome when the volume is high and many persons have to be informed
  • URL and access parameters has been sent to members by email

All files cited in this communications has been post in the wiki. Please take a look.

Many Thanks to joco for his dedication and sustained collaboration.

Document Inventory

Based on existing documents located in various places, a list has been built and submitted to GT to review their freshness and pertinence

  • File is :filelist_jon.xls

Non-deprecated documents has been retained as sources to build a features inventory list

  • See also next section

Features Inventory

From the various design documents still current, a first draft of a high-level features inventory document has been assembled by GT and revised by Jesse.

  • The document is on the wiki in the Action Items topic and called:
  • EOC_US_Features_List_V1.pdf

james >> putting the features into a wiki page with room to put progress under each one might be useful? Or even exploding each feature out to its own design wiki page?

Diagnostic

Design documents shows an incredible wealth of opportunities and expansions to implement. These opportunities shows:

  • A disjoined state amongst features and a lacks of continuity/integration thereof
  • Still there are functional patterns sketched behind the scene that could be unveiled thus easing the system’s function breakdown structure
  • Some key features calls for a major rework of existing GUI, functions and business objects of the EoC Platform
  • Some features are very interesting but requires a 360° scope, a global design and focussed efforts to be delivered in a acceptable time frame and voluntary-based resource availability
  • GT and al. coded a large asset of POG Scripts, addressing multiples aspects of the game. This asset could be a very good springboard for reuse and guidance for future add-ons

In order to organize and regroup semantically and logically associated concepts a high-level view package diagram has been created

  • Wiki TornStars: Architecture : EoC_Global_Model_V2_JB.pdf

  • The key is the formalisation of the “career management” concept
  • In Short – a given career provides to a player choosing it to:
    • A set of new specialized ships adapted for the job and their related loadouts
    • A set of specific operations being executed from a specialized set of stations. Each operation serving as anchor for a suite of missions

    • A set of applied technologies that could be further developed through acquisition/building of R&D Stations who then can develop/enhance a technology

    • A very crude – tentative for discussions and improvement of a career-management sub-system (this is quite big) is depicted as a roadmap
    • Wiki: Architecture: Features: Career management

Diagnostic – a high-level function breakdown structure

Others functional treads has been formalized and (tentatively) pre-scoped as follow. Namely:

  • Traffic – the “AI_Ship improvement Program”
  • Torn Stars – “Trading extension Module”
  • Unstable Space – “Capsule Jump Transformation Module”
  • Azran Shipbuilding Naval Yard
    • The “improved loadout management extension module”
    • The DYO Ship module
  • Tango Squadron’s 2nd Fleet
    • The “AI_Ship wingman Improvement Program”
    • Fleet management module
  • Knowledge is power

    • R&D technical advancement management module

  • Drones of Epitaph
    • World Extension Module

Diagnostic – The Career management paradigm shift

Career-management is explained more extensively in the following four (4) reasons:

  • (1) its “large spectrum” impact its generates on the current EPIC code baseline and induced constant rippling effects of updates and change requests over large chunks of existing code
    • Too heavy to be conveniently managed under a volunteering development approach. Even with a remunerated standard IS development team and approach; this is a major code rewrite project.
  • (2) Recurring appearance of related features/design notes written in many design documents
    • this is a cornerstone for the future ;
  • (3) Personally, this whole “paradigm” seems to be the “prime” suspect responsible for the lost of focus that occurred by the end of 2006
  • This is the reason why I called it “Paradigm Shift”
  • This is the reason I'm taking time here to elaborate a little over it. Because being a probable cause of failure doesn't means it’s bad
  • More, the Career management sub-system holds the key to restart the project and successfully deliver something to the community
    • This is also an opportunity from a PM perspective (see #4 next)
  • (4) Career-management sub-system, from a PM perspective, enables EPIC Team to:
    • reorganizes features in an orderly manner,
    • keeps scope of others packages manageable and within reach of volunteer-based development teams
      • Without abusively taxing “real life” time. Otherwise, it's generating disbelieve and frustration against an impossible task then triggers progressive disengagement and ultimately project’s death
    • Build on strength and diversity and agility of a volunteer-based team
      • Tasking and assignments are kept aligned with scope and design orientations
      • Vertical chunks (for example new ship graphical design) can be realised under a different tempo than the rest of the development
      • Agile development approach generates the most benefits under this kind of breakdown (iteratively develop and deploy small chunks of the whole system)

Career management – proposed Functional breakdown Structure

SpaceLife – “Life, work and death in Space”

  • This is the “Career-Management Program”. More seen as a base framework than a extension module or a sustained evolution program
  • Having the following Extension Module that will be delivered over time:
    • The Corporate Career Path
      • Miner
      • Trader

    • The Law & Order Career Path

      • Police Officer
      • Navy Officer
    • T’Ang High Security Penitentiary - Criminal-minded career Path
      • Pirate

    • Social & Community Involvement – Extraordinaire “ordinary life”

      • Engineer (communications, energy storing/producing)
      • Space Farmer

      • Space Healthcare & pharmaceutical

      • Shipbuilding, Supplies and maintenance (including fuel management)
      • Piety and Devotion (religion)
    • Undercover
      • Agent
    • Freedom
      • Mercenary
    • Upper levels (or life beyond the masses). Can be reached only after having followed one of the previously spoken related base career paths:

      • Corporate - be a CxOs

      • Civilian - Diplomat then head of government
      • Rebel

Career management – Integration with the planned EoC Ecosystem

Career relies on specific dedicated packages inside following “wrapper” packages that will be extended at a proper time such as :

  • Operations Package – Specific Operations and missions implementation to a given career
  • Traffic package - Specific Ship behaviour implementation particular to a given career

  • R&D package – Specific technical/technological extensions unique to a given career

  • Player_ship package – Specific ship templates/loadout unique to a given career.

Diagnostic

Current EoC Platform positioning on the game market

  • Recent forums’ probing reviews shows a progressive fading attention of the EoC community for the proposed Mod
    • Action should be taken to improve this state
  • Personally and honestly I not yet seen a Space Sim game achieving the same playability as EoC
    • Have you seen an other game in the same vertical as EoC that could throw it out of the scene ? Or drag a significant part of the community away of the Mod currently under preparation ?

Unstable Space Next Release’s Delivery Strategies

The available strategies

  • 1 Complete the initial scope and features list as previously planned
  • 2 Re-scope and scale down the initial features list to provide the core vision of Unstable Space
    • The “Capsule Jump Transformation” Module
  • 3 Plan a new revised release with alternates features available from EPIC code portfolio
    • Such as the new loadout module

Strategy Number 1

Deliver Unstable Space with the current list of features. The iteration will be to close outstanding bugs and straight things up to an adequate level

Advantages

  • No distinctive advantage identified

Disadvantages

  • The team is risking to be stuck again where things had been left nearly 10 months ago, without new alternatives
  • The “rebirth” will most likely generate expectations. If a new “no-delivery” happens this will generate collateral damage in the community over EPIC team and future projects
  • We currently lack of sufficient POG programming capability to review code and provide development support to intensive testing that will take place

Strategy Number 2

Scale-down initial Unstable Space’s scope to covers only safe already/nearly implemented features. The iteration will be to close outstanding bugs and straight things up to an adequate level

Advantages

  • A very short iteration (3-4 weeks duration)
  • Reconnect the community with EPIC development team and generate momentum inside the community to hire new programmers
  • Gives to EPIC Team additional time to refine and improve design of the overall architecture and to plan in advance in-depth necessary changes to support the vision
  • Risks for the project to be halted in the same previous conditions are mostly eliminated
  • Fulfill community expectation with a “certain kill” without exposing at-risk features to the community
  • Risks over POG programming capability shortages are minimized
    • We mostly have to test and debugging should be limited to a limited part of the “code surface”

Disadvantages

  • We may need to manage team members’ deception and impression to go backward instead of forward

Strategy Number 3

Plan a new revised release with alternates features readily available from EPIC code portfolio

Advantages

  • No distinctive ones

Disadvantages

  • Globally this strategy is a Capsule Jump to an unknown LPoint. Questions such as :
    • Which features we should choose for the new baseline ?
    • Do we have the time to review or redesign a whole concept?
    • Do we have the programming capability available ? Are we able to manage cascading effects and changes effectively ?

This is not a strategy in itself but instead an opportunity to start a second iteration in parallel of the second one (ideally)

Proposed Strategy

A most likely successful strategy should be oriented on Strategy #2

Amongst identified features for the initial Unstable Space Release Which ones can :

  • be retained ?
  • can be postponed to a later, with more functionally integrated iteration?

What could be stripped down ?

Basically, I found five (5) distinct Requirement Sets pertaining to US release in the documentation :

  • The improved Capsule Jump
    • the Unstable Space Core subject
  • Fuel Management
    • This is one could cascade through others features like loadout, ship, etc.
  • New Periodicals
  • Asteroid Mining
    • this is truly aligned with a specific career-path management
  • Combat-related features
  • Non-player AI as two aspects on this:
    • Wingmen behaviour
    • others ships behaviour

Current Pending Unstable Space release Scope Analysis

Features List:

  • Improved Capsule Jump : This is in fact the long awaited Unstable Space Release

  • Fuel Management: This is more related to ship loadout management\ship types upgrades.

    • To simplify the packaging, we could associate Fuel Management to a given career path associated to Ship Maintenance (who will provide the new ships types, new operations, etc. associated with it).
    • Obviously, this career path should be the subject of an independent iteration/release

  • New periodicals: should clearly be the subject of a different iteration/release that could covers the whole subject of communications inside the game.

    • The idea is great and opens doors to a great wealth of possibilities;

  • Asteroids Mining: truly the subject of a separated Release oriented on the addition of a new career in the EPIC Portfolio.

    • Also, I remembered I've played to a good mod ("Gold Rush" or something) Is it possible to reuse/recover existing code and build over it ? (Missile sensors was a great idea )

  • Combat-related Features: Known to be buggy and requires more POG programming resources than we currently have available

  • Non-Player AI: Two-folded feature

    • Wingmen definitely needs a better AI to control their behaviour.
      • This is sufficient work behind this to sink all the best goodwill of any volunteering team
      • This should be taken separately and designed from a global perspective. Due to the extensive work required I suggest to address the whole perspective independently of Traffic
    • All others Non-Player related Sims' AI improvements and behaviours is really the core of traffic concept.

We should focus Traffic on the improvement and generation of, that is traffic around stations. This is sufficient work for a self-supporting independent release as well.

Proposed Course of Action

Strategy #2

  • Release a re-scoped Unstable Space containing the “Capsule Jump Transformation Module” only

james >> another alternative might be the new loadout facilties that Jon had developed just before finishing up. Or would be too much of a bite?

jesse >> I think the loadout could be built by Joco and I. My only worry about releasing the "Capsule Jump Transformation Module" only would be that taking out the current code could be more work than just finishing it as it is.

jon >> I think jesse has a good point here. Some features are easy to turn off, but some are very difficult in that they open new bugs. You can turn off mining by not placing mining rigs or science ships in the game. But if you turn off loadout you have to turn the player base back on. Then you have to solve all the bugs related to player bases. It would be more worthwhile to just finish up the loadout related work. Just a simple set of purchased weapons and equipment would be enough. The player cannot have more than 5 ship types as it is now. I think more time is needed assessing the current state of the features before a plan can be made. How about break up the feature set into testable chunks and hand them out to team members to try out?

james >> An assessment of implications in removing things as well as how "complete" something is sounds like a good idea. Emails I have seen suggest Jon has started looking at parts of this question already.

  • Proposed time box : Two (2) iterations of four (4) weeks each

james >> makes sense but realities of a mod teams time committments has me wondering what levels of time will be needed to execute on this. And then if said work time is available in these iterations.

  • Proposed due date :
    • Iteration #1 Goal: (proposed from mid-Sept. to Mid-Oct. 2007)

      • bug review & correction

      • installation package development
      • Advertisement on forums and community announcements
    • Iteration #2 Goal: (proposed from mid-Oct. to mid-Nov. 2007)
      • Selection of beta testers from community
      • Beta testing with community
      • Code freeze and final release
      • Final Distribution to community