[tsc-devel] SFML Port New Strategy...

datahead | Thu, 05 Nov 2015 21:24:48 UTC

Post via forum by datahead <…9@x…>:
I spoke the other day with Quintus in a PM discussion regarding the SFML port.

Currently, much of the code in the feature-sfml-port branch has been removed/deactivated, and people have been "filling in the holes", getting things working one item at a time.  It is difficult to tell which commits introduced bugs, which we already have several of.  This also could cause a risk of instability in the next release, after we fixed a good number of bugs in the last release.  Given the number of tasks labeled SFML Port in the tracker (and unknown bugs), I would estimate the original effort would go on for quite some time.  If we were to stick with a feature freeze on top of this, it could really slow growth of the project.

My main suggestion was that the SFML API porting and scene management architecture changes really should be two separate efforts.  Furthermore, we should break each of these into as granular of tasks as possible, testing each individually before moving onto the next.  Thus the game continues to function as we move from task to task.

This is one hypothetical example of a task breakdown that could be followed.  This could vary quite a bit based on our findings and discussions over time:
* Phase 1 - SFML Port
    * Port SDL Input to SFML
    * Port SDL Graphics to SFML
    * Port SDL Audio to SFML
    * Port OpenGL for sprites to SFML
    * Port particle system to SFML
    * Release the game, and get user feedback
* Phase 2 - Scene Management Architecture Overhaul
    * Create scene manager and basic scenes
    * Make game objects work off of the Actor hierarchy
    * Simplify main game loop
    * Get rid of most global variables
    * Release the game, and get user feedback

We would take the feature-sfml-port branch and use it as a reference (maybe renaming it).  One or two of the child branches created for the speedfactor / collision issues in the old port effort would also be maintained for our reference.

Given that we will have reduced the amount of complexity taking place at any one time, it will be much less risky to allow features or even simple architecture changes to take place concurrently.  We can thus analyze other tasks on a case-by-case basis to consider if they will put the above effort at risk or not.  We still do need to finish this effort; completing phase 1 of the above plan should be a priority.

What does everyone think?  This is a major decision that affects everyone.


-- 
Sent by Chessboard.