Roadmap for CE 1.0

[Dullstar]

Regarding skill queuing: if we're going to have a setting for it, maybe it should be for the number of frames to queue for rather than a binary yes/no.

[WillLem]

Made some progress with the Level Select menu today. Everything completed so far is marked with the Gold Talisman ( ) here.

Regarding skill queuing: if we're going to have a setting for it, maybe it should be for the number of frames to queue for rather than a binary yes/no.

Funnily enough, I had the same idea! Yes, we can try this for sure. EDIT: This is now implemented.

[WillLem]

Updated v1.0 features list - completed items are marked with a Gold Talisman ( )

Could do with some feedback on Skill Panel, Replay Features and Sounds - these are still pending discussion prior to initial implementation.

A reminder that even if something has already been implemented at this stage, it can still be updated, revised or removed altogether following RC testing.

In some cases, it has simply been easier to implement several features at once due to the way they're intrinsically linked, which is why this initial version has a lot of features; most of them have been small and relatively easy to implement, so it's no problem to re-work them if needs be.

If we can reach some firm(ish) conclusions on the remaining list items, it may even be possible to get the RC ready within in the next week or so.

[IchoTolot]

I have one more suggestion, but not regarding the overall feature list. It's more about speed and overview.

As more and more topics begin to seperate from this one, I slowly loose the overview about what the cureent state is.
Yes, implementation wise everything is listed in the first post, but that is not the point.
Also there can be a difference between the first post list and the actual implementation, but I want to get to the point.

The list is just very large! Also you need to keep track on more and more discussion topics to stay on top and I slowly start to notice fatique crawling up inside of me (we even just now had a new major update).
My time is limited and I want to do more than just keep track on the CE.

Maybe to descibe me viewpoint a bit more:
I am mostly about playing levels and level creation and not discussions about the engine (Simon would be way more into that  ) - here I am mostly concerned that it functions as intended, properly and that new additions do not do more harm than good (here I count in the extra sounds for example).
I do not like posting in a lot of engine discussion topics, I rather play levels and create my own stuff. It is just that for that I have to rely on a stable engine that does not constantly grind my gears!

That is also something I noticed about the SLX dev cycle, but as I am not a SLX user I did not care there: Topics on topics and new developments to keep track on. While slowly feedback starts to dwindle - I noticed that at some point you asked about more feedback there, but to me it seemed like the sheer amount was too overwhelming.
At some point in the "Recent posts" section it was nearly just new SLX dev topics!

Here the topic has just really started now in January and it's already slowly moving to that direction.

Therefore my suggestion (with maybe an extention to SLX even  ): Slowdown and for the first RC focus on 1 or 2 of the aspects, test those, wait for feedback, finalize them and then move to the next area. We are not in a rush!
Maybe just start with the "Options Menu" and "Level Select Menu" and after we are done with those move on to the "Replay Features".

This way people do not get overwhelmed by the sheer amount of features and we can properly implement and test them in a controled manner.
Otherwise they may just move to "why even bother?" and just stay with standard NL.

[WillLem]

@IchoTolot In the time it took you to compose that reply, you could have posted one or two sentences regarding the features!

But OK, you're more concerned about how fast things are moving, so let's address that.

I can't really do much about my natural workflow speed. What I can do, however, is put CE lower down on my priority list so that I get around to it less; this will obviously help to temper the out-rolling of features. I could also take more frequent breaks during sessions (which is something I'm aiming to do anyway for health reasons).

Another thing that will slow it down is feedback and testing, which we haven't had a chance to get to yet. Let's see how the first RC pans out.

Also there can be a difference between the first post list and the actual implementation

Not so. I update the OP to reflect the subtle changes in implementation, perhaps following discussion, insight, or implementation itself.

The OP list will always be an accurate representation of exactly what's going on in CE; in fact, that's kind of the whole point of it.

I realise people might struggle to keep up with what's going on, so I keep that list as up-to-date as possible, thus providing a quick-glance progress overview. Please do use it that way! - especially if you're struggling to keep up.

The list is just very large!

I explained this in the post prior to yours: "In some cases, it has simply been easier to implement several features at once due to the way they're intrinsically linked, which is why this initial version has a lot of features".

Future versions will have less features. At present, I'm mainly migrating stuff over from SLX that has already been implemented, tested and regarded as an improvement by the few people that use it. So, there's a lot to get through.

I will rein it in a bit though!

Slowdown and for the first RC focus on 1 or 2 of the aspects, test those, wait for feedback, finalize them and then move to the next area. We are not in a rush!

OK, I suppose it wouldn't hurt to just go ahead with what's already implemented and leave the other stuff for next time.

We aren't in a rush, sure, but the counterpoint to this is that we waited for nearly 2 years for NL 12.13, at least in part because users are slow to give feedback (if at all); I don't want it to take so long to get CE up and running.

So, what we need is a compromise between feature rollout and feedback waiting time. I can see 3 possible ways forward with this:

Option 1: We agree as a community on a development schedule, which I can then aim to stick to. I'd be happy to work to something that someone else draws up if that makes everyone feel a bit better about the rate of updates/progress, and then people know in advance how long they have to catch up with what's going on and provide the necessary feedback, should they wish to do so.

Option 2: We agree as a community on a feature limit per-version, which again gives me something to aim for and helps to keep the new feature set less overwhelming with each version.

Option 3: We agree as a community on feedback waiting time at the very least; I need to know how long I should wait before proceeding with anything.

We can also combine any of the above options.

Whatever we decide, waiting indefinitely is not an option for CE development; I'd rather abandon the project altogether than go ahead on that basis. Or, just put together my own version of NL and then make it publicly available for those that might want it. But, I don't really want to do it that way and I'm sure others wouldn't want that either; I think it would be much better to involve the community in development.

But, for that, the community needs to get involved! All I can do is post updates and hope people care enough to reply, the rest is up to everyone else!

Maybe just start with the "Options Menu" and "Level Select Menu" and after we are done with those move on to the "Replay Features".[/b]

This way people do not get overwhelmed by the sheer amount of features and we can properly implement and test them in a controled manner.

OK, for the meantime, I'll take your advice. I'll prepare an RC release soon and leave the features that haven't yet been implemented until next time.

[Simon]

Right, release what you have. You have the zoom bugfix, you evaluate keypresses during level selection, ..., all that carries real value.

-- Simon

[namida]

I can't really do much about my natural workflow speed. What I can do, however, is put CE lower down on my priority list so that I get around to it less; this will obviously help to temper the out-rolling of features. I could also take more frequent breaks during sessions (which is something I'm aiming to do anyway for health reasons).

You can also keep various developments in side branches, if you feel like working on them now, and then work towards rolling them out later. You could even consider making topics about them so people who do want to give the input can, while applying a unique tag to them (maybe something like [LONGTERM]) to indicate they're not under consideration for the immediate upcoming releases.

[WillLem]

You can also keep various developments in side branches

Yes, I could probably do with getting used to working with branches more regularly. SuperLemmix development is mostly one long branch, plus a recently-added branch with a feature I haven't managed to make much progress on.

For CE, though, branches is almost certainly a must.

applying a unique tag to them (maybe something like [LONGTERM]) to indicate they're not under consideration for the immediate upcoming releases.

This is a good idea. For now, I'll try to keep the topics to a minimum because I think that might be what's bothering some people, and I'll roll out groups of features that can be discussed in bunches, like with this topic.

Then, if something generates a fair bit of discussion, it can be broken out into its own topic with the [LONGTERM] tag if development on it needs to be delayed for any reason.

[WillLem]

Right, release what you have

Yes, let's do it! Here's the first RC build.

Also, let's agree on one (or a combination) of these going forward, to help steady the pace of CE development:

Option 1: We agree as a community on a development schedule, which I can then aim to stick to. I'd be happy to work to something that someone else draws up if that makes everyone feel a bit better about the rate of updates/progress, and then people know in advance how long they have to catch up with what's going on and provide the necessary feedback, should they wish to do so.

Option 2: We agree as a community on a feature limit per-version, which again gives me something to aim for and helps to keep the new feature set less overwhelming with each version.

Option 3: We agree as a community on feedback waiting time at the very least; I need to know how long I should wait before proceeding with anything.

[IchoTolot]

I will probably test out the first RC version this weekend.

[namida]

Right, release what you have

Yes, let's do it! Here's the first RC build.

Also, let's agree on one (or a combination) of these going forward, to help steady the pace of CE development:

Option 1: We agree as a community on a development schedule, which I can then aim to stick to. I'd be happy to work to something that someone else draws up if that makes everyone feel a bit better about the rate of updates/progress, and then people know in advance how long they have to catch up with what's going on and provide the necessary feedback, should they wish to do so.

Option 2: We agree as a community on a feature limit per-version, which again gives me something to aim for and helps to keep the new feature set less overwhelming with each version.

Option 3: We agree as a community on feedback waiting time at the very least; I need to know how long I should wait before proceeding with anything.

Option 3 should be considered regardless - at least in the form of a minimum expected timespan between RC and stable. You don't have to meet that timespan exactly; just no shorter than it. (In fact, it's probably a good idea to wait at least a couple of days longer. There's always people who leave it until the last minute.)

Option 1 isn't an awful idea, but will you stick to it? Will you have new features to justify each one? Of course, it could also be a minimum.

Option 2 is one I'd be cautious of. Certianly, consider one or two major ideas per release, but don't limit the minor stuff - I wouldn't consider counting something like "option to display the title screen panels in a single line" towards such a limit, for example. (I also wouldn't implement this option at all, but it came to mind as something that's reasonably fitting as an example here.) Rather than an arbitrary number limit, I'd suggest instead just going off feel - try to stick to just a small number of major things per update, with perhaps a few more minor ones.

If you aren't getting much feedback in the discussion topics, or if it's hard to explain / for people to understand, don't forget that experimental releases are an option too. Use these sparingly, of course, but they can be useful. (They also need not always be publicly released, for that matter. It may be worthwhile making a branch for them similar to the release / RC branches in NL's repo, so that anyone who really wants to can build it from source - and also so you can track down exactly what commit the experimental was based on if this becomes useful for investigating a bug.) There's also the option of going ahead with it in the RC and seeing how people respond to that. When all else fails, there is also always the option of revert it (or make it a setting) later.

[WillLem]

Option 3 ... You don't have to meet that timespan exactly; just no shorter than it. (In fact, it's probably a good idea to wait at least a couple of days longer ... )

Yes, erring on the side of giving more time for people to respond is a given, whatever we decide.

Option 1 isn't an awful idea, but will you stick to it?

I mean, I'll try my best to, of course! When it comes to deadlines, I'm always more likely to be working up to the last minute rather than having everything ready early. Not always, but usually.

Ironically then, having a deadline to work towards might actually slow me down! Any shrewd observers of SuperLemmix development will have noticed that I'm always putting my own self-imposed deadlines back, probably because I tend to make them quite unrealistic. With help from the community, we'd be more likely to come up with realistic and desirable deadlines which I can then aim for.

Option 1 ... Will you have new features to justify each one?

Yes, I think that for at least the first few versions the problem will be having too many and needing to spread them out evenly. Once it comes to the point where all the features that can be migrated over from SLX have been implemented, it'll just be a case of responding to new suggestions and bugfixes, for which we likely won't need a specific schedule anyway (although I'd still be open to sticking to one if that's what people would prefer).

Option 2 is one I'd be cautious of. Certianly, consider one or two major ideas per release, but don't limit the minor stuff

Yes, in all honesty I'd be less happy about Option 2 being chosen as the only way forward; it seems best when combined with one or both of the other options. It certainly makes sense to agree on some nice round number for the major features, as you've suggested (maybe no more than 3?), where minor features can be within some reasonable but not necessarily defined limit.

The only problem there is that I tend not to know what could be considered a "major" feature vs. a "minor" feature. From my point of view, something like SLX's Rewind button is a minor feature, but others may view is as a major feature due to its impact on the UI. Other features are more clear cut, like Playback Mode (obviously major) and displaying level info in the Window Caption (obviously minor), but I may need some guidance now and again if "major" features are slipping through the net as "minor" features.

here's also the option of going ahead with it in the RC and seeing how people respond to that. When all else fails, there is also always the option of revert it (or make it a setting) later.

Yes, I'm pretty sure that this is most likely what will end up happening most of the time, i.e. if feedback isn't forthcoming and/or I'd rather people test a feature before dismissing it (likely), it'll go to RC and then be removed later if it's polled out.