Problem

The Solaris editor will need to transition between the following states:

Play

• GameBehaviour onUpdate and onStart
• GameObject introspection is enabled (through command #12)

Edit

• Player head icons are visible
• Gizmos are visible
• GameObject introspection is enabled (through right-clicking heads or command #12)

Debug

• GameBehaviour onUpdate and onStart
• Gizmos are visible
• GameObject introspection is enabled (through command #12)

Solution

Using kotlin MobX listen to changes from a StateManager singleton instance. Then create an abstract class called StateListener which will abstract the methods onStateChange(state), onStatePlay, onStateEdit and onStateDebug. Any class which extends this class will be able to make use of these state changes by implemented the aforementioned abstract methods.

Requirements

TODO

This is when a GameBehaviour dynamically creates a GameObject instance and instantiates it at runtime at X location. By default, a GameObject should instantiate at 0,0,0. Stacking will need to be implemented for this to work nicely (#7).

• When NBT data is created, a flag needs to be set eg. (isRuntime)
  On state change to anything but PlayMode the following needs to occur:
• Search all locations and remove classes and data with isRuntime true

Problem

There must be a way to flag a build for production. Doing so will remove / strip code that is not necessarily related to being run in production. Production mode will also put all GameObject instances on all maps into Play mode indefinitely

Solution

This will require some more research but since it's related to the build, some more advanced Gradle logic or a plugin may be required.

Problem

There needs to be a way to easily inspect all objects in the entity pool at run time

Solution

Create a command eg. /map introspection which will open up a chest GUI that has links to all active running GameObjects in the entity pool

Problem

GUI for changing Float, Double, String, Int... So on

Solution

Requirements

Create interfaces for common events (on GameObject) eg. Player break block... only register those events if class method is overridden (using class path analysis)

Might allow this... need to consider a good use case. Players can get by simply placing 'Managers' underneath the map or somewhere they know they can go to inspect them. Went with an OOP oriented ECS so location is and should always be present

A global state is when a class is present in all maps, it needs to

• Instantiate itself on the map it's placed on
• Check for a flag (eg. doNotKillOnMapChange) and prevent killing when changing maps
• It will NOT instantiate itself on other maps

Behaviors may pass a @GameProperty that is a requesting reference to another GameObject or its Behaviour.

• Option to set a reference in GUI
• GameObject type will filter by all GameObjects in the Map
• A subtype of GameObject will filter by that type
• (optional) GameBehaviour will require selecting a GameObject with a GameBehaviour of x subtype

Behaviors may pass a @GameProperty that is a requesting reference to another GameObject or its Behaviour.

• Option to set a reference in GUI
• GameObject type will filter by all GameObjects in the Map
• A subtype of GameObject will filter by that type
• (optional) GameBehaviour will require selecting a GameObject with a GameBehaviour of x subtype

Problem

Unfortunately, there are a lot of workarounds to get an engine like this working smoothly. However, there is no way to know what persistent changes the player has made when in play mode. For example; say a GameBehaviour spawns 10 zombies, when we transition back to Edit mode, there's nothing to say that those zombies should be removed.

Solution

An extra required abstract method is to be implemented on GameBehaviour called onCleanUp. It will be called anytime we transition away from Play mode. Developers will need to put clean-up logic here to have a better debugging experience.

Requirements

TODO

Problem

For the engine to actually function, it needs to run certain methods at certain times when the StateManager transitions to Play, Edit or Debug.

Solution

To start there will need to be some optional abstract methods like onStart and onUpdate. onStart will be run as soon as PlayMode is active and onUpdate will be run every tick. onUpdate is a matter of contention because it's not necessarily a good idea to have things running every tick. In which case we'll leave it up to the developer and maybe even allow them to change the tick/update rate (eg. onUpdate runs every 3 ticks).

When PlayMode starts we will also need to clear the entity pool and instantiate classes from scratch using their overrides. When exiting PlayMode these classes will need to be purged from the entity pool again. This is so runtime changes don't pass into other states

Requirements

• Implement an abstract method called 'onStart' on GameBehaviour
• Implement an abstract method called 'onUpdate' on GameBehaviour
• Implement a bootstrap method on MapManager; this will purge the entity pool and instantiate all game objects using their overrides
• Implement a protected method called start and stop on GameObject; Start is called during Debug and Start states while stop is called when entering the Edit State. start will run onStart and initialize onUpdate for each behavior. stop will run each behavior's cleanup method. Each state change will call MapManager's bootstrap
• Research if creating a bukkit scheduler on tick that doesn't do anything is performant
• Make it so that a bukkit scheduler is only started if the onUpdate method has been implemented

Problem

It should be possible to have multiple GameObjects at a single XYZ coordinate.

Solution

When a player stacks a GameObject by either dynamically instantiating (#6) or placing a prefab on an existing object the following should occur:

• The GameObject will change it's head icon to a group icon
• Right-clicking will open up a gui from which you can select or remove the stacked objects
• A check is made before placing a game object if there is an existing object at X,X,X and then appends it's data to the NBT block

Requirements

TODO