Client Based Effect Architecture help

Help and Feedback Scripting Support
1

Hello, I have been wondering how to make a efficient, readable, clean architecture for effects.
My current Architecture works as such

THE PHILOSOPHY OF THIS SYSTEM IS TO HAVE ALL EFFECTS VISUALLY MADE ON THE CLIENT TO PREVENT THIS LOAD BEING DUMPED ONTO THE SERVER

The issue is how to improve this effect system in order to make it more readable, debugable, but most importantly, to make it more optimized and take up less memory; this system works awfully in regards to simple effects such as some particles; however, I want this to be a universal system for all effects.

Server requests effect > EffectId generated > Remote and Dump folders are created, remotes created automatically; Effect pointer instance is created for remote interaction with client > The two folders and effect pointer are stored in a cache

Server requests effect > Client recieves effectId, remote Folder and dumpFolder > Client creates effect runtime instance that acts as a wrapper for effect code to provide cleanup and easy remote access.

Server Requests Termination / Client requests termination > Server has effect pointer destroyed, and the Client has its EffectRuntimeInstance Destroyed.

As for each effect module, each effect is a object that inherits from the base effect object.
On the client, there is the run code to prevent memory buildup on the server. On both sides, there is a table of remotes, the effect name, and other data

As for the effect id, it is some random id for each effect ran; There can be two ids for two running fire effects

As for the effect code, it is as such
function (effectRuntimeInstance, ...) end

The effect runtime instance offers the methods as such

local EffectRuntimeInstance = {}
function EffectRuntimeInstance:InsertIntoDump(...) end
function EffectRuntimeInstance:Fire(remote, ...)
function EffectRuntimeInstance:ConnectTo(remote, conn) end
function EffectRuntimeInstance:Cleanup() end -- clears all connections

The effect pointer is similar, but has no “InsertIntoDump” as the server dose NOT manage the actual visual effect to be seen

My other miscellaneous concern is how to avoid over engineering code

1 Like
2

This is just my opinion on it but there’s no real need to over complicate it like that. For my client sided effects structure its pretty simple. You fire client(s) with the parameters for the effect then a local script uses a function from the effect module (a module with all the effects in it). Then simply use maids to cleanup after everything. No need for anymore than that really, unless you are going for something very grand in scale. Tell me if I’m miss understanding something but I’m pretty sure you could easily remove and simplify a bunch of that code.

3 Likes
3

I guess instead of making wrappers, I can go for two classes of effects, complex and simple.
The complex effects require client server communication whilst the simple effects will handle themselves on their own. As for the wrappers such as the effect pointer/effect runtime instance, I can probably rid those, and make the complex effects objects of their own rather than a simple function. As for replication, this can be done with RunService:IsClient() etc… when dealing with client/server segments of the code.
Anyways, in summary, thank you for the tip

1 Like