Description:

A multiplayer version of the classic minigame Fun with Plushtrap from Five Nights at Freddy's 4® (by Scott Cawthon). You can create lobbies and play with your friends or with complete strangers!

Mostly made by me, with 3D renders by @MaroonFox and Scott Cawthon and TurboWarp extensions by @LukasStudioTV.

Development Stage:

The game is on its BETA Testing Stage, which means I will be testing the gameplay and multiplayer features with other people but will still make changes to the game. These changes can include: more sound effects, more renders and transitions, gameplay balancing changes, trophies, (maybe) soundtracks, etc.

Gameplay: 87%

Renders: 69%

Polishment: 60%

Overall: ⁓72%

Media:

Game Jolt page: https://gamejolt.com/games/fwpmultiplayer/592066

Game Jolt community: https://gamejolt.com/c/fwpmultiplayer-h7g94x

Release Date:

Coming 2024.

Credits:

Coding:

@CamaRod

Renders:

Text, UI, and Background Renders: @CamaRod

New 3D Renders: @MaroonFox

Original 3D Renders: @realscawthon

Credits:

Beta Testing:

@MaroonFox

Voice Acting:

Plushtrap: @CamaRod

Eddie: @rayan332914

Sarah: @snatcherepic

Devlog #1: The Initiative

So, I wasn't planning on making written devlogs on this game, but since I am doing it a lot after I started getting back to working on this game, this devlog may be a little inaccurate. For your information, I got back to this game halfway through December of 2022 (and it is already February of 2023). Because of this, I might not remember everything I made right after going back to this game, but here it is:

The first thing I did was try to modernize the game's UI and overall menu. With that in mind, I made some 2D renders (which I am allowed to show here) including lobby buttons, a background and the basic formatting I wanted for this game. They took me a while to do but I am pretty happy with the final results of it. I ended up with these:

By the way, the render I used for the button to select Plushtrap was made by @MaroonFox. Since it was made a while after I remade the game's menus, the render I had for the original button was from a fanmade render, which I didn't want to include in the final game because I didn't have the rights to it. The flashlight render was just found on Google and edited to fit the game's style.

With that being said, I still had to fix the gameplay, which was really bad and not user-friendly at all on v0.1 (the first version of the game). But that was a topic for another devlog. However, the multiplayer stuff about the game (creating/joining lobbies and actually starting a game) was surprisingly not that hard as I expected. I think I was so devastated about not being able to code a multiplayer game when I first made v0.1 that I just kept telling my mind that it was going to be really hard. But after ⁓2 years of ignoring this game, it finally came up to me and I felt guilty for promising such a huge game (at the time) and not delivering anything for the next 2 years.

The whole reason I started working on this game again was to prove myself that I have grown as a coder and explored a lot of Scratch's limits (and sometimes breaking them through Scratch extensions), even though there are some scratchers out there who do stuff way more impressive that anything I can do. Not only that but, again, I felt shamed for announcing a multiplayer game when I was only in my little confort zone regarding coding in Scratch.

Anyway, enough rambling. Let's talk about the gameplay... in the next devlog. And with that, I finished v0.2.

Devlog #2: The Gameplay

Again, I'm writing these devlogs a lot after the moments I describe in it. Just realized that forgetting somethings I may add gives me an advantage to not tease too much about the game. I will try to be as vague as possible regarding the gameplay because it is still subject to change due to reasons I will explain on a later devlog.

Starting off remaking the gameplay, I did some brainstorming with the v0.1 gameplay chart, which was very confusing and was not user friendly for the kid (when I refer to "Plushtrap" or "the kid" I'll probably just be talking about the players controlling these characters). It was basically a highly unproportional chart made in Scratch's vector editor which displayed the Fun with Plushtrap corridor, with big squares representing the positions Plushtrap could go to. A Plushtrap icon would move through the squares in a very robotic way depending on which squares the player decides to go to. On the other side of the corridor, there was a flashlight icon, which could turn on and off, revealing Plushtrap's position to the kid. Behind it, there was a black screen and nothing else apart from coordinate measures which I used to represent Plushtrap's position in the corridor (like an actual coordinate plane). Like this:

There are 3 bad things about it, though. Firstly, it's boring. There are no actual graphics and it just hurts to see. It clearly looks like it was made in Scratch's vector editor. Secondly, each position had its own sprite, which had to operate a same script but do different things in different circumstances when clicked, and that caused a ton of issues. Thirdly, it had more positions than the ones Plushtrap could be in the original minigame. This was probably the main reason I put this game on a hiatus for so long.

I knew I had to do something about the gameplay, and the first thing I thought was about getting rid of all of the buttons and making a single sprite detect where you're clicking and process Plushtrap's new position from that. I also didn't want it occupying the whole screen because I wanted to have the actual renders used in Fun with Plushtrap. Anyway, it turned out a bit like this:

As you can clearly tell, it was based on the Five Nights at Freddy's: Sister Location breaker room console, which showed the layout of the Fun with Plushtrap hallway. Knowing this, I could reduce the amount of positions that Plushtrap could be on to the actual positions from the original minigame and the render was simple but nice. For the kid, I just had the render of the hallway with no light to show whenever the kid was not clicking/holding the screen (because I wanted to make the game touchscreen friendly). I could also get all of the original renders at an acceptable quality (which took me a long time), although a particular render was particularly hard to be found at the aforementioned acceptable quality. You know, it's not like the jumpscare needs to be high quality, right? I mean, it's probably just Plushtrap's most popular render, but whatever...

After this, I planned out how I would make the renders actually show where Plushtrap is. Remember that coordinate plane thing where I kept track of Plushtrap's position through coordinates? That was probably the only thing from the old gameplay I didn't scrap. That is excluding the cooldown, which is a variable that is set to a high amount (like, let's say, 250) whenever Plushtrap moves and decreases when the flashlight is off. Plushtrap then would only be able to move if the flashlight is off and the cooldown is 0. I thought about making it a cloud variable as well, but it was a terrible idea because the kid doesn't have to keep up with the cooldown, only Plushtrap needs. This way, I would have a cloud variable (Plushtrap's position) that could only be changed in certain circumstances only made possible through in-game natural variables, which is really good because it decreases the latency since it doesn't have to keep up with two cloud variables, but only one who is impacted by a regular variable.

From there, I needed to implement the animations to make sure that the renders (which I kept as the background for the whole project), because there are certain positions in which Plushtrap cannot be seen unless an animation is running. I decided to make another regular variable which dictates in which frame of the animation the render is going to be in right after Plushtrap moves, which is when the animation should play. And when the animation should start, that variable increases and the background updates its costume to the frame corresponding to that coordinate and to that variable. However, this doesn't let the kid see the entirety of the animation, because it is very quick and the human reaction time is not a lot quicker. When Plushtrap moves, if the kid reacts quickly enough, they will be able to see the animation running. So I made another variable that dictates the amount of time that the kid has to shine their light on Plushtrap in order to see the animation. Like that, the animation wouldn't start when Plushtrap moves, rather, when the kid shines their flashlight and if that small interval of time allows them to see the full animation, instead of only seeing the last couple of frames, which is not what happens in the original minigame.

The tl;dr here is, lots of normal variables dictating what happens to cloud variables. They all interact with each other in all sorts of ways, making the game... you know... playable. It's definitely not the most efficient coding (I don't really like adding too many variables) but as long as it works, that's what matters!

And then, we reach a roadblock, one that I still haven't figured out how to get over. But that is for the next devlog. Those were v0.3, v0.4 and v0.5. Yes, each version number corresponds to a new mechanic added, in this case (v0.3: the renders and the semi-functional map; v0.4: the flashlight and the fully-functional map; v0.5: the animations.)

By the way, a huge shoutout to @MaroonFox for helping me test all of these features and changes!

Devlog #3: The Roadblocks

I'm already warning you that this devlog won't contain as many images as the previous ones, because here I'm going to mostly talk about the problems I've been having with this game. This devlog is my current state of development, as of February 4th, 2023.

I wanted something new. Not only to create a multiplayer game, but to also create a game that could interact with your Game Jolt API, meaning you can get trophies, play with friends, etc. And I wanted it for this game. At first, the idea came when I was beta testing the game with @MaroonFox and, since the beta is an html file, I noticed that if I opened the game twice (as in, opening in two separate tabs), I could play the game with myself. This made me ponder about ideas that could fix it. And then it sparkled: Game Jolt API.

Lots of multiplayer games in Game Jolt use its API, but Scratch is particularly limited to these sorts of things. Thankfully, I had found an Game Jolt API extension for TurboWarp (the Scratch extension that I was coding the game with) made by @LukasStudioTV and it looked pretty promising. I quickly got used to the new blocks and could easily learn how to sync projects with games on Game Jolt. After experimenting with the extension for a while, I jumped back into my game and tried to apply it there. There I started noticing some things...

I would have to make a login screen. Easy, right? Yes, actually. After making the login screen, I decided to input my info to try to see if it was working. It was working, with two problems, though:

1: Whenever I inputted the wrong information (username and game token), the extension would still say I was logged in, even though the account I "logged in" with didn't even exist. This is huge because it basically makes the login screen and its whole purpose pointless. Think about it, just inserting anything into the prompts and you would have access to the game. But why didn't I make an account verifier? Well, I did, but you could still bypass it by putting a username that exists (which is what the verifier checks for) but a completely random game token. It worked like this: you typed in a username. This user's public Game Jolt data (like bio, friends list, last login, etc.) would be fetched and the verifier would see if the user's last login wasn't an error. I chose to verify the last login because it's not something customizable, like a bio, or who you're friends with. And when the user didn't exist, the output message would be "Error somewhere!" which means if the output wasn't that, then that account is real. The problem is, the extension didn't care if you were actually logged into a real account or not, it would still say you were logged in.

2: You could log in with an account twice at the same time. The extension also didn't care if someone was already logged into the account you are trying to log in with. This is also bad because even if the first problem didn't exist, you could still play the game by logging into a single account twice in different tabs (which was the problem I was initially trying to solve).

Now, to not discredit the creator of the extension, he did release a patch and he did hear me out when I reported the first issue. Not only that, he fixed it. Sort of. When I was testing the login feature on TurboWarp editor, the first problem had vanished. Now you needed to put precise and correct information in order to actually log in. However, as soon as I packaged the project (on TurboWarp's built-in packager) and went to test it for myself, the issue came back to haunt me. I don't know if it's me not knowing how to update the extension on TurboWarp Packager or if it's an actual error within the extension itself. Either way, I can't go further on anything regarding API in this game at least for now. I'm also trying to see if he can also fix the second issue I mentioned. After implementing the API extension to the game, I decided to make it v0.6 (which means v0.5 is exactly the same as v0.6 but without the API stuff).

Let's take a break here, because now I'm moving on an issue in my game: balancing.

You know how Five Nights at Freddy's 4 is a singleplayer game, right? In singleplayer games, the player can be as overpowered as they want because they are not going against other people who would not have a good gaming experience if that was the case, they are going against bots. Fun with Plushtrap is no different. It's a surprisingly easy minigame, that is, if you know what you're doing. I've even watched some tutorials on YouTube to get to know the game's mechanics, but all they would say is to just listen to a couple sound cues and shine your flashlight after some random sound cue. Of course I'm simplifying the tutorials, but I'm not doing it a lot. The minigame is brutally unfair against Plushtrap (the bot).

This is one of the problems with trying to turn a singleplayer game into a multiplayer game. In order for both players to have a good time playing the game, it needs to be balanced. But when you take a game that on its essence is heavily unbalanced and try to put that for 2 people to play, one of them is not having a good time. Playing as the child in my version of the game is just as easy as the original minigame's version. There's just one strategy: whenever any footsteps are heard, shine your flashlight. Eventually, Plushtrap will either be on the "X" when you shine your flashlight or he will not, which means time will run out if you apply that strategy. It's almost like Tic-Tac-Toe, where there's always a way to never lose, but in this case, it is only available for one of the players.

Now, I'm only allowed to mention this here because I will not release the game with this unbalanced gameplay. A couple of friends of mine who play-tested the game really liked the concept of it, but had the same complaint: the kid never loses. And when I change the gameplay to something more fair and fun, I will not talk about it in as much detail here, since I want the players to figure it out for themselves. But right now, I have absolutely no idea how to change a game whose essence is unfair.

So yeah, these are the problems that are preventing me from making further progress on v0.7, at least for now.

Devlog #4: The Solution(s)

I am writing this devlog the same day I started solving the problems I mentioned on the previous devlog, but this devlog might include more details about specific things, I cannot be very explicit about certain changes I've made today. But here it is:

I have solved two of the issues I talked about in more detail on Devlog #3. If you don't remember, issue #1 was the login not working because you could log in with an account that doesn't exist or with a completely wrong game token. Issue #2 was the extension not knowing if that user is already logged in or not. Issue #3 was the gameplay balancing issues of turning a singleplayer game into a multiplayer game.

With that being said, I was able to implement an autologin system into the game, which recognizes if you're playing the game on Game Jolt (which will always be true since the game will be Game Jolt exclusive) and tries to log in with the account you're logged in with on Game Jolt. It works almost perfectly (more on that later) and it solves issue #1. However, issue #2 still remains a thing because the autologin will not recognize if the user trying to log in is already logged in, making it so people can play the game with themselves using a single account.

I've talked to @LukasStudioTV, the developer of the extension, and he said he will try to implement a block that recognizes if a user is logged in or not (which would allow me to create a system that prevents a single account to be logged in twice at the same time). I'll count that as a half problem solved (bringing the total to one and a half issues solved), since the block has yet to be implemented.

Now, I won't be able to talk in great detail about how I fixed half of issue #3. Just know that I've applied some mechanics to Plushtrap's in order to make Plushtrap more powerful in the hopes of balancing the gameplay. I'll take that as another half-solved issue. It's not fully solved because I have to test their balancing impacts on the game (how much they make the game more balanced). I also can't test them without the help of @MaroonFox, whose laptop's charger imploded. He is currently waiting for a new one to arrive so he can get back to his laptop. He would then help me define how even the game currently is and if its gameplay is good enough for release (and help me catch a few bugs created by the new mechanics in the process).

Today I started v0.8, currently still working on it. This version marks the addition of the login system and the balancing changes to the gameplay. I plan to make v0.9 have custom renders (made by @MaroonFox) of Plushtrap's in-game point of view as well as some other renders by me.

Devlog #5: The Hiatus

As you can clearly see, there hasn't been a lot of progress regarding this game as of late. I've implemented a couple of mechanics that could help Plushtrap in-game and watched a video that breaks down the Plushtrap AI in FNaF 4 (https://www.youtube.com/watch?v=00QpsfqHQzw&t=679s) to try to see if I can apply some concepts to the game. I've also been trying to switch API's, as the original developer for TurboWarp Game Jolt API presumably stopped working on it. Switching API's is boring and to think I still have to implement and make new trophies (which would take into account the actions performed by the players mid-game), test out the previously mentioned Plushtrap mechanics with others (I won't be revealing them just yet), apply FNaF 4's original take on Plushtrap, and make the game more fluid and smooth in general, etc.

Not only that, I also have to ask @MaroonFox for the Plushtrap POV renders; I believe them to be optional but would make the game a lot nicer for Plushtrap's perspective, even with it being a little harder to code. Someday, I'll gather enough motivation to get back to switching everything API related, balancing and polishing the game, as well as making it playable and enjoyable once it releases. For now, I'm going to work on FOXY, GO! GO! GO!

Devlog #6: The Comeback

I've been working on this game behind the curtains the last couple of days, progress has been great. I can't reveal much about it, but the multiplayer stuff with the Game Jolt API and all is almost fixed; I just need to work on the part of people disconnecting from the game mid-match or staying inactive, but apart from that it's good to go! The gameplay is a lot more accurate to the original minigame, and balancing issues are still on the works to be diagnosed and fixed (that is because I haven't actually play tested the game a lot apart from fixing bugs and the multiplayer stuff).

I eventually managed to get around the API problem due to TurboWarp's unnoficial Game Jolt API extension conveniently available in its extension gallery. I've done some research on how Game Jolt's API works and was able to fix a lot of the login issues and discover some cool stuff too. You can now see the username of the other person in the lobby once the game starts, which at first had to inconceivably be done using cloud variables alone, but the API's data storage makes it infinitely easier and actually viable. I already removed the previous API extension.

Page updated

Google Sites

Report abuse

Description:

Development Stage:

Media:

Release Date:

Credits:

Coding:

Renders:

Credits:

Beta Testing:

Voice Acting:

Devlog #1: The Initiative

Devlog #2: The Gameplay

Devlog #3: The Roadblocks

Devlog #4: The Solution(s)

Devlog #5: The Hiatus

Devlog #6: The Comeback

Pages

Tags

Socials

???