ApunoGames Forum

Hello, found this site instead of discord. one question to @TSEG. will Fazbear Nights introduce Multiplayer or Co-op. By using P2P and a nice custom lobby in menu. UE5 specifics could be RepNotify or RPCs. since most of the games logic is there and UE5 supports networking it should be easy, only thing to make is the actual character and network connect/host/client/sync. Just a thought since it would be way nicer to hook up with friends, up to 2 or 4 or more.
As a dev myself if you ever need to get help with this just message me.

The game already is nice and good however there are not alot of co op Fnaf games out there so you would get more audience to this game.

Other than that the game is perfect

We know how to implement multiplayer as a component, and it takes a lot of work. Fazbear Nights wasn't built with multiplayer in mind, making every component fundamentally incompatible with multiplayer. There are also more specific challenges that comes with the simple fact you can be seen in thirdperson. How do we handle jumpscares, or looking at cameras? P2P isn't just slap it on and make it work either, you need to hook it up to EOS in this case so hosts don't have to port forward, luckily we already have a solution to that problem. We also have to manage basic moderation, consider server hosting capabilities, communication methods, and so on.

We have other priorities. 3.1 has been incredibly slow to work with, and something like multiplayer would increase the time it takes 10 fold.

I understand that it may not be a priority.
However if you ever are implementing multiplayer i suggest P2P instead of server hosting.
If you like to help me process of the game. i can certainly help you implement the networking.

I already done a fair amount of the groundwork as a proof-of-concept. I injected the shipping build with UE4SS and I mapped out every runtime Blueprint class doors, clock, power, AI states, player stats, including the exact properties and functions each exposes. The plan is a separate networking component/plugin on top of the base game, so nothing in the games own logic gets touched.
The two design problems you flagged are the ones i actually thought through:
Cameras/monitor: handled independently per-player all players can use their own monitor, and the state just syncs.
Jumpscares: synced as independent discrete events when the host state says "jumpscare", the client side plays the animation locally.

If i may ask since you arent prioritizing mutliplayer this year. Can i make a mod that enables full p2p auto TCP joinable lobby.
Just want to ask to keep it in mind. Since i only have the shipped exe no actual backend or source files

But im not asking to hurry or switch or stop the current development, im just curious why multiplayer wasnt intended.

If we add multiplayer, we can do both P2P and dedicated servers. Not to say this is what would happen, but I would prefer giving players both options.

I'm not sure what you mean by creating a mod that adds P2P without altering classes, that sounds a little far fetched to me... But then again, I'm not familiar with the Unreal modding scene, I wouldn't even know where to start searching.

For the design problems, it isn't just a matter of jumpscares and cameras. But to tackle these two, we'd need:

• A playermodel animation for every jumpscare so they can be seen in thirdperson (the animatronics' jumpscare animations are already full body)
  
  • Some way for the animatronics to exit out of the jumpscare animation state smoothly so they can resume their chase
  • What do we do with the player corpse? Do we delete it? Do we make it a ragdoll and fling it to make it funny for your friends watching you die?

• A playermodel animation for camera interaction
• Only 1 player could use the cameras at a time.

Half of these require new assets.
Then there is the question of how do we handle the game loop, and animatronic AIs? None of the AIs were made to handle more than 1 player. What happens when a player dies? What do we do with them? Are we just going to let them play 5 nights and that's it?
If we were to add a multiplayer, it'd have to be its own dedicated game mode. One where you're not limited to 5 nights.


These are questions we've already asked ourselves, and we have an answer to most of them. However, the implementation is not one that can be done with a mod, of course (or perhaps it could? it'd probably be very difficult).
We even thought about a potential PvP mode that could somewhat work (we're not doing it).

A good multiplayer implementation would change the AIs to interact with multiple players in a fun way, have each game be different than the last, and multiple maps for players to survive in. I think, if we were to just take the current state of the game and allow several players to be together, it'd become boring quite quickly, especially when the meta is to camp the office and wait.
Finally, Fazbear Nights wasn't designed with multiplayer in mind because we had already tried with PFR and it was quite miserable. Besides the whole thing barely staying together with duct tape, what we did was just not fun for anyone. We hadn't given it nearly enough thought. However multiplayer is something we do want to do, at some point. And hopefully, when the day comes, it'll be up to our standards.

If you want to mod the game, nothing stops you.

Interesting. Yes those questions are important and want instead of a half working multiplayer you want full smooth dynamic multiplayer which takes time, i understand that fully. You are right that it cant be done with the "replication" way; Im doing it the state-sync way on top of the singleplayer game, which is why I dont need to touch the base game logic but again it will not be a completely smooth multiplayer like jumpscares and more. I do have a solution for the design problems.
- Cameras: each player uses their own monitor/feed independently — the mod syncs state, not the viewport, so the "only 1 player can use cameras" problem doesnt exist.
- Death / corpse: hosts night is authoritative, client is a live mirror. Corpse handling is just "avatar goes inactive", no ragdoll flinging, but no work either.
- AI + game loop: With a host-authoritative mirror, theres still exactly ONE live AI: the host. The client copy is disabled and just renders host-broadcast state. The AI never has to "handle 2 players" — it gets two positions to target. Host tracks both players coordinates, and the animatronic genuinely follows whichever is seen "on sight" not "nearest by magic.


The networking, sync and relay is what i can build myself, so the thing i cannot is to show player B in Player A world as i need a art avatar.

But yes i understand this scope and the multiplayer vision is slow and hard right now.

Quote from: CKCHDX on Aug 09, 2026, 01:08 PM- Cameras: each player uses their own monitor/feed independently — the mod syncs state, not the viewport, so the "only 1 player can use cameras" problem doesnt exist.

The problem is it doesn't make sense for all players to be able to access cams at once, so I think you misunderstood what i meant.
+1 em dash

Quote from: CKCHDX on Aug 09, 2026, 01:08 PM- Death / corpse: hosts night is authoritative, client is a live mirror. Corpse handling is just "avatar goes inactive", no ragdoll flinging, but no work either.

You are describing basic networking. No matter the case, what the client sees is a copy of the host's/server's instance, save for prediction and client side logic. What does "avatar goes inactive" mean anyway?

Quote from: CKCHDX on Aug 09, 2026, 01:08 PM- AI + game loop: With a host-authoritative mirror, theres still exactly ONE live AI: the host. The client copy is disabled and just renders host-broadcast state. The AI never has to "handle 2 players" — it gets two positions to target. Host tracks both players coordinates, and the animatronic genuinely follows whichever is seen "on sight" not "nearest by magic.

The AI code checks against the local player, AKA the host. It will often just ignore the other players.
+1 em dash

LLMs won't be able to help you much here, especially when they hallucinate how the game's logic works.

Yes, i understand. What i meant by the camera feed is that since both players share same world it will treat the camera feed as single use/locked instead of checking if a player uses it.
About the "Avatar goes inactive" is what i meant that if player B dies in player A world then it will juse disappear and the animatronic(AI) will continue to hunt.

True by default the ai code checks against local player but my debug dump has shown two exploitable facts.
1. Every animatronic has a writeable player property like Bonnie_AIPlayer = AActor and so on. The target reference is not hardcoded.
2. Several animatronics except Bonnie and chica  which rely on writable player property instead but the rest have Pawnsensing with seepawndelegate which fires for any pawn not just a local player but all players
Basically the mechanism is that the host spawns a second player as a player class pawn, the client avatar is kept at the clients synced position every tick. Then the host ai will see both players and repoint each ai to player at whichever target is in sight like original design.

I completely still agree, I will experiment and see how far i can go and keep up to date as i understand that you will not begin with the multiplayer implementation however i can make that jump start for you without needing the source code and i can send the document and code for you to inspect later once my method actually works as-proven concept.
All scripts are written in Lua

About the LLM. I do use a custom LLM that I built to speed the process up faster however I think its pretty accurate since its not chatgpt or general ai via cloud

Well at this point I'm curious to see what you can cook up. You've got our blessing.

Quote from: CKCHDX on Aug 09, 2026, 02:51 PMAbout the LLM. I do use a custom LLM that I built to speed the process up faster however I think its pretty accurate since its not chatgpt or general ai via cloud

I'm fully in favor of self hosting everything, including LLMs. However, unless you've got several 5090s to feed to a model, chances are it'll be dumber than the cloud ones. Not that the free cloud models are smart, they really aren't. But even then I never successfully got a local LLM to outsmart a cloud one.

Yea true. I will do what i can and you will soon see the result