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 rookie 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 change is already in-flight; I am working on a lightweight ECS in C++ tailored to pioneer's needs, and the team has been working on splitting the monolithic core classes up into more manageable chunks - see Propulsion and ShipController.

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 pretty much 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 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.