ettmetal / replicator Goto Github PK

With the release of 2019.3, upm brings integrated git package support. This makes using packages, at least outside the asset store simple.

pros

• Installing is easier, no need to download / track the .unitypackage file
• Updating can be handled by the Unity editor's integrated upm tools
• Testing is integrated into upm packages

cons

• Before 2019.3, installing via upm requires an add-on for GUI or manual manifest editing
• upm packages can't be loaded into Unity by themselves, they require a project (the repo would not contain everything needed to work on Replicator)
• .asmdef structure is required, meaning Replicator will make projects which use it depend on that system

For me, one of the biggest blockers is the .asmdef use. In some projects, it's not necessarily beneficial to have many modules in that architecture. With the integration of git upm packages in Unity 2019.3, it makes sense as a distribution mode, especially given that updating may be handled by that system, and git url's allow for very configurable version targeting.

All in, I think the best move is to retain the repository as a full project, and use a script to push to a upm-specific branch. This could also mean the possibility of retaining .unitypackage releases (for now, at least).

It's better to be tidier, so instead of leaving object pools at the root level, they should be grouped into an object pools sub-menu

If a VariantPool's pool for the base variant is empty, it will prevent the spawning of any other variants. VariantPools should allow any of the available variants to be spawned.

This is because VariantPool does not override the hasAvailableSpawnees method, meaning the availability of pooled objects is entirely determined by the availability of the base variant in VariantPools.

Currently, there is no way to manually pre-place an object from a pool in a scene, meaning that pooled objects can only be spawned via scripting. It might be nice to have the capability of pre-positioning some objects which will be pooled once the game is running.

A feature I've seen in another pooling system, pool culling is the ability for pools which have grown to remove instances later.

This can help with burst spawn needs, allowing most cases to be covered by the pooled instances, with burst needs covered by instances created on expansion but then freeing those instances later.

Instance culling should be gradual where possible to avoid GC spikes.

Proposal for a new pool type, similar to multi-pools, where spawned instances are chosen sequentially, rather than randomly.

Each time a call to Spawn is made, the sequential pool would return an instance from the pool which is next in the order set in the inspector, skipping any pools which do not have instances available. As with other pools, Spawn would return null in the event that there were no available instances.

The objective of using object pools is to reduce runtime instantiation, but the current default behaviour of Replicator pools does not reflect that.

By default, replicator pools will not preload any objects unless the developer has provided a value for preload. To be more in line with the objectives of object pooling, I think that this should be changed so that, without intervention, the default behaviour of Replicator pools would be to preload all objects in the pool.

Although pools are ScriptableObjects, and as such can be created at runtime, they are currently unable to be set-up at runtime.

Their key parameters are stored in private fields, and there are no initialisation methods available - pools were initially designed to be created at edit-time only.

The need for pools may not occur until later in the application's lifecycle, and allowing pools to be created programmatically would add flexibility for client code. It would probably need to be accompanied by a warning, as initialising a pool that needs to create many instances could cause frame hitches.

Currently, inactive pooled objects are hidden from the hierarchy - this is in an attempt to de-clutter the hierarchy view in case there are many pooled objects.

While de-cluttering is a fine goal, it might be nice to make inactive objects visible, for whatever reason, e.g. debugging.

I propose implementing it as a per-pool toggle, but immutable at runtime, although I don't foresee any major incompatibilities with having runtime toggle enabled.

Manually copying the documentation to the wiki is prone to error. As the source already includes xml comments, documentation building should be automated.

The number of scripts is growing, it'd be good to organise them for more sanity.

As the objective of object pooling is to prevent, as much as possible, runtime instantiations, perhaps the current behaviour of allowing pools to expand infinitely by default is unwise.

There could be a hard limit on the size of a given pool, as part of its configuration. Although the pool would be allowed to grow in accordance with its growth strategy, it would not be permitted to grow past this hard cap.