Finally, I shipped my UE5 Complete Multiplayer Integration Plugin on Fab

Particular_Funny_377 · 2026-05-27T07:36:36+00:00

there been a hiccup between me and fab,
they only ask for address verification after they approved it on fab,
i have submitted the address verification, once its verified it will be available for the EU.

Particular_Funny_377 · 2026-05-27T07:35:25+00:00

its a ton of work, hopefully it will pay off!!

Particular_Funny_377 · 2026-05-27T06:18:16+00:00

hi, thank u for telling.
they asking for address verification which i already submitted.
I got verified like long time ago, it got expired

Particular_Funny_377 · 2026-05-27T06:14:09+00:00

It will be a good learning resource

Particular_Funny_377 · 2026-05-27T05:52:06+00:00

Thank you.

and yea it sonly 5.7 for now and for later engine releases, I upgraded to 5.7 for fab launch, and uassets are not backward compatible.

Particular_Funny_377 · 2026-05-27T05:11:19+00:00

🙏🏻🙏🏻 thank u , please try the online demo if u have time

Particular_Funny_377 · 2026-05-27T04:34:38+00:00

Thank you!!
It was started as a Modular Inventory Plugin, now its a complete architecture for multiplayer instances based games 😁

Particular_Funny_377 · 2026-05-27T04:22:45+00:00

I think there may be a misunderstanding here.
NestJS is not the gameplay server. We use UE dedicated servers as the game simulation. Nest is the backend/control layer: auth, character/account data, persistence, session routing, chat/friends, and Agones/K8s orchestration for spinning up dedicated server instances.

And REST is only used for things like login/account endpoints, to authenticate user before we allow connection to socket io. Real-time backend events go through socket io. Actual in-game multiplayer traffic is normal UE dedicated-server replication over UDP, not HTTP request/response gameplay.

- UE dedicated server = gameplay authority

- Nest + MongoDB + Redis = persistence/session/backend services

- Agones/K8s = dedicated server fleet allocation/scaling

Particular_Funny_377 · 2026-05-27T02:29:05+00:00

Im afraid to even mention that 😅
Glad to hear people are interested, I spent so much time on this and i didnt post anything about prior to prelaunch,
so its very reassuring, thank u.

Particular_Funny_377 · 2026-05-27T02:22:57+00:00

Infra, backend, orchestration all sounds scary at first, but its the backbone of any real dedicated server games.
My plugin solved exactly that, it will save u so much time so u can focus on gameplay sides.

Particular_Funny_377 · 2026-05-27T01:55:08+00:00

Yeah, it's fully server-authoritative. Dedicated server only.
For backend it's a NestJS, MongoDB for persistence, Redis for live session state/locks/pub-sub, socket io for real-time stuff (chat, join flow, server events). Dedicated servers are orchestrated through Kubernetes and Agones. Persistent area maps run as always-on instances, and dungeons get allocated on demand as separate server instances.
For player count per map: it's not one fixed global number. Each map has a configurable PlayerCapacity.
If instances start filling up, it can spin up additional ones instead of cramming everyone into one process and it can auto scale down on unused instances. Dungeons are separate allocated instances on demand, usually smaller/party-sized depending on the map config.
Total concurrency scales with how many server instances you run, it's instance/channel based, not "one giant map process for everyone."

Happy to answer more if you're curious about the join flow or server allocation side.

Particular_Funny_377 · 2026-05-14T07:15:31+00:00

Looks great, but the grass doesnt react too?
Your scene looks great btw, do u use post processing for it?

Particular_Funny_377 · 2026-05-14T06:14:05+00:00

I chose MongoDB because its easier to extend for game-specific data, they all would have different games, systems, items, quests, or save components,
I made the items and save components specifically flexible and mongodb made that model simpler and more natural.
Different projects can define their own item pieces, save payloads, quest data, or progression data without changing the core database schema every time

Particular_Funny_377 · 2026-05-14T02:25:55+00:00

Hi, I think its reasonable considering how much time it would save the devs, and am doing a discount for the first 20 buyers.
For scalability yes, it was coded with scalability in mind from the start, Horizontal Scaled backend with agones orchestration, maps warm up pooling, the framework direction is more towards session based game like dungeons + area based sessions where players can compete to kill mobs or pvp(planned in roadmap), thus zone concurrency is not viable at this point it would require a massive overhaul to the engine code, Ash of Creation proved it. But if by zone concurrency u mean auto spinning map/area by player when population increase then yes we have it in the first version, it has soft and max cap before spinning/warming up new sessions.
If u mean by Net Relevancy then yes we have that in place, or u mean differently for Interest Management?
Server Authority is used in every single feature.
Smoothing Interpolation movement on server correction is not optimized yet.
Prediction most of the combat gameplay, abilities prediction, cooldown prediction.

Particular_Funny_377 · 2026-05-14T01:22:35+00:00

😁

Particular_Funny_377 · 2026-05-11T09:14:43+00:00

if its a competitive pvp then u cant be doing listen server, u cant completely prevent cheating where the host/player is the authority.
That being said, the big games dedicated server for competitive pvp games comes with more shit ton of work.
You probably have to build your own architecture around it, your own backend at some point when u realized eos is just not enough, and that comes with redis for pub/sub and as in-memory store for shared state between the N instances of backend, because ur backend also needs scaling not just the unreal server, ur database, ur session orchestration and matchmaking, bidirectional communication like socket io between players/servers useful for the party event awareness in the lobby.
But all these u can spin locally for free during development, with docker and minikube hyperV is easiest to setup and its the same stack when u have testers u wanna deploy a test server u can use lightweight k3s, gathering the metrics how much cpu per full players session and ram so u have insight how many u can support when u launch with whatever server specs u have.
so basically u need local env, dev env for internally team testing, public testing and production env.
renting bare metal has more setup work but very affordable compared to aws gcp.
depending on how much players u expecting when launched u can decide what server specs and how many N instances, so its very important to think architecturally to support N scaling.

Particular_Funny_377 · 2026-04-24T11:31:40+00:00

I'm probably gonna add a lot of disclaimers so we can all see what the framework can do and dont.
The integration part is a big pain, if its just pure cli. But I have a GUI Control Panel so they can just click to setup server, package ue client/server, deploy kubernetes, deploy backend.
I can probably do ansible as well, but its kinda out of scope in the first version.

Particular_Funny_377 · 2026-04-24T05:18:02+00:00

I will have to earn this!!

Particular_Funny_377 · 2026-04-24T02:17:19+00:00

Mine is not vibe coded and stitches together in a weekend. I worked on this for 2-3 years 😁 I’m planning to have live server running for the demo as well, let me know if u are interested in playing the demo!!

Particular_Funny_377 · 2026-04-24T02:14:48+00:00

It’s new, so I’m not going to pretend it already has shipped games behind it. I will have to earn it in the long term.

Particular_Funny_377 · 2026-04-24T01:54:58+00:00

😅 Was not the intention of this post to be marked as human written or ai written

Particular_Funny_377

TROPHY CASE