What do we need to declare 1.0?

[BenjamenMeyer]

This is a discussion thread and will eventually turn into a Project Board with the various parts as tasks. It just helps to get the discussion started in a single place where we can start adding check-lists.

The "1.0" version is a major symbolic milestone. what do we need to get there? And what can we defer to 2.0?

Required for 1.0:

• [ ] Application Binary Interface (ABI) stability
• [ ] Stability between the engine and Python interfaces
• [ ] Stability of saved games files
• [ ] Game Assets and Engine are released on separate cadences
• [ ] Change Game Assets from using CSV/TSV to JSON
• [x] Move away from XML to JSON
• [ ] Keyboard Editor Utility
• [ ] Game Launcher that supports multiple data sets

Nice to have for 1.0:

• [ ] ???

Deferred to 2.0:

• [ ] Network Game Play
• [ ] Text Rendering changes
• [ ] Dropping support for CSV/TSV/XML in Game Assets and Configuration files.

Asset Links:

• VS:UtCS: https://github.com/vegastrike/Assets-Masters/issues/33
• PCWU: https://github.com/pwcu/privateer_wcu/issues/2

[evertvorster]

An autopilot that works? The current autopilot behavior detracts quite a lot from game play. The player ship needs to smoothly exit out of SPEC and drop out of autopilot at a reasonable distance from the target. From my last bit of game testing it seems that vessel speed has a huge impact on SPEC, and it should not. Coming up to SPEC is nice and smooth, and one expects dropping out to be the same.

In addition to that, it would really be nice to have is dynamic skybox generation. It will cut down the size of Assets, and provide a much more visually pleasing experience. For an example of this being achieved in a browser in a lightweight and repeatable way: https://wwwtyro.github.io/space-3d/

[BenjamenMeyer]

@Loki1950 would the autopilot be the engine, assets, or a combo of the two?

[Loki1950]

It's really a combo of both the auto pilot works the way it does in response to how SPEC is defined which is part of the story/background therefore asset related.

[stephengtuggy]

@BenjamenMeyer are we sure that we want to move the assets to JSON as soon as 1.0? Seems like that will be a massive change, from the assets side.

[BenjamenMeyer]

@stephengtuggy we'll probably have a number of intermediate releases before getting to 1.0, so I don't think it'd be a big issue. Though for 1.0 perhaps we should support both and then drop the older method in 2.0?

[stephengtuggy]

@BenjamenMeyer I'm hoping 1.0 will be our next release after 0.8, replacing 0.9.

Yes, I think supporting both would be a good idea as far as 1.0 goes.

[stephengtuggy]

In 0.8.x we introduce the engine versioning. Then in the next release (1.0.x), we break a bunch of interfaces in order to get things right, in terms of integer widths, namingConventions, and so forth.

[nabaco]

I consider changing from CSV/XML to JSON an interface change too, so I would consider doing it as part of 1.0 Changing it in the future will require a major number update (e.g. 1.0 -> 2.0)

[stephengtuggy]

@nabaco I suppose you're right. We're changing the interface anyway; might as well change to JSON while we're at it.

[BenjamenMeyer]

@stephengtuggy I would prefer to do a bunch of the refactoring and interfaces changes before we hit 1.0.

1.0 should be a long term stable interface, so we'd be committing to holding the interfaces for a longer time. Let's figure out what we want to change now and then set a timeline on 1.0.

FWIW, this is just a story to collect requirements for 1.0; I don't see us having a timeline on when 1.0 will be until after that and we'll probably drive several 0.x releases around those requirements too.

[stephengtuggy]

@BenjamenMeyer OK, that makes sense.

[LifWirser]

Having just discovered the GH security scan ( many errors. simular errors from valgrind tools produce hugh amount of errors. So having zero errors from what ever code anlizer the VS project determines.

To keep track each error should generat a BR/issue