Games Scraps: Modular Vehicle Combat - Vehicle combat with buildable vehicles

I've got a plan for improving the scoring system, but I'm also interested in any feedback on why my plan is actually terrible: http://steamcommunity.com/app/350150/discussions/0/535151589889915571

Also, here's a preview of the AI destroying me in low-gravity mode, which is coming in the next update:

 

Does this mean you're still using rigidbodies or did you tweak your own physics system?

 

i love your game!! but it could really use a graphic overhaul

 

I still use Unity physics, and a crazy networking system to make it all work.

This is probably true. It'll get some more work on making the maps look nice at least. I'm much more of a programmer and audio guy than an artist or 3D modeller, and I know it shows.

 

#wizardry

 

Basically at some point I wrote down OK, I need the following:
- No client control lag
- Supports latency up to at least ~500ms
- Cheating prevention (semi-authoritative server)
- All physics can run in real time

Then I thought about options until I came up with the one possible way I could see all that working. The last point is particularly annoying, and is due to the fact that you can change the speed the time passes in Unity but you can't "step" forward or back.

I don't have time to go into the details of the system right now (though I have mentioned some parts of it in the past), but basically it does everything OK except that it doesn't lag compensate when calculating shots: You have to lead your shots to compensate for lag like in the Quake engine, whereas in the Source engine for instance you don't have to. Although having said that, even in the Source engine physics projectiles like the rocket launcher in TF2 aren't lag compensated.

 

Okay, thanks for the explanation. I'm sure I'll have to tackle the issue of multiplayer physics at some point and I'll look at this game as a reference point.

 

Scraps v0.5.1.0 is up. You can now get assist points for helping to destroy a vehicle so "kill stealing" is less of an issue. I've been thinking about potentially more complex solutions that would also help direct gameplay (as I linked a few posts up), but this should help for now.

There's also a new Low Gravity game modifier that you can select and apply to any game, and for the next 24 hours or so I'm also running an official Low Gravity game server (the LOW GRAVITY ZONE).



Full changelog:

2015-07 - 0.5.1.0
- Add Low Gravity game option.
- Added "assist" points for score and XP.
- Redesigned SMG to give it a little left/right movement.
- Balance: Increased engine efficiency multiplier a little. Cars with multiple engines will get a little faster.
- Balance: For Laser and Tesla, see Bug Fixes.
- Balance: Reduced Plasma rotate speed.
- Balance: Reduced Plasma and Large Cannon fire rates a little.
- Balance: Reduced container scrap capacity slightly from 2100 to 2000.
- Weapon damage spread stats look bigger, but the calculation has changed, and things now get knocked around a bit less in general.
- Some improvement for "teleporting" at high latency in multiplayer.
- Re-wrote the modal overlay (loading screen) system to poll state instead of reference count. I knew reference counting would be bug prone and lo, it was.
- Chat stays up a bit longer (you can always see recent chat by pressing T as well).
- Chat text and the round timer on the Build screen don't get in the way of each other quite so much.
- Updated fan translations for Russian, Swedish and Danish, and added a new French translation.
- AI players get a little (AI) designation by their name, and their full difficulty setting info on the leaderboard.
- Some changes to collision damage calculations.
- Started putting full-stops at the end of changelog entries.
Bug Fixes:
- Fixed laser and Tesla weapons only draining half the stated power, and laser also doing half damage. Balanced their stats a little after fixing.
- Remove some minor light halo effects due to an old, old Unity engine bug. Thought I had a workaround but apparently not in every situation.
- Fixed player scores not resetting between rounds.
- Fixed scrap and round length settings not applying if the field was still active when Deploy was clicked.
- End Of Round chat font now matches the in-game chat font.
- Fixed minor text misalignment on chat.
- Fixed server list jumping around in the background while entering a password.

 

Some minor changes in the latest v0.5.1.1.

2015-08 – 0.5.1.1
– Desaturated terrain and dirt FX in Low Gravity mode
– Improved some text alignment in the Lobby
– Balance: A few minor weapon stat tweaks
Bug Fixes:
– Fixed scoreboard ordering half-points incorrectly
– Ramp on the Test Map no longer takes damage outside of test mode (it wasn’t supposed to and it’d get messed up/out of sync)
– Fixed the “press spacebar to change vehicle” text no longer always appearing when it should.

 

New update, v0.5.1.2, brings a new aiming mode which is now the default, where selected weapons will only fire if they're aiming near where you're aiming.



You can press R to switch the mode on and off. It's super useful for vehicles with weapons facing in different directions, and actually pretty useful for any type of vehicle (except ones with no weapons...).

This update also adds score multipliers that come from destroying vehicles without getting destroyed. At the top left you'll see a "x2" etc after destroying vehicles (up to a maximum x3) - if you destroy someone when you're at x2 for instance, you'll get double points.

Basically the idea is to add some incentive to try and stay alive and repair/upgrade when damaged, versus the alternative of self-destructing. Although self-destruct loses you a point and potentially gives a point to someone else, the extra time spent on the Build screen not earning points sometimes offsets that alone. In the future I'm also planning to make repairing able to automatically add back parts that have been destroyed, which should speed up time spent on the build screen a little. Anyway, it's fun to try and stay alive and kicking.

The multiplier system will quite possibly need some tweaking for balance - I'll see how it goes.

Full changelog:

2015-08 - 0.5.1.2
- Added "proximity firing" mode, now on by default. Sets weapons to fire only if they're aiming near the crosshair. Press R to switch.
- Added score multipliers for "killstreaks" - destroying multiple vehicles without being destroyed.
- Changed the assist points system a little in regards to vehicles that destroy themselves.
- Some general wreckage balancing. Also made wreckage easier to pick up.
- Sped up aim around in chase cam camera mode.
- Made game camera always default to the orbit cam on entering a new game. Having the camera save its setting only really caused confusion.
- Balance: Increased collision damage a little.
Bug Fixes:
- Fixed a bug with terrain dirt FX.

 

Nice touch, good way to nerf energy costs.

 

I haven't been making a post for each small update but I've made a few recently:

2015-08 - 0.5.1.5 and 0.5.1.6
- Revamped collision damage calculations.

2015-08 - 0.5.1.4
- XP earned now syncs with Steam Cloud.
- Edited a default vehicle and added a new one.



- More minor weapon balancing.
- Maybe a little fewer crazy physics events when colliding with laggy vehicles (there's still SOME crazy physics, but I've been experimenting).
- Removed the old screenshot code - Steam supports this anyway with F12.

2015-08 - 0.5.1.3
- Multiplayer work that should make things generally smoother and improve "teleporting" laggy vehicles.
- Stopped vehicle damage sounds playing when setting initial health on vehicles when joining games.
- "Proximity firing" mode isn't the default anymore, but made the keys to switch it show in the GUI.
- Sped up unlock progress a little again.
- Some minor weapon balancing.
- Updated "how to play" screens with the proximity firing mode key.

Expect new parts in the next serious update: Full turret versions of the MMG and Medium Cannon and a non-turret version of the Large Cannon.

 

It’s been suggested to me that the name “Scraps” on its own is not very searchable. Despite the fact the Google loves to return me Scraps game related results, I’m very much inclined to agree. I must concede that Google certainly knows I search for Scraps the game a lot, and other types of scrap… never.

Therefore Scraps shall henceforth officially include a subtitle: Scraps: Modular Vehicle Combat.



Please remain calm in this time of change. A rose by any other name and all that.

 

Made a video of the Scraps Godlike AI being awesome in low-grav mode:

 

Working on full-turret versions of the MMG and Medium Cannon and a non-turret version of the Large Cannon.

 

It's been a couple of weeks since the last update so I'd like to show what's going on, even though there's about a week remaining until the next update.

Large chassis:


Updated turret (full Y-axis rotation) versions of the MMG and Medium Cannon, and a non-turret version of the Large Cannon (cheaper, more snap points):


Plus game performance work. Objects made up of lots of smaller parts, many doing their own movement (turrets etc), all of which need to be able to detect hits individually and operate with appropriate physics has always been a bit of a challenge. I've worked out some potential tricks recently, and learnt a couple of others from people who are better wizards than I. Working on implementing that magic now.

Mac and Linux people, I have not forgotten you. I am putting a tentative release date for the Mac and Linux versions of Scraps at September 29th. Getting all that working perfectly will be the focus after this next update goes out next weekend.

 

Scraps version 0.5.2.0 is now live on Steam. I'll go into some more detail but here's the changelog first:

0.5.2.0
- Added full turret versions of the MMG and Medium Cannon, and a semi-fixed version of the Large Cannon. Balanced other weapons to match.
- Added Large Chassis.
- Some in-game CPU performance improvement, particularly for vehicles with many parts.
- Major in-game GPU performance improvement.
- Switched from DirectX9 to DirectX11.
- Increased max scrap limits a little (40,000->50,000 for 8 players. Select less Max Players for more).
- Build screen inventory shows a little icon next to turrets (weapons with full y-axis rotation).
- Small and Large sizes for the Proximity Firing mode.
- Made the spinning camera effect in menus much slower (it hurt some people's heads).
- Increased max suspension spring value by 25%.
- Darker shadows.
- More outlines on stuff.
- By popular request, leaderboard now only shows while the key (~ by default) is held.
- Background music for Round End and Game End screens.
- Other minor audio changes.
- Changed the angle calculation for projectile weapon trails - looks more "correct" when shot from moving vehicles.
- Added something to the Test Map?
Bug Fixes:
- In-game messages now show the correct amount of points a player earned from destroying another vehicle.
- Fixed weapon "can't fire" sound playing too much.

Weapons and Large Chassis







The new turret versions of the MMG and Medium Cannon can rotate fully around if the space is available, but cost a bit more. They should help in the early game against opponents who've unlocked other turret weapons. The semi-fixed version of the Large Cannon is cheaper and a little stronger.

One minor note: Currently in the "same type" weapon link mode, all the weapons are considered as different, whereas I'm sure it'd be better to have normal and turret types of the same weapon linked together. I'll change that in an update tomorrow.

Performance

The other major work in this update was on performance (check the changelog above for all the other, minor stuff).

I learned some graphics magic and implemented that to drastically reduce draw calls on the GPU, and graphics performance is now much improved. You might get a framerate that's improved 50% or more in some cases.

In fact GPU performance has got so much better, that the game is now often heavily CPU bound when dealing with complex vehicles with lots of weapons, mainly because of all the physics work. I also did some physics optimisation in this update, but it's not as drastic as the graphics improvement. I've pretty much optimised things as far as I can for now, and the next big step might be upgrading to Unity 5, since it's supposed to have that improved physics performance. Unfortunately before I update the game to Unity 5 I need to write a custom wheel collider (or buy someone else's one), because the built-in wheel colliders have changed completely and can't work well with Scraps anymore.

Graphics Batching

A few technical details here, particularly for Unity devs. The graphics improvement came from being able to combine more vehicle parts.

You guys will probably know that static 3D models - things that never move at all - can be marked as Static and get automatically batched by the graphics engine. Separate meshes, as long as they use the same material with the same shader, can be combined into one draw call, which means less work for the graphics card (although I'm no expert on how this stuff works exactly).

All parts on Scraps vehicles use the same material. All the part textures are baked into one big texture atlas image (think like the Minecraft texture file, but much bigger), and data in the vertices of the parts themselves determines whether they're shiny or dull, or damaged, or hot - allowing the whole thing to use the same single shader.

But that's not enough to get batching working on its own. Unity can do a small amount of "dynamic batching" - batching for objects that aren't Static - but its limit is only a few hundred polygons. One vehicle part has a few hundred already.

On the Build screen, your vehicle is always made up of the individual parts that you've placed. But one thing I was already doing is taking all the parts on a vehicle that don't move (I mean, the whole vehicle moves, but those parts all move together with it) and combining them into one big combined mesh when you entered a game. Having one combined mesh is the final tipping point to getting everything batched and reducing the draw calls. (When parts get destroyed I zero the appropriate ones out.)

That helped, but I couldn't combine anything that moved on its own, like weapon turrets and spinning fans, and there was still a lot of that.

Here's the trick. Unity devs, listen up, because I know there are others out there searching for the same powers I was searching for. Even batching stuff on the Asset Store often does less than this.

You can combine everything, and have the GPU do the transforms directly on the vertices of the parts that move to put them wherever they need to be. Create one model and change the model as you go. You could write a shader to do it, but you don't even have to, because Unity has built-in support for it. Ever used SkinnedMeshRenderer to animate something with bones? The transforms of the separate moving vehicle parts can be the bones! The Unify Wiki even has an example of how to do the conversion!

So now I combine everything, and it's real fast. There is a little bit of overhead in doing the transforms: People with DirectX11 or newer cards, you'll be doing it on the GPU (Devs, check your Player settings for the checkboxed to enable this and DX11 mode). Those with DX9 or DX10 cards will be doing it on the CPU. But it's a small amount of extra work either way compared to the gains in total performance.

Please use these powers responsibly.

What's Coming

For the next few weeks I'll be working on the Mac and Linux versions, with a plan to hopefully release those publicly on the 28th or 29th of this month. I'll be seeing how crazy or sane that deadline actually is in the next couple of days as I start testing on those platforms again.

I'm also aware that the multiplayer has gone quiet recently. I always feel especially sorry for that lone person on a server when the stats read 1/8 (sometimes I join for a few minutes ). I've been doing what I can with both some paid and unpaid marketing, and I have more to do, but the best thing I can really continue to do now is make the game as good as possible.

So the next major thing I'm currently planning to focus on after the Mac and Linux releases will be some expanded single-player content. I have a plan but I won't elaborate on that just now. That way even if things don't pick up multiplayer-wise there'll be more fun single-player stuff to do, so you shouldn't miss out too much either way.

Of course there's already the AI (and you can always Multiplayer -> Internet -> Host A Game with AI to play against, that's open to humans to join as well), and the Scraps demo can also join LAN games - so only one person needs to own the full version to play on LAN. Or if you can find some people that do have the full version, you can also host your own Internet games and they can join.

Thanks for continuing to follow Scraps.

 

Hi,

If it's helpful, I've been using Edy's Vehicle Pack to handle wheel colliders in my game. I have aircraft built at runtime from a variety of configurable parts with quite varied weights and rigidbody shapes, and the landing gear works nicely with EVP. Changing weight on the fly doesn't cause irregular behaviour either. Obviously you have your own use case, but it sounds superficially like this could be helpful?

 

Yeah, I know Edy has managed to work around the weirdness with Unity 5's wheel colliders as well (he talks about it a bit here and elsewhere in that thread). If I go for a third-party solution, or just want to check out how someone else did it so I can do my own version, his'll most likely be the one I go for.

Basically he says in that thread that the new friction model is so janky, he just doesn't use it and wrote a custom one from scratch instead. Certainly with the wide range of vehicles in Scraps I had no luck with a good solution when trying it out. It's sort of janky in Unity 4 as well but it could be wrangled into working. In Unity 5 you just can't have very heavy vehicles with enough friction to drive without them also jittering off into space.

 

Yeah, I had a look through your forum after writing that- there are some very cool limit-pushing designs (love the pirate ship) that are a long way outside the mass spectrum I'm working with. I'm also not applying torque through the wheels, rather taxiing with engine thrust- it did take a bit of work to get braking working so imagine driving the wheels would have been temperamental. Hope you do find a solution though, the PhysX update is more efficient overall.

 

People have made some amazing stuff!

I don't apply torque though the wheels either (even in Unity 4). Just a force. It kinda made it too hard to design good vehicles. Too easy to get the centre of mass a little off and do massive wheelies everywhere and stuff like that.

Edit: Did you ever see how the old Unity car tutorial did its driving physics? It was so weird.
They applied a “drag” force each tick (separate to the rigidbody's drag, which they actually left at 0). They increased the “drag” with speed, and did some crazy stuff with it for handbraking. Instead of using physics to turn and adding anti-roll, they just rotated the actual object directly with transform.RotateAround.

 

Just a short announcement that the Scraps Mac and Linux versions are set for a Monday September 28th release on Steam, and are looking good.

Some Scraps players on the forum have also been organising a time to join multiplayer, so if you want to get in some multiplayer when there're people on, check out this thread: http://forum.scrapsgame.com/t/weekly-games/335

The scheduled one right now is for 8pm EDT on the 19th. That's midnight UTC. Here's a timezone converter that should tell you when that is in your local time.

 

Actually had lots of people on for the organised game above. Would be good to do it again sometime.

I did some recording while I was on:

 

Good times testing in the editor with debug lines on.

 

Have been testing Scraps with multiplayer on Windows, Mac and Linux machines all in the same game simultaneously today. Quite pleased with how smoothly it's all working.

 

Enemy ship spotted on the horizon.

 

Early progress on a new map.

 

The Scraps "weekly game" is happening again this week, where everyone is invited to join the multiplayer at roughly the same time to get some people on playing together.

The main one is again at 8pm EDT on Saturday (that's midnight UTC). But if that's out of your timezone or you just want to play twice, try coming on 12 hours earlier at 8am EDT (midday Saturday UTC).

I've added both to the Steam events calendar which should also auto-convert to your timezone:http://steamcommunity.com/games/350150/events

 

People are starting to filter in for the weekly game time. Come join!

 

Scraps repository visualisation of development so far:

This is a visualisation of files in the scraps version control repository over time using a tool called Gource. It's missing the first few months of development where I was using a different repository, hence the early file-splosion.

Apparently I set the speed a bit too fast for Gource to keep up with the dates: The early big influx of files is an initial import (stuff from the previous repo), and then it keeps going a bit after the present date is reached at the end. I didn't actually travel to the future yet (waiting till October 21 for that).

 

Right, packages are updated, depots uploaded, game updated etc and Scraps versions for Mac and Linux are now available alongside Windows. They're all fully cross-compatible so you should be able to play in the same game with people from all three OS's.

There are just a few known issues right now:

Known Issues

Windows:
- None.

Mac:
- When playing singleplayer or hosting a multiplayer game, a Scraps Server icon appears and sits bouncing in the dock.

Linux:
- MSAA anti-aliasing settings may not work in-game. You may be able to work around this by manually enabling AA in your graphics driver settings. e.g. For Radeon cards, open Catalyst Control Center and go to 3D -> Anti-Aliasing, then set Mode to "Override application settings" and set Level where you like (4x is nice).
- On multi-monitor setups, screen resolutions may show up as options that are higher than your main monitor's resolution. If selected they'll look wrong and you'll just need to change it back to a lower resolution.

Changes

I've also had time to make a few updates to the game:

Aiming

This was partly a performance choice (the new system requires a few less checks), but the aiming system now works a little differently. Whereas all the little weapon cross-hairs used to show what they'd actually hit if firing in a straight line, they now essentially just show the aim direction of that weapon. Theoretically that sounds worse, but in practice the old system was often a bit confusing when trying to aim at something, and it caused some issues like getting really close to a vehicle and having your cross-hairs sort of sweep out of the "proximity aiming" circle range. Bullet drop from some weapons also sort of negated its usefulness. See what you think.

Aiming things with a camera that's at a different place than the things is always a little complicated. Some games just cheat and shoot everything straight out of the camera, but that causes some other issues - you get people doing stuff like shooting over walls they're hiding behind.

Health info for key parts



As shown above. Gives a better idea of things than just the damage textures. Showing health for all parts on the vehicle is a bit much, but the cockpit and chassis are the ones that actually get you destroyed, and they also tend to have the most HP, so they're useful to see in more detail.

The labels and icons over enemy vehicles fade in and out at different distances, to try and avoid blocking your view. All the bars are also sized based on total HP - that is, stuff with more HP starts with a bigger bar, and the same amount of damage will also take off the same chunk.

Blocks



Lots more basic block shapes.

Full Changelog

2015-09 - 0.5.2.5
- Added cross-platform Mac and Linux OS support!
- Updated player name labels and added health info for their key parts under the label.
- Also added health info for the player's own key parts into the GUI.
- Rounded off the bridge on SandyBridge a little (less getting stuck on the corner).
- Reticles (crosshairs) for active weapons now show them aiming at infinity, instead of showing them on what they'll actually hit if firing straight.
- Added several additional basic blocks.
- The "wealth multiplier" that increases costs for rich players now (more logically) only takes vehicle value into account, rather than total wealth.
- Vehicle scrap value now also takes part damage into account (damaged parts have less value).
- Reduced max collision damage a little.
- Updated Russian translation text.
- When choosing an initial game resolution, if your native res is ridiculously high (looking at you, Retina displays!), the game looks for a good lower one at the same ratio so you're not squinting at tiny menus. On Linux Scraps will actually start windowed the first time it boots instead to avoid the following known issue. You can still set fullscreen and any resolution in the game options.
Bug Fixes:
- Scrolling the inventory no longer also zooms the vehicle camera.
- Fixed a server memory leak that I accidentally introduced in the previous release.
- Fixed loading text not updating to the new language right away when the language was changed.

 

Scraps v0.5.2.7 http://www.scrapsgame.com/scraps-v0-5-2-7

Also not sure if the "weekly game" will happen this week but if people come it will happen. Join Scraps MP in about 15 minutes from right now.

 

And it's Weekly Game time today again later today: http://steamcommunity.com/games/350150/events/105063526136670299
As always it just depends on whether people feel like coming on for a game, so try coming on around that time if you're looking for some Scraps multiplayer.

 

Help, stuck in design hell trying to make buttons with icons that make sense.

I need three buttons:
- Big main button, repair and rebuild your vehicle as much as you can afford (background colour of the button will change depending on if you can fully afford it).
- Smaller button to just repair damaged parts (not replace totally destroyed ones).
- Another smaller button to just rebuild destroyed parts, but not repair damaged parts.

I like this one with vehicle silhouettes but I'm not sure how clear it is. And the silhouette at the top looks blah.



Maybe this one with icons is clearer, or maybe it's just more confusing:



Edit: Alt 3:



Edit 2: Another one:

 

I haven't played the game (I'll probably pick it up soon, been watching this game for a while, it looks great!), but personally I like the last (Alt 3) version best. It seems the most elegant and pretty, however I can understand why you like the first version as it's more descriptive to new players who may be unfamiliar to what each button does... Is it possible to sort of split the difference and have it so when the player hovers their mouse over each button, a description appears ("Repair remaining parts.", "Rebuild destroyed parts.", "Rebuild and repair vehicle."). That way, the UI looks elegant and yet still helps brand new players understand what each button does?

Maybe not what you're going for, not sure what the rest of the UI looks like or how it functions... However if you are leaning towards the first version, maybe just a prettier looking silhouette for the vehicle would do?

And just to finish my opinion on the images, the second version did make it more confusing for me.

And one question on functionality; when selecting the center button (repair/rebuild), which action takes precedence? For example, if the player cannot afford both, does it repair the vehicle first or rebuild destroyed parts first? Perhaps you only need two buttons that way allowing the player to decide which action takes priority? Again, not familiar with the rest of the game, just a passing thought an off chance it may help! Otherwise, ignore this.

 

I'll repair first and then rebuild once that's at 100%. There's also a separate "repair mode" that players can use where they can click specific parts to repair (allowing more specific choice if you've got limited funds). There's no "rebuild mode" but for lost parts, you can always manually add them back one by one instead of using the automatic system.

Are you suggesting having one button that repairs first, then rebuilds, and another that rebuilds first, then repairs? That's a very clever idea, although I think the current system allows a little more control. Still, it's always a balance between functionality and simplicity.

 

I like your idea, but what I was suggesting was maybe something even simpler. Maybe the two buttons could instead be one for repairing and the other for rebuilding, removing the repair/rebuild button in the center. That way the player can select which takes precedence and simplify the UI, giving control and simplicity. The middle button in your example images could be somewhat confusing if the player doesn't have sufficient funds to complete the repair and rebuild at once (which happens first?). Again, haven't played the game yet so maybe having the quick "I don't care what you repair/rebuild, just get me back in the game, now!" button is nice to have. Just thinking in terms of pretty/simple/useful, but not "what's best for Scraps". When I pick up the game maybe I'll be able to give more accurate feedback!

 

Alt 3 is good. I think my favorite is the last one (edit 2) by a bit, though.

Same here.

That sounds good to me! Always bugs me (a bit) when UI's don't have a text version for commands/icons somewhere (toggleable global tooltips is preferred). Makes you have to actually perform unwanted actions just to figure out what each thing does. (just my 2 cents--no idea where that phrase came from, but it seems to express my tone atm)

 

Yep yep. It could work with two buttons. It's just that I suspect most of the time you'll actually want both - to have it just do as much as you can afford. So I wanted to have that as the big JUST DO IT button. As you say it's basically the "I don't care what you repair/rebuild, just get me back in the game, now!" button to save a little time.

Also, definitely it will have tooltips, and simple text under the buttons as well.

 

Oh, that last one was added while I was writing my initial feedback on the images, didn't see it. But yes, I agree. The last one (Edit 2) does win out by a bit IMO; the hammer says "rebuild" maybe a little clearer than the blowtorch.

 

Apologies or the lateness of this update. I wasn't able to do Scraps work last week due to some real life events, and this week is going to be the same. Rather than having to push the next update way back, I've managed some time to clean up and release a smaller update today that still has the two major features I mentioned last time, plus a few other things as well.

Full changelog:
2015-10 - 0.5.2.9
- ## Added ability to rebuild as well as repair damaged vehicles while in-game.
- ## Wreckage pickup is easier, it kind of "attracts" towards you.
- Some general balance tweaks to wreckage.
- Improved the AI's weapon selection methods.
- Different sounds for each type of vehicle warning.
- Parts now sell for their purchase value, taking any wealth tax into account, so you never lose money.
- Increased steering speed for keyboard controls a little.
- Refreshing the server list clears the old list when it was user-prompted, just so it's more obvious that it's doing something.
- Updated Steamworks.NET and uLink versions.
Bug Fixes:
- Workaround for an issue in Steam where sometimes only the first two lobbies got returned.
- Spawn FX no longer show when creating existing vehicles as a player joins a game that's already in progress.
- Vehicle labels no longer show on top of loading screen dialogs.
- Fixed AI looking as if they repair right before they evac, instead of after.
- Fixed audio screeches and other silliness that sometimes occurred when entering maps.
- Fixed a bug with part costs and wealth tax when ctrl-placing parts.
- Fixed another bug with wealth tax when calculating estimated repair costs.


Rebuilding


You can now rebuild lost parts automagically after using evac pads (if you can afford it).

There are several ways this could work. As with my general philosophy for Scraps I've tried to balance functionality against complexity. At the moment it works like this:

• Parts lost in-game count as ones to rebuild. Parts you manually remove on the Build Screen don't.
  
• Removing a part on your vehicle on the Build Screen doesn't clear the rebuild list, but if parts in the rebuild list depended on that removed part, they'll fail to get added back. You won't be charged for those failed parts.
  
• Adding a part to your vehicle on the Build Screen clears the rebuild list and sets the current vehicle as the "base" vehicle that'll be rebuilt to. This means you can build on your saved vehicle during a game and rebuild back to your temporarily improved one after you lose parts in battle, but it does also mean that adding a part when you have parts to rebuild will lose you that rebuild list. It's a compromise because once you start trying to handle these sort of branching trees of vehicle designs the complexity of the system skyrockets.

The Scraps Community
Just a note on the Scraps community in general: You guys are the best. While other people are complaining about their toxic game communities and "it broke plz fix" bug reports, Scraps players are sending me bug reports with a video of the bug happening. Recently I got a bug report that came with a suggested fix that was actually a good solution! In game dev circles that's usually accompanied by pigs flying.

It was so nice to come back after not being able to check up on the game for a few days to see three new super nice reviews (especially coming not too long after one that began with "honestly the worst game I have ever played..."). It's always especially cool to hear from people that have been following things since the early Builder Demo-only days. I know Scraps dev can be slow so I appreciate the people that keep checking back even more.

 

Technical post.

A long time ago Unity released a Car Tutorial that had some nice skidmarks for the car, but the skidmarks script did a whole bunch of unnecessary stuff and generated a ridiculous amount of garbage as it ran, causing the garbage collector to freak out about once a second and use about 25% of the CPU in the frame collecting a bunch of meshes. I had some skidmark code based on it in early versions of Scraps, but it had the same terrible garbage issues so I took it out rather than fix it at the time.

In the meantime I looked over a few other skidmark solutions but they all had issues of their own. For instance some were trail renderer-based and had the marks (all of them) disappearing as soon as the vehicle stopped skidding ("it's not a bug, it's a feature").

Recently someone contacted me to ask if I'd ever worked it out, and while I hadn't, we had some back and forth on it and he pointed out to me that it was possible to do it the original mesh-based way without generating so much garbage. Today I made that happen, so here it is, a modified version of the old Car Tutorial skidmarks that doesn't generate the garbage, doesn't count up numMarks forever, and doesn't do all that unnecessary mesh assignment in LateUpdate:

Code (CSharp):

1.  
2. using UnityEngine;
3.  
4. // Skidmarks texture. Only need one of these in a scene somewhere. Call AddSkidMark.
5. public class Skidmarks : MonoBehaviour {
6.     // INSPECTOR SETTINGS
7.  
8.     // Material for the skidmarks to use
9.     [SerializeField]
10.     Material skidmarksMaterial;
11.  
12.     // END INSPECTOR SETTINGS
13.  
14.     // Variables for each mark created. Needed to generate the correct mesh.
15.     class MarkSection {
16.         public Vector3 Pos = Vector3.zero;
17.         public Vector3 Normal = Vector3.zero;
18.         public Vector4 Tangent = Vector4.zero;
19.         public Vector3 Posl = Vector3.zero;
20.         public Vector3 Posr = Vector3.zero;
21.         public byte Intensity;
22.         public int LastIndex;
23.     };
24.  
25.     const int MAX_MARKS = 1024; // Max number of marks total for everyone together
26.     const float MARK_WIDTH = 0.35f; // Width of the skidmarks. Should match the width of the wheels
27.     const float GROUND_OFFSET = 0.02f;    // Distance above surface in metres
28.     const float MIN_DISTANCE = 1.0f; // Distance between points in metres. Bigger = more clunky, straight-line skidmarks
29.     const float MIN_SQR_DISTANCE = MIN_DISTANCE * MIN_DISTANCE;
30.  
31.     int markIndex;
32.     MarkSection[] skidmarks;
33.     Mesh marksMesh;
34.     MeshRenderer mr;
35.     MeshFilter mf;
36.  
37.     Vector3[] vertices;
38.     Vector3[] normals;
39.     Vector4[] tangents;
40.     Color32[] colors;
41.     Vector2[] uvs;
42.     int[] triangles;
43.  
44.     bool updated;
45.     bool haveSetBounds;
46.  
47.     // #### UNITY INTERNAL METHODS ####
48.  
49.     protected void Start() {
50.         skidmarks = new MarkSection[MAX_MARKS];
51.         for (int i = 0; i < MAX_MARKS; i++) {
52.             skidmarks[i] = new MarkSection();
53.         }
54.  
55.         mf = GetComponent();
56.         mr = GetComponent();
57.         if (mr == null) {
58.             mr = gameObject.AddComponent();
59.         }
60.  
61.         marksMesh = new Mesh();
62.         marksMesh.MarkDynamic();
63.         if (mf == null) {
64.             mf = gameObject.AddComponent();
65.         }
66.         mf.sharedMesh = marksMesh;
67.  
68.         vertices = new Vector3[MAX_MARKS * 4];
69.         normals = new Vector3[MAX_MARKS * 4];
70.         tangents = new Vector4[MAX_MARKS * 4];
71.         colors = new Color32[MAX_MARKS * 4];
72.         uvs = new Vector2[MAX_MARKS * 4];
73.         triangles = new int[MAX_MARKS * 6];
74.  
75.         mr.castShadows = false;
76.         mr.receiveShadows = false;
77.         mr.material = skidmarksMaterial;
78.         mr.useLightProbes = false;
79.     }
80.  
81.     protected void LateUpdate() {
82.         if (!updated) return;
83.         updated = false;
84.  
85.         // Reassign the mesh if it's changed this frame
86.         marksMesh.vertices = vertices;
87.         marksMesh.normals = normals;
88.         marksMesh.tangents = tangents;
89.         marksMesh.triangles = triangles;
90.         marksMesh.colors32 = colors;
91.         marksMesh.uv = uvs;
92.  
93.         if (!haveSetBounds) {
94.             // Could use RecalculateBounds here each frame instead, but it uses about 0.1-0.2ms each time.
95.             // Save time by just making the mesh bounds huge, so the skidmarks will always draw.
96.             // Not sure why I only need to do this once, yet can't do it in Start (it resets to zero).
97.             marksMesh.bounds = new Bounds(new Vector3(0, 0, 0), new Vector3(10000, 10000, 10000));
98.             haveSetBounds = true;
99.         }
100.  
101.         mf.sharedMesh = marksMesh;
102.     }
103.  
104.     // #### PUBLIC METHODS ####
105.  
106.     // Function called by the wheels that is skidding. Gathers all the information needed to
107.     // create the mesh later. Sets the intensity of the skidmark section b setting the alpha
108.     // of the vertex color.
109.     public int AddSkidMark(Vector3 pos, Vector3 normal, float intensity, int lastIndex) {
110.         if (intensity > 1) intensity = 1.0f;
111.         else if (intensity < 0) return -1; if (lastIndex > 0) {
112.             float sqrDistance = (pos - skidmarks[lastIndex].Pos).sqrMagnitude;
113.             if (sqrDistance < MIN_SQR_DISTANCE) return lastIndex;
114.         }
115.  
116.         MarkSection curSection = skidmarks[markIndex];
117.  
118.         curSection.Pos = pos + normal * GROUND_OFFSET;
119.         curSection.Normal = normal;
120.         curSection.Intensity = (byte)(intensity * 255f);
121.         curSection.LastIndex = lastIndex;
122.  
123.         if (lastIndex != -1) {
124.             MarkSection lastSection = skidmarks[lastIndex];
125.             Vector3 dir = (curSection.Pos - lastSection.Pos);
126.             Vector3 xDir = Vector3.Cross(dir, normal).normalized;
127.  
128.             curSection.Posl = curSection.Pos + xDir * MARK_WIDTH * 0.5f;
129.             curSection.Posr = curSection.Pos - xDir * MARK_WIDTH * 0.5f;
130.             curSection.Tangent = new Vector4(xDir.x, xDir.y, xDir.z, 1);
131.  
132.             if (lastSection.LastIndex == -1) {
133.                 lastSection.Tangent = curSection.Tangent;
134.                 lastSection.Posl = curSection.Pos + xDir * MARK_WIDTH * 0.5f;
135.                 lastSection.Posr = curSection.Pos - xDir * MARK_WIDTH * 0.5f;
136.             }
137.         }
138.  
139.         UpdateSkidmarksMesh();
140.  
141.         int curIndex = markIndex;
142.         // Update circular index
143.         markIndex = ++markIndex % MAX_MARKS;
144.  
145.         return curIndex;
146.     }
147.  
148.     // #### PROTECTED/PRIVATE METHODS ####
149.  
150.     // Update part of the mesh for the current markIndex
151.     void UpdateSkidmarksMesh() {
152.         MarkSection curr = skidmarks[markIndex];
153.  
154.         // Nothing to connect to yet
155.         if (curr.LastIndex == -1) return;
156.  
157.         MarkSection last = skidmarks[curr.LastIndex];
158.         vertices[markIndex * 4 + 0] = last.Posl;
159.         vertices[markIndex * 4 + 1] = last.Posr;
160.         vertices[markIndex * 4 + 2] = curr.Posl;
161.         vertices[markIndex * 4 + 3] = curr.Posr;
162.  
163.         normals[markIndex * 4 + 0] = last.Normal;
164.         normals[markIndex * 4 + 1] = last.Normal;
165.         normals[markIndex * 4 + 2] = curr.Normal;
166.         normals[markIndex * 4 + 3] = curr.Normal;
167.  
168.         tangents[markIndex * 4 + 0] = last.Tangent;
169.         tangents[markIndex * 4 + 1] = last.Tangent;
170.         tangents[markIndex * 4 + 2] = curr.Tangent;
171.         tangents[markIndex * 4 + 3] = curr.Tangent;
172.  
173.         colors[markIndex * 4 + 0] = new Color32(0, 0, 0, last.Intensity);
174.         colors[markIndex * 4 + 1] = new Color32(0, 0, 0, last.Intensity);
175.         colors[markIndex * 4 + 2] = new Color32(0, 0, 0, curr.Intensity);
176.         colors[markIndex * 4 + 3] = new Color32(0, 0, 0, curr.Intensity);
177.  
178.         uvs[markIndex * 4 + 0] = new Vector2(0, 0);
179.         uvs[markIndex * 4 + 1] = new Vector2(1, 0);
180.         uvs[markIndex * 4 + 2] = new Vector2(0, 1);
181.         uvs[markIndex * 4 + 3] = new Vector2(1, 1);
182.  
183.         triangles[markIndex * 6 + 0] = markIndex * 4 + 0;
184.         triangles[markIndex * 6 + 2] = markIndex * 4 + 1;
185.         triangles[markIndex * 6 + 1] = markIndex * 4 + 2;
186.  
187.         triangles[markIndex * 6 + 3] = markIndex * 4 + 2;
188.         triangles[markIndex * 6 + 5] = markIndex * 4 + 1;
189.         triangles[markIndex * 6 + 4] = markIndex * 4 + 3;
190.  
191.         updated = true;
192.     }
193. }
194.  

Put that script anywhere in a scene. It needs a MeshFilter and MeshRenderer, but it'll generate them itself. You probably want your skidmarks material to have less than 100% alpha. I've uploaded just the shader from the Car Tutorial here.

Call AddSkidmark wherever you want them and keep track of the lastSkid, clearing it when you want them to stop: I'm using the GetGroundHit data from the wheels each FixedUpdate. You might want to adjust for the forward velocity of your vehicle so they don't look like they're generating just behind the wheels. Example usage:

Code (CSharp):

1.  
2. WheelHit wheelHitInfo;
3. if (wheelCollider.GetGroundHit(out wheelHitInfo)) {
4.     // Check sideways speed
5.     // Gives velocity with +Z being our forward axis
6.     Vector3 localVelocity = transform.InverseTransformDirection(rigidbody.velocity);
7.     float skidSpeed = Mathf.Abs(localVelocity.x);
8.     if (skidSpeed >= SKID_FX_SPEED) {
9.         // MAX_SKID_INTENSITY as a constant, m/s where skids are at full intensity
10.         float intensity = Mathf.Clamp01(skidSpeed / MAX_SKID_INTENSITY);
11.         Vector3 skidPoint = wheelHitInfo.point + (rigidbody.velocity * Time.fixedDeltaTime);
12.         lastSkid = Skidmarks.AddSkidMark(skidPoint, wheelHitInfo.normal, intensity, lastSkid);
13.     }
14.     else {
15.         lastSkid = -1;
16.     }
17. }
18.  

(smoke not included)

This'll be in the next Scraps update.

 

I've added a new map called RiverRift to the game. It's got jumps as shortcuts, water, and a big rift in the ground that you can shove vehicles in to destroy them.









Skidmarks are finally back (see my post here for a technical writeup on the skidmarks effect).



And leaderboards now show whether other players have their vehicles currently in-game.





Icons are a vehicle on terrain for in-game, a spanner & hammer for build screen, and a dash for no vehicle.

I've also adjusted vehicle speeds a little: Very light vehicles will be a little slower, but heavier vehicles will generally be a bit faster now with the same engine configuration. Mass in general had a little too much effect on speed.

The first time I made the change I set the multiplier too high. Actually so high the frame optimisation ruined this gif I tried to make of it:



You'll also find a little more wreckage drops in general, due to a change of calculation for drop amount from reliant parts (when a part is destroyed that has other parts that are reliant on it for their connection to the vehicle).

Full Changelog
2015-11 - 0.5.2.11
- New engine power calc. Very light vehicles are now a little slower, but heavy vehicles are significantly faster.
- Vehicles with a high centre of mass are a bit less prone to tipping over.
- Better wreckage spawn calculation; reliant parts get sorted by cost.
Bug Fixes:
- Fixed SFX volume, which was no longer affecting all sounds.
- Better collision damage calculation in some cases.

2015-11 - 0.5.2.10
- ## New Map - RiverRift.
- ## Skidmarks make a triumphant return, now without the ridiculous garbage generation.
- Minor work on existing terrain FX.
- Improved game camera obstacle avoidance.
- Added icons to leaderboards to show player's vehicle state (none/in-game/building).

A little driving tour of the new map:

 

Smallish update today:

2015-11 - 0.5.2.13
- AI is much, much less likely to follow you off a cliff
- Added top speed guess to the Build screen stats
- Performance: More efficient terrain rendering
- Reduced HP on Medium and Heavy cockpits
- Made heavy vehicles a little faster

You can now see a reasonable estimate of your vehicle's top speed in the build screen stats:


It'll show up in mph if you have that set instead.

 

Pleasantly surprised to see Scraps as a gift with the latest PC Gamer. Nice work! Hopefully the increased community size will draw in more players for you.

Was it an easy process dealing with PCG?

 

Bit of an experiment, that. It'd be nice to get more players on and more exposure for the game, and a key with a copy of a physical magazine seemed much less likely than online bundles and giveaways to end up with people reselling keys and undercutting real sales. I'm also just an old fan of PC Gamer.

I'd run a paid ad with them once before which may have helped me seem legit but yeah I just asked them about running the promo - I'd seen Manastorm do it the month before - and they said OK.

 

Just a Scraps Weekly Game reminder.

A while ago a few people organised an unofficial "Weekly Game" where people would try to come onto Scraps multiplayer at the same time to play together. These have been going on for a while now and they're sometimes more popular than others, but if you're looking for people to play against, coming on at one of these times is probably your best bet:

• The main one is at midnight Saturday UTC. That linked Steam event will automatically adjust its timezone to match the region you have set in Steam if you're logged in.
  
• If that doesn't work for you, there's an alternate time 12 hours earlier at midday Saturday UTC.

There's no official server to join - either people join one of my official ones or they create their own with custom settings. Again these are just unofficial things - no guarantees of attendance - but it's been good fun in the past.

 

Here's a bit of a look back at three years of Scraps development: http://www.scrapsgame.com/three-years-of-scraps-development

 

Shown in editor view, but in-game the effect is the same.

I have some light beams that come out of the ground. Without fog, everything looks OK:


But with fog on (the skybox is also on here), someone's wrong. The glass parts of the walls in the background aren't blending properly:


The glass in the background is using the default Unity 4 Unlit Transparent shader. It seems like having it as any sort of transparent shader causes the issue, so from that I can say the problem is with viewing transparent objects through the light beams.

The light beam shader is this:

Code (csharp):

1.  
2. Shader "Custom/MovingLightBeam" {
3.     Properties {
4.         _MainTex ("Particle Texture", 2D) = "white" {}
5.         _TintColor ("Tint Color", Color) = (1,1,1,1)
6.         _InvFade ("Soft Particles Factor", Range(0.01,3.0)) = 1.0
7.     }
8.  
9.     Category {
10.         Tags { "Queue"="Transparent" "IgnoreProjector"="True" "RenderType"="Transparent" }
11.         Blend One OneMinusSrcColor
12.         ColorMask RGB
13.         Cull Off Lighting Off ZWrite Off Fog { Color (0,0,0,0) }
14.         BindChannels {
15.             Bind "Color", color
16.             Bind "Vertex", vertex
17.             Bind "TexCoord", texcoord
18.         }
19.  
20.         // ---- Fragment program cards
21.         SubShader {
22.             Pass {
23.      
24.                 CGPROGRAM
25.                 #pragma vertex vert
26.                 #pragma fragment frag
27.                 #pragma fragmentoption ARB_precision_hint_fastest
28.                 #pragma multi_compile_particles
29.  
30.                 #include "UnityCG.cginc"
31.  
32.                 sampler2D _MainTex;
33.                 fixed4 _TintColor;
34.          
35.                 struct appdata_t {
36.                     float4 vertex : POSITION;
37.                     fixed4 color : COLOR;
38.                     float2 texcoord : TEXCOORD0;
39.                 };
40.  
41.                 struct v2f {
42.                     float4 vertex : POSITION;
43.                     fixed4 color : COLOR;
44.                     float2 texcoord : TEXCOORD0;
45.                     #ifdef SOFTPARTICLES_ON
46.                     float4 projPos : TEXCOORD1;
47.                     #endif
48.                 };
49.  
50.                 float4 _MainTex_ST;
51.          
52.                 v2f vert (appdata_t v)
53.                 {
54.                     v2f o;
55.                     o.vertex = mul(UNITY_MATRIX_MVP, v.vertex);
56.                     #ifdef SOFTPARTICLES_ON
57.                     o.projPos = ComputeScreenPos (o.vertex);
58.                     COMPUTE_EYEDEPTH(o.projPos.z);
59.                     #endif
60.                     o.color = v.color * _TintColor;
61.                     o.texcoord = TRANSFORM_TEX(v.texcoord,_MainTex);
62.                     return o;
63.                 }
64.  
65.                 sampler2D _CameraDepthTexture;
66.                 float _InvFade;
67.          
68.                 fixed4 frag (v2f i) : COLOR
69.                 {
70.                     #ifdef SOFTPARTICLES_ON
71.                     float sceneZ = LinearEyeDepth (UNITY_SAMPLE_DEPTH(tex2Dproj(_CameraDepthTexture, UNITY_PROJ_COORD(i.projPos))));
72.                     float partZ = i.projPos.z;
73.                     float fade = saturate (_InvFade * (sceneZ-partZ));
74.                     i.color.a *= fade;
75.                     #endif
76.              
77.                     half4 prev = i.color * tex2D(_MainTex, i.texcoord);
78.                     prev.rgb *= prev.a;
79.                     return prev;
80.                 }
81.                 ENDCG
82.             }
83.         }  
84.  
85.         // ---- Dual texture cards
86.         SubShader {
87.             Pass {
88.                 SetTexture [_MainTex] {
89.                     combine texture * primary
90.                 }
91.                 SetTexture [_MainTex] {
92.                     combine previous * previous alpha, previous
93.                 }
94.             }
95.         }
96.  
97.         // ---- Single texture cards (does not do particle colors)
98.         SubShader {
99.             Pass {
100.                 SetTexture [_MainTex] {
101.                     combine texture * texture alpha, texture
102.                 }
103.             }
104.         }
105.     }
106. }
107.  

Does anyone know what I'd need to change to get it blending nicely?