Add path to 1.0 document

[FredrikNoren]

@Pombal @philpax @pierd @ten3roberts @chaosprint @droqen let's discuss this here. I just laid out an idea for a rough outline in the doc here. I think we should try to commit to a list of accomplishable things that lead to 1.0; of course if we discover things along the way we might need to revise that list, but at least it'll give us a roadmap to what's needed.

Also, post-1.0 doesn't mean we stop iterating; it just means it will be heavier to make big, broad changes because we'll have to maintain more backwards compatibility and support for people to migrate. I.e. there will be lots of things that won't be "done" in time for 1.0, but if we wait for everything to be "done" we'll never be able to start providing a stable version.

[philpax]

Additional suggestions:

From the roadmap in the README:

• multithreading logic
• asset hotreloading
• ECS save/load

From old documentation:

• collaborative editor
• additional platform support
• particle system
• post-processing

From my personal issue roundup:

• more control over the physics engine
• more procedural assets
• more language support [I feel like we should have this figured out - at least viability / implementation - before we go 0.1]
• prediction etc

There's more but I'll mention them as I think of them. These aren't "these should be done by 1.0", more bringing them up for discussion so we can decide.

[Pombal]

Adding to the "bringing them up for discussion" pile:

• collaborative open world building tools
• fast hot reload across multiple platforms (make a change on desktop, see change on web)
• performant physics on the web
• gameplay helpers: navigation, path finding, behaviour trees, etc
• video playback
• integrated developer tools (profiling, memory, state debugging)
• antialiasing

[droqen]

In terms of working out the kinks, I think multiple games (of multiple types/genres) will be made. Not sure whether that bears mentioning in the 1.0, as I agree with the end goal of one medium-sized game that sort of 'proves' the kinks have been worked out. Just noting that, under the hood, this will mean a broad variety of working experiments as well.

Practically speaking, I'm not sure what will be easy or hard to vary later on, but that should probably be the priority in terms of reaching 1.0, right? Other stuff that can be additive can be... well... added easily, later on. (For example, Antialiasing does not seem like it's going to break things down the line and it could just be added in 1.1 or 1.5.2 or 2.0 without consequence? But also, I really don't know much about rendering tech so I could be very wrong about that)

The most important to me is reaching a place where I have a comfortable package interoperation workflow, such that I don't want it to change and I trust I'll be able to encapsulate larger and larger systems in neat little packages that can be added to a wide variety of projects, facilitating modular and quick development.

[chaosprint]

• Fire
• Smoke
• EQ
• Reverb

[Pombal]

@droqen If 1.0 is viewed as just a compatibility guarantee, I agree.
But if users view it as a measure of maturity for creating great experiences, then more will be expected.

For reference, Unreal 1 was good enough to create Unreal Tournament and the first release of Unity was announced at Apples's WWDC.

We don't have to compare or do the same but I think we could look at 1.0 also through the lens of what quality experiences can we create with it and what's the bar for 1.0 for a modern engine.

With that said, I understand we have to make tradeoffs and I would also take packaging workflows guaratees over AA any day :)

[droqen]

@Pombal That makes a lot of sense! Did not mean to pit antialiasing and package workflow against each other btw, kinda an unfair fight ;)

I'm very interested in what we want 1.0 to ultimately mean or do on top of the mere compatibility guarantee. The examples you've described are really inspiring, helpful for pulling me out of the bubble of just what it means functionality-wise!

[philpax]

From a discussion in the office:

• What kinds of games do we want built on 1.0, and what do we need for those?

• Fredrik and I agree that we want to enable the kind of energy/technology confluence that led to the explosion of mods-to-games in the 2000s and early 2010s - Warcraft 3 being modded into Dota, Arma -> DayZ -> DayZ BR -> PUBG, etc.

• What does the ecosystem look like for 1.0, and what will packages be able to do?

  We've been discussing inversion-of-control, where the entrypoint to your game actually sets up the ECS + renderer + etc, but I fear that may fracture the ecosystem, even if it would give the users ultimate control. Is that something we should strive for in 1.0?