User:Sturnclaw

From PioneerWiki
Revision as of 20:41, 16 October 2018 by Sturnclaw (talk | contribs) (Add the ECS and Input tasks)
Jump to: navigation, search

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.

Gameplay:

Rendering:

Content: