Game Optimization - Concepts

[TheAviator01]

I had some questions about game optimization:

(Feel free to comment on any of the questions, or suggest other advice)

1. Is it better to split the server framework into 2 individual scripts?

2. For large games, would you guys recommend using Streaming Enabled?

3. Is it better to handle bullet raycasting on the server side? (considering that the server won’t see local parts)

4. Is it okay to use beam objects as a way to display projectiles / bullets?

5. Is it okay to keep creating a ton of reserved server access codes for a game that has a main lobby, and then teleports players to a separate game place containing the map? (teleportation service)

Thanks for reading this.

[Avigant]

1. Has nothing to do with optimization. For sanity and determinism, one entry point per machine is ideal, neglecting game.ReplicatedFirst.

2. No. Provides no control to developer, players can die from getting onto unloaded map parts. Custom chunk loading is better.

3. Servers fire the authoritative bullet. The local client immediately displays visual feedback.

4. Adornments may be more performant, but I’m not sure about this. It’s okay to do this, yes.

5. Avoid teleporting players because it’s bad user experience when possible, but this is not a performance problem, and would be fine.

[TheAviator01]

Teleportation Concept:

My game is a little similar to PUBG or Fortnite, in the sense that you join a lobby server, and then teleport to the actual game that is about to start… At most, it’s probably around a 5 second teleportation wait. I could also add a custom load screen animation or layout to make it look better.

Lobby: A ton of players (Max 100)
Individual Game Server: 5 - 75 players (Min 5 Max 100)

Also, how would you go about making a custom chunk loading method?

[Avigant]

I’ll get around to writing a proper tutorial sometime:

How do games like Meepcity load different buildings?

@MrLonely1221’s approach is not the most beneficial possible, as it saves no client memory. As long as the loaded area iisn’t in render view normally, there’s no real performance gain from doing what he does. His approach does have a computation penalty, so this approach may be a negative with no benefits if these parts are not normally able to be in render view. For a loading system like this, you want to store this sever-side, not client-side at all. Put the instance inside Player.PlayerGui w…

[TheAviator01]

Alright. In the meantime, I kind of want to have a max player limit of 100 for my lobby servers, but I need to be a beta tester. Do you know the link to get to that page?

[Avigant]

Enroll in the Roblox Beta Program

Opt in I want to be added to the beta program.

[edenojack]

4; Beams are a good way of displaying these, depending on what it is that you are trying to display.

• If you are moving a bullet, yeah these are great.
• If you are moving a rocket, you can use them, however a Part would probably do better.

Moving forward with this, Attachments are necessary for Beams. Attachments require an object to be inside of, and cannot directly be placed into the Workspace because of this. However, they can be placed into the Terrain Object, within workspace. Terrain has the exact same origin as Workspace, so you’ll be able to put them in, and change their position as if they’re in the regular workspace.

[EmilyBendsSpace]

@TheAviator01

• Is it better to split the server framework into 2 individual scripts?

Better than what? One monolithic Script that is all the server code? Yes. A ton of scripts running independently? Usually. One Script that intelligently loads all the other server-side code from modules, with a good system for managing dependencies and communication between systems? No.

• For large games, would you guys recommend using Streaming Enabled?

I have not had good experiences with StreamingEnabled, but in all fairness, I have not tried it recently. It will most likely require you to write more code specifically to account for things not being loaded. For example, when I first turned it on, players were teleporting to places on the map and falling out of the world before the terrain loaded, I had to add code just to wait for the ground beneath them to load.

• Is it better to handle bullet raycasting on the server side? (considering that the server won’t see local parts)

That’s not a simple question. It entirely depends on how competitive your game is, how your projectiles are modeled (e.g. parts, vs. hitscan, vs custom kinematic calculations), and how (or whether) your system does any latency compensation. Many times, you want the client and server to both run all the code, and use the server’s account to validate that the client’s version of events agrees within acceptable tolerances for internet latency.

• Is it okay to use beam objects as a way to display projectiles / bullets?

Yes.

• Is it okay to keep creating a ton of reserved server access codes for a game that has a main lobby, and then teleports players to a separate game place containing the map? (teleportation service)

Yes. A lot of round-based games do this and it’s an intended use of the TeleportService system.

[TheAviator01]

What would be the benefit of putting attachments + beam objects inside “terrain” rather than “workspace”?

My current setup:
Workspace → Folder (Projectiles) → Objects (Attachments & Beams)

[XandertjeKnal (Xander)]

In Terrain the attachments don’t require a parent part, so you can put them in there and animate the positions of them directly.

If you try putting an attachment directly in Workspace (or in a folder like you suggested), it will prompt you that you need to put it in a parent part.

So the benefit is that you don’t have to make a new part every time a bullet is fired, in this case.

[TheAviator01]

Awesome (: Before, I had an ignore part at the position (0, 0, 0), and then parented the attachments to that part (but obviously, that method is not the best lol) I like the terrain parent idea^

[EmilyBendsSpace]

It makes no difference right now. I personally have an “OriginPart” in all of my games, which is a transparent, non-collide, anchored 1x1x1 block at 0,0,0 with no rotations. I use a 1x1x1 so that HandleAdornment types I adorn this part with don’t inherit any extra scale factor and all their offsets are just in world coordinates. I don’t use Terrain as the parent or adornee because it seems less future-proof to me, since it’s not a supported or intended use of the Smooth Terrain’s primitive part. How the Terrain part is scaled, or how/whether its descendants replicate could change and break this usage at any time.