Bit of short notice on this but I've been mentioning it on IRC and Slack with several key people confirmed available already. This is architecture first, GSOC second.
World time planner link - 1 pm Saturday US West, 4 pm US East, 10 pm Germany, 2.30 am Sunday India (sorry!), 8 am Australia (Sydney)
Location: #terasology on Freenode IRC (just hit the chat tab here on the site if you don't have an IRC client)
I'll be around for hours before and after for general topics like GSOC student help, maybe some play testing on @minnesotags' server for the final build candidate, and so on
Sunday March 13th is the v1.0.0 engine release. Monday is start date for GSOC student proposals.
Agenda:
This is just a formality I expect will be brief. Final chance to raise any concerns before we freeze the engine/modding API for v1.0.0 until the next major release (months away). I don't expect any concerns and realize we don't even technically need the modules super stable as that doesn't affect API.
Any more GSOC mentor volunteers?
We've got enough for two students now, but could use more just in case. I doubt we'll get a third spot but still, a few more even backup mentors would help our numbers in justifying a second slot
Note: You can volunteer as a backup mentor just to help represent, without commitment beyond checking for questions in the forum or elsewhere if you get a chance and can help. Pretty much "IRC help" level. We have two primary mentors with actual time committed.
Immediate future beyond v1.0.0
We've been doing architecture at this point for years. Time to switch gears! Releasing engine v1.0.0 and entering Alpha at the game level will be a good time to step out of stealth mode and get some attention for the game.
It'll also be a time to probably focus on a new playability milestone - currently we're missing a fair amount of simple content and expected usability features like being able to drop an inventory stack outside the inventory to drop it. Some of the remaining v1.0.0 issues will go into that milestone and they should be good material for our new contributors (not GSOC level, but maybe more challenging than simple issues)
As @Florian recently pointed out continuing to work architecture without stable content for actual players can lead to burnout, and probably has. I'd like to see if we can get some people focused on this and some issues submitted on GitHub for what we're missing for a journey to Beta and a better experience for end users.
Longer term architecture
We have several areas still pending refactoring and some potential for future options
For instance the DAG Pipeline issue has been identified as a possible new GSOC item, while also likely blocking several other items like the Oculus or far rendering items. I don't personally know what level that fits at. Would it work the same with LWJGL and LibGDX (higher level architecturally) or would any future plan to consider LibGDX waste that effort? Should it be built on Marcin's new approach instead for a v2 or even v3 engine release? Or can we refactor the current engine without a major release and just slowly improve what we have?
In the perfect world I would love to see us build a pile of awesome content on top of engine v1.0.0 including a huge Playability milestone getting us a fun game with lots of activity. Content that would then all be compatible or nearly effortlessly adjustable for a v2.0.0 engine release with some of the above improvements.
If the impact on existing content is minimal we could probably do another major release within 6-12 months. But if the impact is major it may have to wait further, or maybe we shouldn't even do it. The good news is that the engine is getting smaller and smaller with content and libs being extracted out. As always I am looking for discussion and hopefully consensus, we have better experts than I on evaluating our architectural future
World time planner link - 1 pm Saturday US West, 4 pm US East, 10 pm Germany, 2.30 am Sunday India (sorry!), 8 am Australia (Sydney)
Location: #terasology on Freenode IRC (just hit the chat tab here on the site if you don't have an IRC client)
I'll be around for hours before and after for general topics like GSOC student help, maybe some play testing on @minnesotags' server for the final build candidate, and so on
Sunday March 13th is the v1.0.0 engine release. Monday is start date for GSOC student proposals.
Agenda:
- Final check for officially releasing engine v1.0.0
- Any more GSOC mentors?
- Immediate future beyond v1.0.0 - Playability
- Longer term architecture
This is just a formality I expect will be brief. Final chance to raise any concerns before we freeze the engine/modding API for v1.0.0 until the next major release (months away). I don't expect any concerns and realize we don't even technically need the modules super stable as that doesn't affect API.
Any more GSOC mentor volunteers?
We've got enough for two students now, but could use more just in case. I doubt we'll get a third spot but still, a few more even backup mentors would help our numbers in justifying a second slot
Note: You can volunteer as a backup mentor just to help represent, without commitment beyond checking for questions in the forum or elsewhere if you get a chance and can help. Pretty much "IRC help" level. We have two primary mentors with actual time committed.
Immediate future beyond v1.0.0
We've been doing architecture at this point for years. Time to switch gears! Releasing engine v1.0.0 and entering Alpha at the game level will be a good time to step out of stealth mode and get some attention for the game.
It'll also be a time to probably focus on a new playability milestone - currently we're missing a fair amount of simple content and expected usability features like being able to drop an inventory stack outside the inventory to drop it. Some of the remaining v1.0.0 issues will go into that milestone and they should be good material for our new contributors (not GSOC level, but maybe more challenging than simple issues)
As @Florian recently pointed out continuing to work architecture without stable content for actual players can lead to burnout, and probably has. I'd like to see if we can get some people focused on this and some issues submitted on GitHub for what we're missing for a journey to Beta and a better experience for end users.
Longer term architecture
We have several areas still pending refactoring and some potential for future options
- gestalt-entity is being extracted - @Immortius is working this but with no set timeline for when it might get used for Terasology (could even get used for Destination Sol first?)
- NUI might be getting extracted and/or get an editor of some sort (a GSOC student is looking at that), and again might get applied to Destination Sol. Exactly how much gets extracted?
- Finishing CoreRegistry -> Context? Extract it? Do any libs need it? Where does it go?
- Rendering still needs an overhaul. @manu3d has slowly refactored away but we need cleaner overall architecture like the DAG Pipeline approach. We have several GSOC students interested in this or issues that depend on it (like refreshed Oculus support)
- @Marcin Sciesinski has reappeared out of nowhere with shiny toys as he tends to do from time to time: an incubating LibGDX-based re-envisioning of Terasology's base engine, with assorted tweaks to the entity system and rendering. Main highlight: not a repeatedly refactored engine that started as a tech demo.
For instance the DAG Pipeline issue has been identified as a possible new GSOC item, while also likely blocking several other items like the Oculus or far rendering items. I don't personally know what level that fits at. Would it work the same with LWJGL and LibGDX (higher level architecturally) or would any future plan to consider LibGDX waste that effort? Should it be built on Marcin's new approach instead for a v2 or even v3 engine release? Or can we refactor the current engine without a major release and just slowly improve what we have?
In the perfect world I would love to see us build a pile of awesome content on top of engine v1.0.0 including a huge Playability milestone getting us a fun game with lots of activity. Content that would then all be compatible or nearly effortlessly adjustable for a v2.0.0 engine release with some of the above improvements.
If the impact on existing content is minimal we could probably do another major release within 6-12 months. But if the impact is major it may have to wait further, or maybe we shouldn't even do it. The good news is that the engine is getting smaller and smaller with content and libs being extracted out. As always I am looking for discussion and hopefully consensus, we have better experts than I on evaluating our architectural future
Last edited: