Community Q&A

We met when we were born because we are siblings. I wanted to make this game because of Plazma Burst 2, Mutilate-a-Doll 2, and Madness Combat.

It made everything easier because we didn't have to go to school in person anymore. I miss Covid.

Kei goed.

Yeah I don't like marketing or merchandise or any of that corporate, soulless stuff. If I were to sell anything it'd be little poseable figures or plushies. Profits go to charity or something.

Not by my hand.

Like once a month I'll open Garry's Mod, Quake III Arena, or Halo.

A teaser trailer should be out soon. The game will be free.

I like making games and ppg is like a programming sandbox. I can add any item that I think would be fun to make.

I don't think there is a lack of them. It's just that many of them are overcomplicated and not fun. Make simple games. Don't try to make wiremod again.

Backwards compatibility. Improving the game while keeping older contraptions & mods working is nearly impossible with the way I've designed things. I can't turn back.

There is no crew, it's just my brothers and me. I don't feel very anonymous.

I made People Playground.

I want to add simplified but fun nuclear physics and chemistry to the game at some point. A proper radiation system would be cool as well.

I don't know. I'm prone to rewrite things but ppg has become so large and convoluted that it'd be an enormous task.

go watch game theory fnaf videos

It's still being worked on as a standalone application. Other things have taken priority.

No :(. For a proper implementation, it'd basically require a complete rewrite. For a half-baked implementation, you can state sync as many variables as you can find and have a very cool 8 fps, 3 second ping experience.

Unity has a custom implementation of Box2D. In Box2D, fixed joints are springs. They're constraints that oscillate very quickly to keep the connected objects in the right place. The higher the frequency, the more rigid the constraint. Physics iterations are usually at 8, but ppg defaults to 16 and can go up to 128. This would be way overkill for most games, but not for a physics sandbox. These joints can never truly be fixed due to their springy nature.

An alternative would be parenting all connected objects to the one single rigidbody. This would make the fixed cable truly fixed. This was partially implemented at some point but too many objects expect to have their own rigidbody for their functionality. A proper implementation would mean I have to change hundreds of scripts, including public API. This would break many mods and contraptions, so I gave up. I might give it a go again at some point, ideally without having to break everything.

I'm going to add a Gorse two years ago.

I appear to be dumb as hell because I can't figure out how to make gears work properly. It seems like a simple problem at first: make a thing spin when another thing spins. Turns out it's not that easy.

Imagine two gears, A and B, that are connected to each other. If one of them spins the other one spins in the opposite direction and vice versa. Let's say we give A a spin, we should see B start to spin too but it isn't. In fact, we can't give A a spin because B isn't spinning. B is preventing A from spinning because it's trying to impose its own rotational velocity onto A.

Even if they're both spinning we have another problem: we can never stop them from spinning. A is making B spin and B is making A spin simultaneously. Neither of them care about the external forces we apply, they will just copy each other. I "solved" this by making them only copy 50% of each other's velocity and leaving the rest open for the physics engine to interact. This worked to an extent, but it made torque transfer poorly. You can't lift an object using these 50% gears because they will slip and slide.

Gears don't slip. They're practically wheels with infinite friction. So I changed gears to belts, because belts can acceptably slip to an extent. If you can think of a solution to this issue, please help.

Oh and yes, Box2D does have a Gear joint. Unfortunately not only does Unity not implement this, the existing third-party implementations require both gears to be pinned to the wall.

Physics is calculated 50 times per second, no matter your framerate. If an object is moving at 50 m/s, it will move an entire meter every frame. In discrete mode, the engine will not check if anything is obstructing the object within that meter. In continuous mode however, the engine WILL check what's in between. This is much slower but much more accurate.

But even then, sometimes, objects will phase through each other. This can happen if an object is moving very quickly or with a lot of force, and it's being obstructed by objects held in place with joints (like a ragdoll). The object will just squeeze through the joints no matter the collision detection quality.

For a short while, I wanted humans to have every organ as a physical object. I only got as far as the brain, lungs, intestines, and eyeballs. Then I stopped caring, but left the feature in because I thought it could just be optional and forget about it. Over time I had received infinite bug reports and complaints about the organs and my neglect of them. I learnt that every feature, experimental or not, is expected to work perfectly. That was annoying so now it's gone.

I tried doing this and it worked, kind of, but it was like a hacky patch over the shitty sharpness system. I need to rewrite the whole thing to make it work properly, fortunately I don't think many contraptions rely on this. Some mods will break, so I'll have to make it really easy to switch to the new system. Ideally, the new system would support stabbing, slashing, moving in all directions while stabbed, and better exit wound detection.

I was working on a mobile version but I realised that I really don't like mobile games. I was making the mobile version for other people, not for myself. I abandoned the project, but I may still finish it at some point. Probably not though.