User:Sturnclaw

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

In more serious news, 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.

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 (DONE) and implicit "init.lua" support.
• Make throwing a Lua error safe with regards to C++ code, and support arbitrarily disabling a Lua module if it is throwing an error.
  • 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.
  • Use a Lua script to scan C++ files for annotations, generating bindings based upon annotated properties and methods.
  • To avoid re-inventing the wheel, generate C++ files that make heavy use of templates to pass data back and forth from Lua. This will allow programmers to do sanity-checking in template specializations, and create a common convention for binding data to Lua.

Gameplay:

• Refactor the camera / view system to better support inputs, allow arbitrary spectator / debug cameras for editor mode, enable first-person and turret cameras.
  • Add a "camera offset" axis for internal / cockpit view that can be hooked up to headtracking. In Testing
  • Make the existing camera system use the new InputFrames for input. In Testing
  • Decouple camera systems from the concept of a ship to make them suitable for debug/flying cameras. Evaluating
  • Add cameras for turrets. Stalled on Dependency
• Completely rewrite the weapons systems to support arbitrary guns and turrets, as well as a better loadout system.

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.

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 the new gun / missile system.