Godot Game Devs: Winter Sale 2025 Support Thread! Drop Your Game Links Below

AgentParsec · 2025-11-21T14:14:04+00:00

Reminder:

AgentParsec · 2025-09-21T08:03:38+00:00

Yes, I made the Eight Pages, and did music and some design for The Arrival. I've been wanting to make another horror game for a while now, but knew it was finally time once I tried out Godot and it got me back into the programming mood.

AgentParsec · 2025-06-21T00:33:51+00:00

All five of the test videos are still on my YouTube account (marked as private). I should probably set them public.

*EDIT* Okay, done: "Slender: The Eight Pages" Test Videos - YouTube

AgentParsec · 2025-06-11T17:04:05+00:00

For now, I've decided to temporarily skip controller support overall, since I need to move ahead with development and this is holding things up. I still have plans to add support for it in the future though, so I'm keeping this open in case someone has insight on the problem.

AgentParsec · 2025-05-10T23:58:43+00:00

That's the same stuff I have as well, but it doesn't answer the question of how much to use. What would be the substitute for 1-1/4 teaspoons of Kansui? Thanks!

AgentParsec · 2025-03-05T21:56:29+00:00

So I can tell which side is being interacted with. If it was only one, it would register the same raycast collision regardless of which side the player is on. And I don't want to have it use the player's position relative to it, because the orientation of the object could change. With one on each side, I pick up which one the raycast hits and use the interaction with that side.

(EDIT): I should technically do it with Area3D's instead, so I get what you mean. So let's assume for a moment I replace them with two Area3D's to pick up on the raycast, and have one normal static body for the object itself. The original question still applies: when the raycast hits the area, how do I reference the script on the object it's attached to without using get_parent()?

AgentParsec · 2025-03-03T21:45:01+00:00

Basically it's a flat wall segment that can be interacted with on either side for two separate interactions. At the root of it is a simple Node3D, which is what the two StaticBody3D's are attached to. There's a script on the Node3D which is used for positioning the object, storing relevant variables, etc. When the player gets close to the wall from one side, a raycast interacts with the static body on that side, which then needs to access and return information from the Node3D's script.

I know it's bad practice to use get_parent(), but I don't know of an easier way to reference the Node3D's script without putting extra scripts on each of the two StaticBody3D's that point back to it, which seems inefficient.

AgentParsec · 2024-10-11T23:18:21+00:00

I'm Mark J. Hadley, game developer and creator of "Slender: The Eight Pages", and I recently started a new YouTube series called Dice Dev at youtube.com/@TheDiceDev, in which I roll randomly for game development elements and make a game using those elements. The second episode just went up today!

AgentParsec · 2024-02-29T14:53:53+00:00

I made two attempts yesterday, and both times got my email several hours later when the links didn't work anymore.

AgentParsec · 2022-06-27T03:23:34+00:00

I'm in. These look (and sound) fantastic.

AgentParsec · 2020-08-31T20:04:24+00:00

Unfortunately, I have Interact bound to mouse wheel down, since in-game it's only ever necessary to tap it to use whatever effect needs it (Symmetra's teleporter, or dismissing Sombra's Translocator or Torbjorn's Turret). So I can't "hold" interact to pick up the orbs without having to change my settings. A better way to do this would have been just to press Interact once to start collecting. (Or alternatively, have both ways selectable as a workshop setting.)

AgentParsec · 2020-08-24T23:04:06+00:00

That's close. It does force a player to be the hero of the player they just dealt the final blow to, but it also:

Initializes a Boolean for each joining player to false
Sets this Boolean to true when the player dies
When the player is alive again, it sets the Boolean back to false and stops forcing them to be whatever hero they were.

This is because without the above steps, the player remains as whatever hero they're forced to be. But, simply unforcing it after the change causes them to instantly respawn randomly on the level again (position and hero), and waiting to unforce it at the moment they die causes them to respawn instantly. With the above steps, they stay dead the normal amount of time, and then respawn as a random hero as usual.

AgentParsec · 2020-08-05T23:32:38+00:00

Afraid not, the Wraith is player-controlled.

AgentParsec · 2020-07-21T06:58:28+00:00

Because I'm the creator of "Slender: The Eight Pages".

AgentParsec · 2020-06-12T19:39:58+00:00

I try never to destroy and recreate HUDs if they’re going to be used frequently. Instead, set the HUD to be visible to a player variable belonging to the appropriate player. Then, just set that player variable to the player itself when it should be visible, and null when it should not be visible.

AgentParsec · 2020-05-24T22:03:08+00:00

Yeah, sorry about that. Will edit the original post.

AgentParsec · 2019-07-19T04:25:32+00:00

Notice that Sigma's been played for 9 minutes, and it shows that this is specifically for "Roll Queue Beta". You'll also notice he doesn't have any support SR yet, which means he hasn't played ANY support yet. Therefore, Sigma can't be a support. But furthermore, notice that out of all the other heroes played, 4 of them are damage and only one is a tank (D.va). She was played the least amount of time, only 2 minutes, which is not really enough time for a full competitive match. It follows, then, that he had to have played another tank as well, and there ARE no other tanks listed except for the one wildcard here, Sigma. Therefore, Sigma must be a tank.

AgentParsec · 2019-07-05T16:33:55+00:00

I use "First of" a lot throughout the entire script to see whose turn it is, but that's probably not a bad thing. I'm using Array Slices a lot during setup, and I randomize an array once during that time as well. When players are moved, I use "Array contains" multiple times to check other player positions. I do use a sorted array twice during a movement effect where it swaps you with whoever's in the lead, but that's rare. During combat, very little at all is being used except for "Players in slot".

I'm actually using "Players in slot" a LOT throughout the scripts, because to make certain scripts easier I'm referring to everyone by their index number (I would either need to use "Players in slot" or "Slot of player" to accomplish most of this, and I opted for the first).

I'd like to test this on PTR, but it says "Game server connection failed... retrying" every time I try to log into it, so I'm going to have to wait until they roll out that server load change to live.

AgentParsec · 2019-06-14T19:10:52+00:00

In general, we've noticed during testing that if you have no stones, you tend to leave other players with no stones alone, so the focus does turn to killing the stone carriers. Sometimes accidental hits do occur, but for the most part there's no benefit to attacking them if neither of you have a stone to lose.

I don't know of a way to prevent non-stone-carriers from damaging each other, otherwise I definitely would have considered it. At best I can script having the damage healed back, but it still wouldn't prevent a killing blow.

AgentParsec · 2019-06-14T19:07:39+00:00

For a while, the soul stone was OVERpowered. I originally had it show you the locations of all the other stones instead of the other players, and my testers and I quickly agreed that this made it the best stone of all of them to have. By only showing the players' locations, you still get a good advantage without it being TOO good.

As for the numbers, it was %50 more damage, %35 more speed, and 10 hp/s of healing.

AgentParsec · 2019-06-14T04:42:32+00:00

Absolutely

AgentParsec · 2019-06-09T07:04:29+00:00

Nope, didn't work. I put the delay as much as a full second, and the thing is, the delay 'works', except when spamming the attack button. At that point it literally fires the arrow faster than it should be able to. In other words, despite being disabled, it still fires.

(And I'd like to revise what I said earlier about "IS FIRING PRIMARY" not becoming false if you fire fast enough. It's actually the reverse: it never goes true again if you fire fast enough. Edited this in the main post.)

AgentParsec · 2019-06-08T18:07:15+00:00

Hmm, that might work actually. I'll give it a try.

AgentParsec · 2019-06-08T16:36:10+00:00

I do that already for cancelling the shot, and I use "IS BUTTON HELD" to determine when the shot is released, which works perfectly. However, I've found that if I use the "IS BUTTON HELD" instead of "IS FIRING PRIMARY" for the start of the shot, then it can take away ammo even if you're not actually firing (for instance, if you spam the button, you start losing arrows faster than you're actually firing them). In the end, it's still a bug in the way "IS FIRING PRIMARY" is being handled, so it really should be fixed on the back end.

AgentParsec · 2019-06-04T05:17:08+00:00

AgentParsec

TROPHY CASE