nobledraconian / dragon-engine

Universal framework for Roblox games.

👨‍💻 About me

Game developer on Roblox, currently running the startup Phoenix Entertainment. I have roughly 9 years of programming experience, mostly working in Lua.

🏆 GameDev Achievements 🏆

• 2020 Bloxy Winner for "Best Live Event"
• RDC 2020 gamejam winner for "Most Creative Gameplay" (https://github.com/NobleDraconian/Gamejam-2020)
• RDC 2021 gamejam winner for "Best use of theme" (https://github.com/NobleDraconian/Gamejam-2021)

🛠️ Projects

Dragon Engine

Dragon Engine is a framework for Roblox games that follows a microservice architecture, with a built-in module loader with run-time dependency resolution capabilities.

📫 Contact information:

Email : Accessible on the left side!

Discord : Noble_Draconian#0001

Twitter : https://twitter.com/Noble_Draconian

Statistics

dragon-engine's Issues

There should be an option to suppress ALL output from the framework

Currently, as of v0.1.0-rc.4, there is no way to suppress all output from the framework. Alongside disabling the Debug option, there should be another option to remove any and all output that the framework sends to the code logs.

Modules should be able to be auto-initialized with an Init() method

Currently, the framework has no way of auto-initializing modules it loads. If modules have an API method named Init(), the framework should automatically call that method to initialize the module.

This is useful in cases where a shared module wants access to framework resources.

Access to Cmdr is denied in studio

Currently, EngineDebugService doesn't account for handling permissions when testing a given project in studio, so it denies the developer access to the Cmdr terminal while testing in studio.

This can easily be fixed by checking RunService:IsStudio() and acting accordingly.

There should be server -> client RemoteFunction support

Currently, it is not possible to have client-sided methods that are invoked from the server via RemoteFunctions. Having a feature that allows this to occur would be useful for niche cases where the server wants to know about information that is on the client. An example of this would be in a melee combat system with a block mechanic, for responsiveness purposes the client would be the source of truth for a block's state. When another player attacks, the server would need to ask the client that is being attacked if they are blocking or not. This is doable with Server -> Client RemoteFunctions.

There could be a method on the server called RegisterClientEndpoint or somesuch, where it'll register a Server -> Client RemoteFunction that clients can 'listen' to, and the server can invoke.
It should be noted that an API method like this should be on the server only, for security reasons. A server should only be invoking client methods it knows about contextually. Clients should not be able to register arbitrary methods that the server can execute.

This method would be similar to how clients register client-facing server methods, but in reverse.

APIs are needed to cover cases where microservices depend on other microservices

Currently, as of v0.1.0-rc.6, it is impossible to have complex microservice dependencies. If microservice A depends on microservice B, and microservice B depends on microservice C, there is no way for each respective microservice to wait for the microservices that it depends on to be running. There should be APIs to allow for this type of behavior to happen.

Real world use-case:
CameraController depends on PlayerController:GetSetting("CameraLockedToMouse"), which depends on DataController:GetData().

In this case, since all services have Start() called in a non-specific order, the reference to DataController is not guaranteed to exist when PlayerController:GetSetting() is called, since PlayerController has only been initialized so far:

function PlayerController:GetSetting(SettingName)
	local PlayerData = DataController:GetData(true)

	return PlayerData.Settings[SettingName].Value
end

function PlayerController:Start()
	self:DebugLog("[Player Controller] Started!")

	DataController = self:GetController("DataController")
end

In this scenario, DataController will have to be fully running first, then PlayerController, and then CameraController.

Perhaps there should be some sort of config option that lets microservices specify their dependencies, and the framework will then calculate the order in which to load & run the microservices? E.g. CameraController specifies that it depends on a controller named "PlayerController", and PlayerController specifies that it depends on a controller named "DataController". The framework gets all of this information, and then loads everything sequentially, in the specified order.

Dependabot couldn't find the submodule /Submodules/.gitmodules

Dependabot couldn't find a .gitmodules for this project.

Dependabot requires a .gitmodules to evaluate your project's current Git dependencies. It had expected to find one at the path: /Submodules/.gitmodules.

If this isn't a Git project, or if it is a library, you may wish to disable updates for it from within Dependabot.

You can mention @dependabot in the comments below to contact the Dependabot team.

SecurityService should encrypt RemoteEvent/RemoteFunction names via GUID

Currently, remote's names are not encrypted, making them easier to target by exploiters. SecurityService should encrypt RemoteEvent/RemoteFunction names via HttpService:GenerateGUID() to make it harder for exploiters to determine which remote does what.

I'm not entirely sure how I'm going to pass remote names on to the client though - this will need some more planning before it can be implemented.

Dependabot couldn't find the submodule lib

Dependabot couldn't find the submodule lib. Perhaps it isn't committed, or isn't a submodule?

You can mention @dependabot in the comments below to contact the Dependabot team.

Documentation site is broken (404)

Client events for services are not being created

If a client event is created for a service, but the service has no endpoints/client-facing methods, the client event will not be created properly. This occurs because a service with no endpoints does not get a folder created for it in the internal network folder that contains all of the remotes for services.

Specifying developer-specific settings feels messy

Right now, the framework looks for a hard-coded folder in game.ReplicatedStorage named "DragonEngine_UserSettings", this isn't an ideal way to let a developer specify their configurations for the framework.
The code that merges the default settings and developer settings is also a bit buggy, in some situations the settings aren't merged properly.

I plan to redo how settings are loaded and specified.
A few initial ideas I had:

• Perhaps settings should be specified via some API?
• Perhaps fire a 'FrameworkLoaded' event or somesuch to tell the developer when to load their own configs? Downside to this : Loading is a bit slower as the developer's modules will be loaded AFTER the framework loads its own internal modules. This can result in a few extra seconds of loading time for the game, which isn't that great.

API for client -> server RemoteEvents is needed

Currently, there is no way to register a service remote event that clients can fire. Usecases include things like character sound replication, custom character state change events, etc. An API method is needed for this. It could look something like DragonEngine:RegisterServiceClientInvokableEvent() or somesuch. This API method would return the generated remote event, which would be parented under a new folder under the service's folder in ReplicatedStorage, called "ClientInvokableEvents" or something similiar. On the client, these events would be stored in the service's table, e.g. AvatarService.ReplicateSound = <RemoteEvent>. From there, a client sided script can fire the event to the server via ServiceName.EventName:FireServer().

Framework client should not rely on `<Player>.PlayerScripts` and should use `StarterPlayer.StarterPlayerScripts` instead

Currently, as of v0.1.0-rc.4 the framework's client relies on reading from & parenting things to <Player>.PlayerScripts. While a standard practice, this prevents it from working properly in a unit testing environment via run-in-roblox. It should be able to directly use StarterPlayerScripts on the client to allow for it to be used in the context of unit testing.

Dependabot couldn't find the branch Dev

Dependabot was set up to create pull requests against the branch Dev, but couldn't find it.

If the branch has been permanently deleted you can update Dependabot's target branch from your dashboard.

You can mention @dependabot in the comments below to contact the Dependabot team.

Don't set name properties in rojo config files

Currently, the rojo config files for this framework are assigning names to the framework's folders via the Name property. This causes rojo to duplicate folders when live-syncing into a place file.

The Name property should not be assigned in the config files.

Dragon-Engine/shared.project.json

Lines 7 to 9 in 68ffcf2

	"$properties" : {
	"Name" : "DragonEngine"
	},

Dragon-Engine/server.project.json

Lines 7 to 9 in 68ffcf2

	"$properties" : {
	"Name" : "DragonEngine"
	}

Dragon-Engine/client.project.json

Lines 7 to 9 in 68ffcf2

	"$properties" : {
	"Name" : "DragonEngine"
	}

Framework core scripts should be converted into modulescripts

Currently, as of v0.1.0-rc.4, the framework automatically runs when the server or client starts via Script and LocalScript instances. The core of the framework should be converted into being 2 ModuleScript instances. This makes it possible for the consumer of the framework to:

• Explicitly execute the framework when they want
• Unit test their project's systems that have dependencies on this framework if they are using run-in-roblox, since they can now do the above in the single script instance that run-in-roblox runs
• Only execute the server side of the framework if the client side isn't needed

'Stop' and 'Unload' methods should be optional in Services/Controllers

The methods Stop and Unload shouldn't be required for Services and Controllers, rather they should be optional.

If Stop is called on a service/controller, but the method is not present, the framework will spit an error saying something along the lines of "Service/Controller is not able to be stopped".

Same thing applies with Unload being called on a service/controller that does not have the method.

Framework errors should be handled with `xpcall` instead of `pcall`

Currently, as of v2.0.0, the framework handles its errors through pcall instead of xpcall. It should use xpcall, as it preserves stack traces properly, which makes debugging easier.

Un-needed services/controllers should be removed

Currently, as of v0.1.0-rc.4, there are a few services and controllers that come packaged with the framework by default, when they do not need to be. They are extra bulk that don't serve much of a purpose, and as such, should be removed.