Archived Alpha

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
#1
This has been heavily updated with a new approach - will aim to get that validated at the upcoming meeting.
  • ALPHA definition = Game is relatively stable from the user's perspective. Most breaking or visually jarring changes that have a user impact should be out of the way when we declare ourselves in Alpha. No guarantee against world-breaking changes still
  • BETA definition = Game is relatively stable even from a developer's perspective. Architecture is solid and any breaking back-end changes should be out of the way. Most expected modding functionality in place. Best effort in avoiding further world-breaking changes.
Beyond that an actual 1.0 release would primarily contain lots of polish and content on top of the Beta. Following the intent of SemVer we'd push out additional breaking changes or major overhauls to a future 2.0 release. Example: Adopting LibGDX which probably shouldn't be a focus for 1.0. Eternal disclaimer: Unless somebody really feels like doing it and commits to the effort ;)

2.0 wouldn't be a sequel or anything like that, it is simply another release. Think Firefox/Chrome release approach - could be several major releases in a year, although I somewhat doubt that level of speed since we're still all-volunteer!

On a somewhat related note Launcher v2.0 might correspond with game alpha or beta when module tracking / auto downloading gets ready

Onwards to the edited Alpha MoSCoW with the WOULD section actually being what could wait till Beta (but of course would be great in Alpha if it happens)

MUST

Architecture
  • Major breaking changes
    • Vertical chunks - in good shape
    • World Gen rework, since we need trees working again after vertical chunks. In progress.
      • Will include some work on updating the AnotherWorld module
    • Higher level GameType/Mod support
  • Headless server improvements
    • More command line / config file setup support (seed, modules, world type, etc - some currently working via Gradle)
      • We've got a permissions system now, could use a file for declaring admins etc (and/or whitelist)
    • Ability to load existing worlds
    • Squish world persistence bugs (not everything is saving right)
  • Further work on the asset system to remove AssetType and allow new asset types to be added by modules
  • Camera as a component
  • Modules config framework
  • Sending events to prefabs
  • In-game saving / auto-saving / graceful world state in case of crash
Content
  • More mature AI system (@synopia is working on a 2.0 of Behavior Trees)
    • Behavior trees more usable by mere mortals
      • @Florian got a new node working to path around deer idly. Maybe we just need a guide?
    • Proper flow from high level goals ("Start a colony") through intermediate targets (gather x, y, and z to be ready) to minimal steps (like BT nodes)
    • Some sort of neutral creature brain (like for animals) - started
  • At least one replayable game type stable - work on others can continue but go stable with beta
Logistics - see also the logistics arc thread
  • Versioning & releasing of modules
    • Most the footwork has been done here. Very close!
  • Applet working again (almost there!)
  • Publishing game download automatically to GitHub
  • Gooey v2.0 - integration with Jenkins and GitHub for easier module maintenance
SHOULD
  • Better forum organizing (fully implement thread prefixes, for instance)
    • Partially done, mainly need to go over existing threads and classify
  • Better graphics options in-game
    • Some have been done. More requested in #1144
  • Improved override functionality + verify fully functional (we may already be there). Need to add good examples and doc
  • Sort out key binding conflicts better (might be same as the MUST on module config)
COULD
  • Proper music director system + official sound track in-game - see #1091, need a volunteer and an incubator
  • Adjust (most) existing world generators to work with new world gen framework (not necessarily taking advantage of the new arbitrary world height yet)
  • Documentation. Insert appropriate priority joke here
  • More tutorials
    • Got initial world gen and inventory/interaction tutorials!
  • Floating player name tags in multiplayer
  • Actual player model for multi (beyond the monkey head)
  • Updated block picker (tabbed!) for free-style (getting close)
WOULD (BETA or later)
  • Translation framework ? See also the separate thread
    • Weblate is now in place for the Launcher, so good progress
    • Initial work for using it for the game menu is also set up
  • Billboard rendering via BillboardComponent + System.
  • Block rework, both on the definition end to be more like prefabs and a review of how they are handled in game (maybe some optimisation).
  • TeraMath (changing math libraries is a breaking change) - might be done by the time you read this, PR awaiting merge
  • Liquids as non-blocks
  • Multi-world support
  • Prefab improvements around inlining sub-prefabs
  • Support for blocks that have different shape/appearance/collision depending on immediately surrounding blocks.
  • Support for procedural block textures via tile slot reservation and addition
  • Mode Zero Distro Iota setup / packaging / mod tracking site (big separate topic)
    • Working Distros in Jenkins, need to support in Launcher and improve further
  • Sort out supporting / optional module dependencies / enhancements
  • Enhance world generators to take advantage of arbitrary height / world surface calculations / other new world gen framework features
    • Would be great to get the few features back that we lost in Perlin with the facet refactor
  • Code package naming review (not user visible so could wait till Beta - sooner is better though)
  • Gestalt (splitting engine into more libraries)
    • One done, one in progress, ? more
  • Saved world versioning (for offering a way to convert worlds past breaking changes)
Multiplayer improvements (would/beta):
  • Server console (beyond players being able to use the in-game console - a prompt for the headless server, or at least a capture of CTRL-C to force a graceful shutdown)
  • Simple server security (whitelist? Even if you could easily spoof one it's a start)
    • Permissions are in place. No whitelist yet and kickUser crashes the server :D
  • Monitoring tools
  • Server browser / server stat discovery
  • General polish
Rough goal dates: Alpha by September could be a neat way to celebrate our 3rd birthday, but may be a tad ambitious. Beta sometime next year.
 
Last edited:

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
#3
I would add "unreal dreams": translation friendly ;)
Good point, and well put - we do need a translation framework sooner or later. Unsure when, but at least added it to the list :)

Edit: A few internationalization posts were split out into a separate thread
 

Immortius

Lead Software Architect
Contributor
Architecture
GUI
#4
Been meaning to get something like this posted. What should be done before we could consider Terasology alpha ready? First rough draft below in MoSCoW style (channeling UberWaffe here - still owe a reply there since October, eep), feedback away!

MUST


Architecture
  • Any major breaking changes must be done for stability reasons. Minor can be done later, especially if we put in a little extra effort to support some way to maintain compatibility (but I suppose then that wouldn't be "breaking" anymore ...)
    • Vertical chunks (well under way)
    • Block overhaul to prefabs ?
    • TeraMath ? Might be lower priority
  • Headless server improvements
    • Full command line setup support (seed, modules, world type, etc - some working via Gradle)
    • Ability to load existing worlds (and most persistence bugs squashed)
  • World gen structure updates
  • Updated liquid system
Architecturally, what I feel is needed to be generally feature complete are:

The things you've said:
  • Vertical chunks
  • Block rework, both on the definition end to be more like prefabs and a review of how they are handled in game (maybe some optimisation).
  • TeraMath (since changing math libraries is a breaking change)
  • World Gen rework, since we need trees working again after vertical chunks
  • Liquids as non-blocks
And some additional things:
  • Further work on the asset system to remove AssetType and allow new asset types to be added by modules
  • Prefab improvements around inlining sub-prefabs
  • Camera as a component
  • Multi-world support
  • Higher level GameType/Mod support
  • Modules config framework
  • Support for blocks that have different shape/appearance/collision depending on immediately surrounding blocks.
  • Sending events to prefabs
  • Ingame saving
Probably longer term (post alpha):
  • Support for procedural block textures via tile slot reservation and addition
  • Billboard rendering via BillboardComponent + System.
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
#5
Thanks! Edited all that in, shuffled into categories somewhat :)

Might cause some more GitHub spam tomorrow with more alpha issues. Although all those extra items make me question September more :coffee:
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
#6
Bump - put some stuff in italics to suggest what could be pushed out past when this milestone/incubator could be considered complete (mainly just so we can say we completed something). The next thing after might be beta, with some of the minor but potentially breaking things required to be finished before we consider ourselves in beta.

I got into thinking that libGDX / Android could be a decent goal for a next major release (2.0). After all we don't need to complete all the things! by the time we consider Terasology "stable" and playable normally. It can be nice to actually release, then just keep working and release more major releases (note: not same thing as sequels - still same game) now and then :)
 

Mike Kienenberger

Active Member
Contributor
Architecture
GUI
#7
What about a general review of our engine packages? Just before we go alpha, I think it would make sense to review the entire existing package layout and see what should be changed now that all code is in place.

-- Identify things that should be moved into a module
-- Make sure engine-subsystem specific classes are in the sub-system
-- Make sure the public api and the internal api are in separate obvious packages
-- Review package names and organization of the things in them
 

Immortius

Lead Software Architect
Contributor
Architecture
GUI
#8
I'ld also like a chance to split engine features out into separate libraries, but that can happen post-alpha.
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
#9
Overhauled the first post some, making an alpha/beta split more clear (and with definitions!) with less stuff in Alpha. Could probably even make it fewer still - some of the mystery items I don't know if would fit better with the alpha definition or beta :)

Immortius - do you think Gestalt should be aimed at Beta or a 2.0 release? Thoughts on the first post overhaul and some of the mystery architecture items still listed in Alpha that haven't been started yet? Or stuff from Beta that really should be Alpha ?