Programming Suggesstions & Advice for JoJo Flames of Conflict

Bulletin Board
1

  1. I’ve seen a bit of the video talking about the internals of the game (though not all of it). So, something very important about these things is to NOT overly rely on instances or anything from inside the DataModel and ESPECIALLY on instances that are by nature unreliable (Player Characters for example). Overreliance of instances can very easily break things around due to a LARGE list of factors. Sure, you have control over instances but NOWHERE NEAR what the actual engine does. The engine CAN and WILL mess with instances under random and/or specific circumstances. Remember, the engine controls replication, streaming, physics and whenever or not those instances exist at all. Not anyone else. And secondly, overreliance on instances can very easily destroy performance HARD. Check the microprofiler logs of most anime games and you’ll quickly see how many unnecessary things they perform for no reason at all. Documentation for the microprofiler.

  2. Performance. Many anime games suffers from performance issues one way or another. Either the server is chugging along due to poor code, or the client is dying trying to render a million unnecessary things or trying to compute random crap. Focus on it. Performance should be a big priority of ANY game especially if you want the game to be as accessible as possible. And trust me, don’t underestimate the kind of low end hardware (or decent phones) some people can run. Those can actually be one of the most loyal players. Here’s a couple tips for keeping performance high.

    1. Reduced DataModel overreliance (as previously stated)
    2. Avoid repeated reads/writes for the same values/properties.
    3. Cache cache cache. Most things can be cached to save quite a bit of performance.
    4. Cache instances! This is a bit different from point 3. The idea here is that parts should be cached whenever possible instead of creating/cloning new ones every time. Destruction debris can take advantage of this.
    5. Functions should ONLY be ran when they are specifically needed. Signals can help with this.
    6. Avoid utilizing tons of redundant instances. Whenever possible, compress instance counts by merging/combining parts or by simply using fewer by default.
    7. Not everything needs to render shadows. Disable shadow rendering for small/thin objects that can barely generate a shadow as is.
    8. Disable collisions for objects inside other objects. You can save a decent bit of cpu resources by simply disabling all collisions on parts that realistically have no real use for.
    9. Not everything needs to be made out of parts. You can use WAY more simplified meshes for buildings and props that remove unseen faces/triangles.
    10. If you plan in using all of the provided lighting toys then do know that not every light source needs to render a shadow. If the light source is small enough or if not many things can even get shadowed then its probably not worth it to let it keep computing shadows.
    11. Avoid using a million individual transparent objects. Batch them into fewer instances whenever possible. GPUs don’t like a ton of transparent objects.
    12. The client does not need to be aware of any and all stored instances. Give the client as little as possible to keep memory usage down.
    13. Design your game around rendering budgets (How many triangles should the player view AT MAX? 250k? 500k? 1 million? The bigger the number, the lesser performance but higher visual fidelity).
    14. When creating new instances, its best you simply CLONE from a template instance. Cloning is WAY faster than creating new instances from scratch.

  3. Bandwidth. There are MANY cases of games who send obscene amounts of data to the client every second. Compress any data whenever possible. Try sending as little data as possible. A interesting way to compress data is to simply send VERY short and simple ID’s that point to to a very common value instead. One example of this can be to simply send the ID of lets say “c” as the representation of a 30 second skill cooldown to the client. (The client needs to be aware that said 30 second cooldown is what that ID “c” actually is). Expect people with connections of 5-20 MPBS. Do not design your game around 100+ MBPS connections. Do that and you’ll make your game mobile proof.

  4. Security. Game security on a general level isn’t very hard. Use common sense and basic logic and you will be safe from any “Infinite level” or “Money giver” exploits. Do NOT offer the client ANY remotes that lets the client to send towards the server data that allows said client to modify server data & information. Mess this up and game breaking exploits will be one line of code only. And secondly, offer the client as little as possible to work with (instances, data, scripts, etc). Do this and exploiters will have a harder time trying to mess with the rest of the game or server. (By the way, ALL module scripts that replicate on the client CAN be decompiled, viewed and copied by any exploiter. This is the case with LocalScripts too). Any instance that exists on the client (From Workspace, ReplicatedStorage, etc) CAN be accessed by any exploiter. So, give them nothing to work with!

Time Step functionality is… something else entirely. I don’t think your current approach for features like “Time Stop” is great and may lead to issues along with technical debt. Time Stepping is a rather complex feature that requires DEEP integration into the game. But here is a simple design you can try to properly manage time stepping.
Proper implementation of such system can translate to things like Made in Heaven’s universe acceleration to work out of the box.

There should exist FOUR types of Time Step values:

1. The Server (Global, influences all)
2. Per-Player (Influences individual players only)
3. Client (Influences the client of a player only, not necessarily the player)
4. Per-Object (Time Step value created for an individual skill or similar. Should be influenced by the server time step value)

Each one of those “Time Step” values are just simple numbers. Default should be 1 (aka normal speed or 1x speed). 0 Means fully stopped time (aka 0x speed) and anything higher than 1 would be higher speed. (Decimals will work too).

The idea is that ALL of your code should be based around these time step values. (Any number multiplies with this to determine actual speed of everything).
Your code should either be running via frame steps all of the time (executing every frame) OR it should at least listen to any changes of these Time Step values to apply them accordingly. Everything should have Time Step functionality. Cooldowns, Effects, Attack animations, walk speed, everything.

Now do note that while not exactly convenient to implement (its not easy i know), So far it is a good and decent way to implement all of this. Particle Emitters have a time scale value (though ranges only from 1 to 0) and animations let you specifically set their playback speed to any value (including past 1). Sadly no proper Time Stepping implementation is quick or easy to do.
You could very likely benefit from having some sort of module that manages most of the work (Should be a replicated one).

Some resources to help with game development:

Signal object for script use (works 1:1 like instance signals):

Faster indexing of instance properties. Don’t expect 100 more fps out of this though:

Faster encoding/decoding. You can use this for encoding/decoding things when working with DataStores:

Documentation for the Microprofiler. It’s a tool baked into the client and studio that lets you keep track of the compute times of your own code: