This engine is used for every Killemony Universe game.
In the future, I will release a public version of the engine.
Current Version v0.1.0
Features
Loading
The KUV engine comes prepackaged with a default loading screen and an option to enable/disable it. I’ll add a watermark in a future update.
Data Manager
The data manager extension handles 4 different types of data: Save data for players, leaderboards, purchases, and rewards. The data extension is also able to keep record of temporary and permanent data.
Activity
Activity tracks which phases of the game each player is in.
Course Manager
Course manager is what it says. When a client fires a course request to the server using RemoteEvent, it checks to see if the request is valid and then creates a copy of the course map for the client to access.
Lfx
Lfx is short for Lighting Effects. Lfx is effective at both universal visuals for the whole server and separating visual effects between clients. This is very useful for games that have players on different parts of the map. This is also useful for when players are playing on different courses all together.
Player-To-Player Filtering
Some games of mine have players accessing different course maps rather than accessing different parts of the SAME map. They are also programmed to overlap in the same positions as each other. In this case, a player’s client is programmed to filter out all the other players from their screen using CollisionService.
Seasonal
Seasonal is an extension that changes the game for season changes and holidays in real time. This feature programmed into games is heavily underutilized in Roblox. With the seasonal extension, it is potentially possible to change the map to way ahead of time, possibly without ever having to open the game ever again. The purpose of this feature is to attempt to create infinite feedback where updates generate traffic rather than manual.
Custom Spawns
The KUV Engine doesn’t use regular SpawnLocation instances to respawn players. Instead, it uses a complex system of parts named “Respawn”, an Unreliable RemoteEvent that fires whenever players reach spawns, and an extension module for temporarily saving players’ spawn locations. And all of this is being handle on the server side.
Triggers
Triggers are used to perform specific actions from changing the camera’s cframe to locking the player to a linear plane. Triggers have a handful of attributes that can be used simultaneously.
Interactions
There are currently 2 different types of interactions that can be chosen: “Touched” and “Proximity”.
The Interactions module is a glorified Touched event/Magnitude calculator with extra layers to single out specific objects.
Connections
Using and clearing script connections became such a cluttered mess inside scripts by themselves that I create a separate OOP module for every other module and script to use whenever it uses script connections. There’s a way to add connections, remove connections, and even clear out the queue of connections.
Notes
Highlights
The engine already uses metatables, object-oriented programming, a modular system, and maids for an easier experience.
Nearly every function uses type-checking to filter out incorrect data types in parameters.
Issues
As of now, I’m still only focused on the functionality of the engine. I haven’t gotten to the point of development where I start to optimize existing code with better techniques. The code will continue to optimize as time goes on. Some of the biggest issues at the moment are:
- Functions constantly running in order to detect certain conditions
- Type-checking is used in the engine, but type identifiers are not used alongside variable names inside parameters
- The error debugging system is in its infancy and is extremely inferior at the moment
Here is a list of games that use this engine.