Testing wreckage spawning with placeholder wreckage models.
A scrap is a fight, but scrap is also junk that can be reused. When a vehicle part is destroyed in a Scraps game, it'll drop some wreckage. Nothing like the amount you see above, but enough that maybe you can scavenge some and get back to an evac pad, where you can spend it on improving your vehicle.
To pick up scrap, you'll need something to put it in. So far, I've made this tall container:
Pretty much like something you'd buy at Storage Box.
The white fill bars and plastic viewing window help you - and your enemies - see how much scrap you're carrying. The lid also bounces around as you drive:
Scrap that you pick up is divided evenly between all your containers. Scrap does have some weight, so putting all your containers on one side may not be a good idea.
I'm going to anticipate someone suggesting an even cooler way of handling scrap collection by both proposing and debunking it as an option now: Wouldn't it be cool if the scrap you collected actually went into your containers? Like, the actual scrap piece sat in a container with its own physics, instead of this abstract representation on how full your containers are?
Yes it would. It would be the coolest. You could try to carry too much while driving carefully like a combat version of Tricky Truck. You could ram people who were carrying too much to topple some of their scrap and steal it.
There are two reason why that wouldn't work unfortunately, one much bigger than the other:
- Minor reason: Getting physics-based scrap into containers. Dropping scrap correctly into containers on moving vehicles would be hard, but working out where there's space to spawn scrap inside a container would be a lot worse. There'd probably be some cases where you picked up some scrap but it didn't make it into the container properly even when it clearly should have.
- Major reason: Network bandwidth. When scrap is spawned as a part is destroyed, it does its own special deterministic physics, ignores anything moving, and the server tells it exactly where to go (it's partly random, but the server sends a seed to use, like how putting a seed into Minecraft always gets you the same "random" map).
Using actual physics-based scrap pieces flying all over the place, with Unity's physics being non-deterministic as well, would just be impossible. If scrap was just cosmetic, it'd be fine because it wouldn't matter if the server's scrap pieces didn't match the clients, but it can be picked up by anyone. So the positional data of every active piece of scrap on the map would have to be synchronised over the network all the time.
So that's why I'm using a more abstract representation here. You can still destroy their container to get the scrap that's in it!
New: Half-height blocks and slope blocks.
I also made a few more cosmetic blocks this week. I will put these into the demo, but not right now: It's not in a good place to update right now because my demo branch is getting too out-of-date to merge changes into, but in the main game the vehicle building and testing process is a little broken and not tested properly since I've made lots of changes. When things are more stable I'll be able to put this stuff into the demo.
This isn't Minecraft - We have slopes! This would be even better if the game calculated aerodynamics, which is a future possibility.
I have one issue with half blocks that I'm not sure of the ideal way to solve. It's easiest to show via image:
Any clever suggestions are welcome. For now, I've omitted snap points from the sides of half-blocks, which limits some arrangements but at least everything sits nicely.