User:Sturnclaw

Hello! My name is Sturnclaw. Your code offends me. Prepare to die.

In more serious words, I'm known as Sturnclaw around here. In demeanor, I'm pretty much your typical overconfident software engineer who thinks he can do anything given enough time and sauerkraut – I'll leave the verification of that claim up to the reader.

A cursory search will reveal that I'm the owner and head of Web eWorks, LTD, and when I'm not busy with that or one of a number of side projects, I work on Pioneer to brush up my C++ skills.

You can find me on Github as Web eWorks, or on IRC as sturnclaw.

The List

Upon the recommendation of several members of the team, I have begun to curate The List, stored right here on this page.

What is "The List", you ask? The List is basically a copy of Pioneer's roadmap, kept fairly current to the latest IRC fantasizing plans, and annotated with my thoughts and recommendations for implementation. It is estimated that completing all of the items on The List will take between 5 and 15 person-years of development work, so if you want to implement something here, go right ahead.

Without further ado, I present The List:

Core Tech:

Entity Component System (ECS) Model

Convert the Pioneer codebase to use a composition-based model instead of an inheritance-based model.

• The rationale behind this decision is that an inheritance-based architecture for gameplay objects is generally unsustainable without some form of composition, especially so when mods are involved - what if your mod wants to add a different implementation of a hyperdrive?
• This will be a multi-step process:
  • Implement some minor features using the ECS paradigm to get started and evaluate requirements. Working
  • Drive the new ECS-based features from existing code as a temporary measure. Working
  • Convert a major feature (Ship, BodyOnPlanet, etc) to use the ECS.
  • Continue converting major features until all applicable areas of the code are converted.

Input System

Before I started working on Pioneer, the input system was particularly archaic; inputs were defined with macros in a single file that got #included into about 4 different files and compiled into the binary - needless to say, if you wanted a new input axis or action, you had to recompile the entire game.

The input system is currently being refactored into a modular, moddable system which supports sharing axes between systems and modules and defining entirely new axes and actions in mods.

This change is about half done - the technical underpinnings of the system are mostly finished, and all that's left is to expose it to Lua.

Planned Features:

• Modular, Lua-exposed input system WORKING
• Key-chord inputs, allowing arbitrary modifier keys / buttons. A software "pinkie switch" if you will. DONE
• Frame-based input grouping system, allowing multiple conflicting "modes" to be enabled or disabled en-bloc. DONE
• Touchscreen input for camera and flight controls. (Investigate: virtual joysticks or whole-screen mouse emulation?)

Model System

The model system needs further work and refactoring. It currently bloats savefiles excessively, has a very limited API that ignores file paths, is a pain to build files for release builds, and cannot be multi-threaded.

Planned Improvements:

• Don't store a list of transform visitors in savefiles; animations should be responsible for node positioning. Possibly use a dirty flag to only store nodes that have been explicitly positioned by code? DONE
• Refactor all code and data that touches models to use full paths instead of just the basename component.
• Refactor model loading to make it asynchronous; run the load step on a separate thread, and add an end-of-frame task on the main thread to upload model data to GPU
• Allow ModelBody to cache collision objects. This will likely come hand in hand with not creating separate Model instances.

Lua Engine

Coming on the heels of the input changes are improvements to Pioneer's Lua engine. At current, Pioneer is using its own feature-incomplete version of require() (used as import()), which supports a very limited method of calling other code files. Additionally, the C++ side of the Lua interface has issues with handling Lua errors - if C++ calls a lua function that errors, the whole engine terminates with an error.

There are several goals to accomplish here, but the major two are:

• Update import() to support Lua 5.2+ style "module.submodule" syntax and implicit "init.lua" support. DONE
• Deprecate import() in favor of require() to support languages that target Lua. DONE
• Make throwing a Lua error safe with regards to C++ code, and support arbitrarily disabling a Lua module if it is throwing an error. WORKING
  • E.g. if a specific part of the UI throws an error, silently catch it and log it. If it keeps throwing errors, disable the module and inform the user. This is going to require some significant work, but it will make the modding and content-creation ecosystem much more user-friendly.

Tangentially to the ECS changes, we need a better method of binding C++ code and data to Lua. Currently the hand-written method is serviceable, but it is akin to "implementing the same thing twice", doubling the workload for anyone wanting to add something new.

• Add an automatic solution for binding C++ code to Lua, capable of auto-generating bindings for properties, methods, and POD-structs and full LuaObject classes. DONE (see LuaMetaType.h)

Gameplay:

There are a huge number of new features and wild gameplay ideas that I and others would really like to see added to the game, but this is a more reasonable list of features that can actually be implemented with a few months of work.

• Refactor the camera / view system to better support inputs, allow arbitrary spectator / debug cameras for editor mode, enable first-person and turret cameras. WORKING
  • Add a "camera offset" axis for internal / cockpit view that can be hooked up to headtracking. DONE
  • Make the existing camera system use the new InputFrames for input. DONE
  • Decouple camera systems from the concept of a ship to make them suitable for debug/flying cameras. WORKING
  • Add cameras for turrets.
• Completely rewrite the weapons systems to support arbitrary guns and turrets, as well as a better loadout system. WORKING
  • Arbitrary fixed gun mounts. WORKING
  • Turret hardpoints
  • Missile racks / hardpoints
• Rework drag and atmospheric heating to be somewhat accurate. WORKING
• Implement atmospheric lift so aerodynamic ships can fly. DONE
• Add airframe damage due to excessive G-force and/or dynamic pressure when flying in atmosphere.
  • Possibly damage specific components (landing gear, control surfaces, etc) reducing their effectiveness and/or destroying them.

Higher-level gameplay refactor features include:

• Support procedurally-generated 'planetary outpost' buildings that have to be discovered / scanned.
  • Load outpost configurations from a scene file of some sort?
• Add power, heat, and EM system simulations to ships.
  • Power is generated by reactor and/or engines, used to operate most ship systems.
  • Heat generated by engines, shields, and weapons; vented through radiators and atmosphere.
  • EM is generated by all systems and used to determine ship sensor profile.
• Dynamic ship sensor contact system
  • Ships no longer always show up on the map, they have to be "visible" to the player
  • Add scanner mode to discover outposts, ships, etc
  • Dynamic signal strength approximation allowing reasonable stealth gameplay
  • Planetary occlusion of signals

Rendering:

PBR Rendering Engine

Convert Pioneer to a Clustered Forward or Clustered Deferred rendering model. This change needs to implement support for numerous lights, mesh decals ala Star Citizen, accurate terrain rendering with high-res texturing support via material layering and distance-dependent detail texturing, a full postprocessing chain including bloom, chromatic aberration, motion blur, and an AO implementation (perhaps an HBAO or SSAO variant), support for atmospheric shading, etc.

Reference:

• Forward+ Decal Rendering
• Filament Renderer, an open-source mobile-capable Clustered Forward PBR renderer, with accompanying whitepaper.
• A paper on clustered rendering
• Atmospheric Scattering with link to implementation.

Clouds

Possibly using a low-resolution voxelized implementation, atmospheric clouds are a planned feature. They'd need to support transparency, layer over each other without killing performance, and look at least moderately good. Flat clouds are also required when looking at a planet from orbit, which could be static textures or generated from a basic weather simulation for believable construction.

Mesh Decals

TODO: link in nozmajner's ship decal work, pontificate about supporting that engine-side.

Content:

• Finish modelling and texturing the Sador Heavy Fighter, including setting it up to use turrets and a new gun / missile system.