[PC] Scraps: Modular vehicle combat

Yeah, it was a little unfortunate that not too long after I started Scraps, Freejam first announced Robocraft, which really is quite similar. Although Scraps has much more of a focus on functional, inter-dependent parts and physics.

Didn't win at PlayByPlay but that's all good; here's

--Super secret new content preview #2/10--​

I made some stationary gun turrets to use for the currently-in-development new game mode.





I've also written some simple AI for them.

Note that generator and those heat-sinks: They also have inter-dependent functional parts like vehicles. Here's a demo video of everything where I explain what's going on:

By the way, I didn't really mean to take two weeks between super secret new content previews - subsequent ones may be closer together. I managed to reproduce a stack overflow crash that I've been seeing sometimes come up in automated error reports, but haven't been able to reproduce myself until now. So I've been looking into that as well and it's been a bit of a rabbit hole.

At the moment if you run Scraps for more than an hour or two in one game (without quitting to the menu and starting a new one), and there's heavy action like seven AI all fighting, it might occur. It shows itself in a way where the game will still be running but it'll be behaving strangely and weapons won't seem to do damage anymore.

It's proven very elusive and frustrating to track down. The stack overflow doesn't include a stack trace or any additional information with it. I think it's related to a memory leak but the memory leak itself is proving very difficult to find. A leaked object like a vehicle mesh would be easy to detect, but instead it's data on the heap and the Unity engine allows me no way to see what's on the heap, just that the heap size keeps growing. I've spent too long trying different things and checking old versions already so I'm going to keep working on new content by day, and hack apart a branch when I've got time in the evenings, until I've unveiled the culprit there as well.

 

This week I made a flying drone enemy type.



They track you, zip around the place, and are fun to shoot.

Initial tests were interesting, almost boids-like:



I found that for the drones I could use a surprising amount of the same code I used for the turrets which was nice. Apart from the actual flying code, a drone is pretty much a turret that moves. And similarly to the turrets I showed last week, they're made of functional parts just like vehicles. Here's a group of them where the one on the right has lost its heat sink and is starting to overheat, and another gets it heat sink shot off:


(sorry for the huge gif! Webm support will get better one day...)

I gave the drones some basic AI. I won't claim it's anywhere near as interesting as Dave's vehicle AI but it doesn't need to be in this case. They don't "fake" their flying though, they thrust around with real physics, so of course you can shoot or crash into them to throw them off. Hitting stuff way up in the air is tricky and not really good fun, so I've designed them to hover along close to the ground.

You can see the physics at work in this scenario when I first gave them weapons...



Yeah so, standard recoil is a bit much for them. Hence I must confess they are cheating a little now: It was either spend ages writing some smart AI that'd attempt to counter weapon recoil while flying somehow, or just let them have less recoil on their guns. I hate it when AI gets to cheat (vehicle AI never cheats by the way, it only sees what it can actually see and collects only scrap that it really collects) but the pragmatic choice here was obvious. So the drones you see elsewhere in this post are using specially engineered reduced-recoil MMGs.

See you next week.

 

Super Secret New Content Preview #4/10



Scraps vehicles so far always ostensibly have a human driver in a cockpit. Even if they're actually controlled by the AI, there's a cockpit that a person can fit in.

I wanted some mini vehicles as a sort of starter enemy, more like a ground-based fancier version of the drones I showed earlier. Easy enough to code because they're still vehicles, but different. Instead of a human driver in a cockpit they have a Brain CPU.




It's still a key component of the vehicle so the vehicle is lost if it's destroyed, like with the standard cockpits.

I made it a micro chassis to use, that'd be too small for a normal cockpit.



To be clear, the CPU cockpit and micro chassis aren't player usable, at least not with my current plans. They're just for fighting against. Look how cute it is though.





I'm going to be away on family business for a few days next week (actually I'm already away now!) so I'm not sure if Super Secret New Content Preview #5 will make it on on schedule next weekend. But I'm hoping I'll get enough work time in that it will.

 

Super secret new content preview #5/10: Road Encounter

A small taste of things to come.

 

Super secret new content preview #6/10: Less of a preview, more of a discussion

For the first couple of days this week I was working on something that I then decided against. I've got other work done but it's not really ready to show, it's mostly just code that doesn't visibly do anything yet. So let's talk about the other thing I was working on because I'm interested in what people think as well. I do apologise that this isn't much of an interesting "preview."


Part Wreckage
Ever since I started working on the scrap wreckage system for Scraps, I intended there to be two types of drops. When you destroyed parts, you'd be able to collect general wreckage that was like cash you could spend on parts during a game, after using an Evac Pad. That part's in the game now. But there was also meant to be a chance that a whole part would drop when you destroyed one on an enemy. They'd have some amount of damage already applied like say 0-50%.

This got left out initially just so I could get the game out a bit sooner, but I wanted it for the new game mode. Some code was there, and I started adding the rest to get it all working. I got as far as having the part wreckage spawn, but not as far as making the interface for you to spend it, before I changed my mind.



My original idea was that if you picked up a part, it'd now be a free part to use on the Build screen (if you used an Evac Pad - if you died you'd lose it like with wreckage scrap). And so you could end up with a conglomerative scrap creation built of all sorts of scavenged parts, and I figured that'd be cool. But I weighed up the pros and cons again as I was restarting work on it, and I came up with:

Pros:

• Interstate '76 did it and it was cool. At the end of each mission you'd get salvage parts you could use to slowly upgrade your car. They'd have damage to repair as well. And it was fun.
  
• It'd make enemy drops basically like a loot system in an RPG, which is a time-tested effective system. General scrap drops are like coins and part drops are like gear/items.
  
• It'd encourage interesting builds and often it is limitations that end up inspiring real creativity. Plus it'd provide more variation to the game in general. Work with what you've got, try new things, and building ridiculous vehicles out of a bunch of scavenged parts is well within the Scraps philosophy.

Cons:

• Interstate '76 is a different game to Scraps, and while it worked well there, you couldn't buy parts at all – it was all salvage. So the parallel doesn't quite apply.
  
• It could prevent interesting designs as much as it might encourage them, forcing people to use certain parts rather than follow their ideas. I've seen that Robocraft (a game with a similar concept to Scraps) recently switched from a money system to a loot drop system, and everyone hates it, because they can't build what they want. Part drops would similarly stop people from building what they want.

Ultimately I'm thinking it's actually a better idea to leave things as-is. If I did do it, I'd certainly make it optional in melee mode (the current game mode). If I really want some special weapon to drop from some special vehicle, it could instead drop a "token" that simply unlocks that special part as available to build normally (i.e. buy it with scrap).

 

Someone reminded me about selling parts. Selling parts is another complication. If you put a part on your vehicle and then delete it, you get its current value back. But if you can sell salvaged parts for full value then the feature is almost pointless! - the only benefit vs. just getting scrap directly would be that you can't buy damaged parts so maybe you could use something that you couldn't afford new. If you can't sell scavenged parts for their full value, that's gonna be confusing if you're removing things from the vehicle to get scrap back. Not to mention complicating the code. I think this feature was a dumb idea from the start.

 

I like the concept of the idea, but it does seem like it would work better one way or the other, as it could get quite confusing with collected items vs purchased items.
Personally I like the freedom that the current system gives you, so I think you would need to somehow add the 'collect full parts' feature into what is currently there...and from your latest post it sounds like that could make things a bit too complicated!
Possibly this could work as a way to give players additional things to purchase that are not normally available? IE the NPC drops some cool bit of gear that isnt usually available, and picking it up gives you a 'token' that makes that item available for you to purchase (using the usual system).

 

Now there's a name I've not heard in a long, long time.​

 

Yeah, that's my idea basically. Maybe in a singleplayer game an AI drops a "super cannon" or whatever and you can now build it for the duration of that game. Or maybe you unlock a cosmetic thing that you can use everywhere now.

 

Super secret new content preview #7/10: "Procedural and hand-crafted"

This update is going to end up giving away a bit about the new game mode but that's OK, I'll explain everything at preview #10 and that's not too far off anyway.

So, in the new game mode I wanted levels that are a bit different every time. Each one short but always something new. The standard solution to that is to use procedural generation, and have the code create something that's different every time. But procedural can also mean bland, generating the same things with the same rules in different places, and for every game where it works well there's one where it doesn't.

I'm taking a sort of a hybrid approach here which with some luck will almost give you the best of both worlds. Here's a complete map for one "world":



That's big - it's over 7km long. But when a level generates it just takes a small chunk of that complete terrain, starting anywhere along it, and putting travel in a forward or reverse direction. I'm still tuning the exact length that'll be, but it's in the region of 1.5 or two kilometres.



Then within that area, things get more complicated.

Throughout the whole level the road is your guide.



Spawn on the road, leave on the road.

Within the level I can hand-place scenery, walls, turrets, enemy vehicles etc. A lot more stuff than the level will actually need. Then I tell the level generator OK, spawn some stuff in the level for a total of about x amount of scrap, and about 60% of it (or whatever) should be in stuff that attacks you, and the rest should be harmless (like crates). It then looks at all the groups of things and probabilities within the selected section of the map and decides what to spawn.

I've set it up so I can pack the entire contents of the level up so instead of having a bajillion things spawned in the world and then deleting most of them (which would waste a bunch of time and RAM), everything in the level is stored only as information about that thing, and then only what's selected is spawned. Everything can be unpacked (basically, spawn everything) so I can edit it, and then packed again for in-game use. In Unity engine terms it basically stores the prefab used, the position and rotation, and then any other custom information that particular thing needs to configure it.

But the key feature is that I've also set it up so I can create everything in groups with custom spawn probabilities. Here's an example of one group of things that could be selected to spawn:



This whole thing - the roadblocks, the turret, and the two crates - has a "normal" chance of spawning so it has about as much chance as anything else to be selected. If it's too close to something else that's already selected, or its scrap values don't work out with what the level needs, then it probably won't be chosen.

But within the group itself, it can choose different subsets of things to spawn as well. This subset will be chosen as soon as the level generator looks at it, so that it can know exactly what scrap value it'll have.



The roadblocks in the middle are set to always spawn the concrete barriers OR the wooden walls, but but never both. So it'll never actually look like the above in-game.

Neither the crates nor the turret are guaranteed to spawn at all, even if the group is chosen - you could get just the roadblocks. But somewhere between zero and all three will be chosen, with one of the crates in this case being a rarer spawn than the other. I could also set it to only spawn one thing out of three, or 1-3, or 0-2 or whatever. And the spawners can be nested so one of the choices could be another spawner with its own mix of guaranteed things and sub-choices.

But even as it is there are 16 possible combinations of just that one small set.

For AI vehicle spawns, I can now define patrol paths so they can patrol around, or just sit and wait.



Right now most of the code for level generation is done, as is most of the stuff to put in the levels, but I still have a lot of work to do in actually populating levels and in the actual framework of the new game mode. Sometimes it feels like things are progressing at a decent speed, sometimes it doesn't, but rest assured that I'm working on it.

See you next weekend.

 

Super secret new content preview #8/10: Desert landscape

For the new singleplayer game mode I need three maps to start off with.

You've seen the initial Gorge map:



Desert Map
Now I've started on a desert map. In my mind I have this basic idea of the four classical elements - Earth, Wind, Fire, Water - where the gorge map is Earth and is sort of the starting Green Hill Zone of the thing, and the desert is Fire. Artistically though I was inspired by the real Desert Road here in New Zealand:



Photo credit: Nicolas Leroy.

So not a sandy desert, but more of a tussocky one left barren by volcanic activity.



I'm still working on the look of this but here are a couple more shots:





Other Part-Time Work
I've got some other part-time work starting this week. I've been working on Scraps full-time for years now but it's never made the sort of money one could live off. That's fine, I'm making this game because I've wanted to play it since the 90s and not because I want to be rich, but I'm going to have some other work to do on the side.

Please don't let this worry you about Scraps ever being left unfinished. I've been wanting to play this game forever, it's taken longer than I hoped but it's really starting to look like the game I've always wanted, and unless I die suddenly I'll be working on it and it's getting made.

 

No special preview this week I'm afraid, but there is a game update.

I didn't intend to do an update right at this moment but I've finally, finally fixed a memory leak on the Scraps server that I've been trying to track down for months. I've been looking at it on and off in the evenings so that it didn't impact development on the game, but I've also really wanted to get it fixed. If you ran a game, even a single-player one, for a long time with lots of vehicles being spawned and destroyed, it'd eventually mess up and weird things would start to happen - like all damage would stop registering. It also meant that dedicated servers needed much closer supervision than they should have needed.

In the meantime while I've been working on the new game mode I've also been fixing other things, so there are some other bonus changes here as well.


Changelog
2016-6 - 0.5.4.4
- Added partial Polish translation
- Adjusted collision damage down a little
- Adjusted AI targeting a little. More shots at parts, less direct chassis shots
- AI aiming calculation now takes the shooter's velocity into account as well as the target's. Be afraid
- Made the in-game chassis colliders more detailed. Previously there was a box that could end up "protecting" some low components like small engines, with the chassis taking damage instead of the hit part
- Adjusted some sounds and volumes of various things
- Removed wreckage size scaling as it spawned since it looked dumb and was dumb
- Had to exclude screen resolutions that don't match your monitor's aspect ratio due to a bug in the Unity engine. On Linux resolution reporting is too fickle to limit: If a chosen res doesn't look right, just try another one
- Added visual indicator to health bars to help show when damage is done
- Wreckage pickup is far more performance-efficient. No more slowdown when complex vehicles drive over wreckage.
Bug Fixes:
- FINALLY tracked down a memory leak on the server that was causing trouble when running the game for a long time
- Fixed a couple of bugs with bullet spread. Machine-guns were more accurate than they looked visually (they match the visuals now)
- Projectile trail FX angle fix

2016-4 - 0.5.4.3
- Improved AI pathing quite a bit
- If AI gets stuck persuing in a circle, it'll eventually break out
- Updated the vehicle/environment shader look a little
Bug Fixes:
- ATI cards that didn't support DirectX 11 had some issues with the new terrain shader. Disabled some features if ATI+DX9 is detected to help the look


Info on the leak
The Scraps server was slowly using up more and more RAM, until eventually the whole thing would crash with a stack overflow exception. But the stack wasn't the problem - it was the heap.

I knew that it was the heap because looking at the Unity profiler, it appeared that all objects were being garbage collected just as they should be, but the thing that grew was Other->ManagedHeap.UsedSize. In other words things on the heap were getting allocated and not deallocated, so the heap had to keep growing when new things were made.

Unfortunately in Unity it's impossible to inspect the heap, although it is now possible on platforms that use IL2CPP. Being able to inspect the contents of the heap would have solved this much faster.

I fairly quickly worked out that creating and destroying vehicles was the problem, but the profiler reported that everything on the vehicles was successfully destroyed. Yet the leak implied something big was being held onto. There had to be a reference somewhere to something on a vehicle from something outside of the vehicle, that never got freed.

My eventual discovery after slowly hacking pieces of Scraps apart was that it was an event subscription to an event on a static class.

Scraps parts have a Health class that's a MonoBehaviour, and Health has a non-MonoBehaviour class that acts as a sub-component to do different things depending on whether this is a client or server machine (remember that this leak only happened on the server).

When the health script was created, the member class subscribed to a static tick event on a static clock class that the server has. When the health script was destroyed, it run its explosion effects and all that, and also told the member class to unsubscribe from its event... most of the time.

The problem was that the Health script's call to the member class wasn't in its OnDestroy, it was in another method that did all the destroying actions for the part and then called Destroy() itself - and that method didn't get called in every situation. Thus sometimes the event never got unsubscribed, and the reference to the member class was held by the static clock class forever, preventing it from being destroyed.

Much more was being retained on the heap than just that one class, so my theory is that Unity was managing to remove the vehicle's data on the C# side, but not in the C++ back-end. Thus the profiler would show that every object was destroyed successfully, but in fact the static clock class' reference held onto the non-MonoBehaviour class which in turn was holding onto the whole vehicle part with its memory-consuming mesh and textures.

To fix the issue for certain I basically just moved the cleanup code into the OnDestroy of the Health script, guaranteeing that if the script is destroyed, its member class gets cleaned up as well.

TL;DR: If your heap is growing forever and you aren't leaking any objects, one thing to look for is events that mightn't be being unsubscribed. And don't think that a GameObject being gone means it's necessarily really gone.

 

I've been working on the third and final terrain type I want for the initial release of the new singleplayer mode. To complement the existing Earth/Fire worlds, the next element is Water. Cold water.





Slippery ice.





Tune in next weekend and I'll properly explain what the new game mode actually is!

 

So I introduced the new Gauntlet game mode but it got lost in the Unity Forum update saga madness.

Check it out on the main Scraps site instead: http://www.scrapsgame.com/not-secret-new-content-preview-1010-gauntlet

 

Since I’m being slow with the next update post, here’s a sneak preview.

 

The first week after I made the Gauntlet announcement post was a bit of a mess and I didn't have a lot of time for Scraps work. It was getting near time for an update post and I was left wondering what I could make the next one about. What could I do in a couple of days or so? I didn't really want to do another small Gauntlet mode work post because that's all I've been doing for a while.

So my decision was, you know what, it's time to take a short break from the new game mode work and put something new in the game, for the players.

I looked through my figurative bag of potential parts to add and the Plasmanator came out.




Changelog for v0.5.5.0
- Added Plasmanator weapon
- Replaced uLink closed-source version with uLink source code
- Reduced network bandwidth use a little


Plasmanator facts

• Area effect weapon like super a Plasma Artillery.
• Charges up. Holding down the Fire button charges it, and releasing actually fires it.
• Drains lots of power while charging, and some power while sitting at full charge.
• White smoke and a change in audio indicate full charge.
• More charge = more damage and force on hit.
• Unlocks at 4700XP.

More charge also used to mean a faster bullet, which was nice conceptually but made it horrible to aim because you could never really get a feel for it unless you always waited for full charge. So the firing force is constant, but the hit force does increase with charge. There are bigger bullet and hit FX for the weapon for bigger charges.



I wasn't sure how a charged weapon should handle the "R" key aiming mode where weapons only fire if they're aiming inside the circle area. It's just not a great weapon to use in that mode really - and you can of course turn it off. Currently it works the same as any other weapon, which means that the firing state cannot be active for it when it aims outside the circle. Since it charges while "firing", it will charge while inside the circle if you're holding fire, but if it goes outside the circle while being charged it'll fire off a shot since the "firing" state is turning off.

I also wasn't sure how the AI should use it. Well, conceptually I was, but algorithmically... well, I wish I could just tell it to "behave like a human." I'd given Dave an assignment to look at it sometime but then I ended up doing it myself today. Basically I told the AI that if it's firing a charged weapon, it should release Fire momentarily to let off a shot IF:

• Its aiming is going off-target OR
• The weapon is fully charged OR
• Power levels are very low (which would suggest that it won't be able to charge any higher)

What I sometimes find is that in my code I'll go maybe a little overboard trying to find the perfect solution that covers every possible case, whereas Dave will code something super fast that's simple and yet more often than not turns out to work fine. Sometimes it'll need some tweaks and changes later, but usually the fact that it's simple at first means it's also easy to change. I feel like I might have managed a bit of a Dave-style solution here for once where I was worrying about how the AI was going to handle all these complex weapon scenarios, I ended up just adding a few simple rules, and actually it seems to do well enough to fool me that maybe the AI could even be somewhat intelligent.

Of course as always if you find any bugs with things, please report them.

This video was in my sneak preview update but here it is again. If you want to see something new with it, just load up the game - the Plasmanator is in the game right now!

P.S. Take note of where your shots hit. If you don't seem to be doing much damage, you may be hitting in front of the enemy instead of directly on them. The bullets drop fairly fast so aiming a little above the target is key.

 

This week I fixed some bugs with the Gauntlet mode level generation and I've been testing my level generation out.

I looked at two things that I noticed were an issue:

Issue: A need for cover in the early game
In Gauntlet you start with a small and cheap vehicle, and I found that you'd end up shooting a machine-gun turret with a machine-gun and it lacked much room for strategy. You can sneak up to some extent but often you crest a hill or something and you both have line-of-sight and you might as well shoot or get shot. I can beat the levels easily enough but I've been playing Scraps for years - you shouldn't have to take x amount of damage every time.

Solution: I'm just going to add some taller barriers around the place basically, so there'll be more opportunities to approach from a strategic angle.

Issue: Searching for that last crate
You want to shoot crates to collect scrap, and if crates might be out in the wilderness somewhere, you're going to want to scour the wilderness to make sure you find them all.

I knew that would be a bit of a chore, so I made most things spawn along the road that goes through every Gauntlet level. But it doesn't fix the problem because there's still some chance that things will spawn out in the middle of nowhere, so you end up going looking anyway. And removing that chance entirely would mean no reward ever for exploration, so I wouldn't do that.

RPGs have had this problem for a long time. The theory is of course that when there's somewhere out-of-the-way to explore, you get something cool to reward your exploration. And having something there is probably better than exploring and finding nothing. But it also means now you have to explore every boring side-passage because you might miss something cool.



Image credit: Possibly Adrian Chmielarz.

Solution: I've added a radar mini-map so you can automatically know there's something out there from a good distance. I don't think I'd add a radar in melee mode/multiplayer because having a radar map would remove a player's ability to surprise the enemy. But in singleplayer I think it'll be fine.



Enemy units are yellow crosses, non-threatening objects that contain scrap are blue squares. Trying to think of the colour-blind in these design choices.

 

Weekly update time. This week I've continued working on level content and generation. I added some more content to the Earth level, and added the remaining features to the level gen that I needed:

• Since Gauntlet levels can be played in forward or reverse direction, I added an option to include level content in one direction only (so I can do stuff like have walls that are always behind something no matter whether you're playing in "forward" or "reverse").
• Added an automatic rotation option to mirror the direction of things in reverse mode. So I can do stuff like have turrets automatically flip to face the other way.
• Added a specifier to have things not spawn until a certain level. Since each world (each map) will have 2-3 levels played within it, I can say something like "OK, don't have drones appear until level 2" and they won't spawn in World 1-1.

Hopefully that's now every feature it needs. I'll really try to stick to that because I know in gamedev it's all too easy to get stuck working on the "engine" forever and never actually make the game. I also think the level gen is all working correctly now (it's a pretty serious probability-processing machine at this point), it just needs some adjustments.

I added some giant arrows in the sky for myself in the Unity editor so I actually remember which way is the world's forward direction...



Unity devs, call this from your OnDrawGizmos to get dumb sky arrows like me:

Code (CSharp):

1. void DrawGizmoArrow(float xPos, float zPos) {
2.     Gizmos.color = Color.green;
3.     float arrowHeight = 300;
4.     Vector3 arrowStart = new Vector3(xPos, arrowHeight, zPos - 200);
5.     Vector3 arrowEnd = new Vector3(xPos, arrowHeight, zPos + 200);
6.     Gizmos.DrawLine(arrowStart, arrowEnd);
7.     Vector3 crossLineStart = new Vector3(xPos - 50, arrowHeight, zPos + 50);
8.     Vector3 crossLineEnd = new Vector3(xPos + 50, arrowHeight, zPos + 50);
9.     Gizmos.DrawLine(crossLineStart, crossLineEnd);
10.     Gizmos.DrawLine(crossLineStart, arrowEnd);
11.     Gizmos.DrawLine(crossLineEnd, arrowEnd);
12. }

Oh and I modelled some of those "taller barriers" that I mentioned were needed last time.



Gauntlet mode release TODO status:
Bold = currently working on.

• Finish up the level generation system - All features now in. Some adjustments still to do.
• Populate the three maps with lots more content for the level generator to choose from - Working on map 1.
• Finish up the desert and snow terrains
• Write the framework around the new mode – handling game start, game end, scoring etc
• Make some more vehicles for the AI to use
• Add leaderboards? Or initial release might just give you a local score, and add online leaderboards later

 

2016-8 - 0.5.6.0
- Reduced XP required to unlock some later parts a little. Final unlock is at 4000XP versus the previous 4700XP
- Added eight stationary turrets to the test map to facilitate testing armour etc
Bug Fixes:
- Fixed several null reference exceptions that could occur when vehicle parts were destroyed
- Players with laggy connections could still get incorrectly kicked for "cheating". Threw out that code for now: It won't kick you anymore but still needs some work later
- Various small fixes

 

Changelog
0.5.6.1
- Revamped the code that shows other player's vehicles in multiplayer. Their movement is now smoother, while not being any more delayed
- Much improved vehicle collisions between laggy players as well. No more flying across the map!
- Reduced some unnecessary network traffic
- Added option to have a radar in melee games
- Minor GUI adjustments
Bug Fixes:
- Hover effect no longer shows on Melee mode button while an overlay is up
- Fixed real-time shadows not matching up with baked shadows at low graphics settings on the Test Map
- Fixed a timing bug on joining multiplayer games that could get you disconnected with a vehicle build error



Radar in Melee games
I said in a previous post that I wouldn't add the radar I designed for Gauntlet mode into melee mode, because you should be able to hide from other players. But I figured it may as well be a custom option. Tick it at the lobby to enable it for everyone in the game (except AI - they still need line-of-sight to see you).




No more inadvertently flying across the map
This week I managed to fix an issue that's been plaguing Scraps multiplayer since it was first released, and that I actually I thought might be impossible to fix. Something that might not seem very important at the moment while Internet multiplayer is quiet, but still a relief to conquer.

Scraps has always had an issue where sometimes, if you collided with another player and the latency between you was high, you could end up flying across the map. Like at 1:43 in this video where I'm playing from New Zealand on a US-based server:

It was... "fun", sometimes, with quotes as necessary around "fun". It was definitely not how things should work, particularly since you could end up taking mega collision damage as well.

To set the scene:

• In Scraps, each client PC is in charge of the physics for their own vehicle.
• The server also runs its own physics, but for movement it's just checking what the client said (for most other things it's the authority).
• Other vehicles you see are sending you their positions - they're not running their own movement physics on your machine.
• Having said that, they still need collision boxes and momentum so that you can collide with them.

So each vehicle is doing their movement physics on their own machine, and getting sent the positions of everyone else. Since the "fly across the map" problem got worse as your latency got worse, I theorised that the problem was as follows:

1. You and an enemy vehicle collide.
2. Latency means that although your vehicle bounces back right away, they keep moving forward for a moment because both of you are seeing each other a little in the past, and you're only doing physics locally for yourself.
3. They therefore clip their vehicle's collision boxes into your vehicle further than they should, sending you flying across the map due to the physics engine's repulsion force that tries to keep things apart.

Basically their ghost invades your personal space and your vehicle tries to get away. And that would be potentially impossible to fix.

But it turned out that wasn't the problem!


The Real Problem part 1: How games show other players
Let's look at how a game shows other players' positions first.



The above applies to any real-time multiplayer game. You simply cannot know where other players are right now, because there's always some latency between your computers. There are two typical ways to handle this: Extrapolation and Interpolation.



With extrapolation, you say OK they were here half a second ago and going this fast in this direction, so they're probably here now. But extrapolation sucks: In Scraps and especially in FPS games where players can change direction even faster. If players always ran in a straight line at the same speed extrapolation would be great, but it's just a guess and often it turns out to be a bad one -meaning once the next real position update comes through, you'll see things rapidly correct themselves to a new position.

So usually interpolation is the way to go, in Scraps and in other games. You show the other player a little in the past (1s in the diagram above is a big exaggeration just for easy numbers. Quake 3 used 0.1s for instance), so that you can have real data on both their past and future positions, and then show a smooth movement between them. No more guessing. There can still be some issues like the "bouncing ball problem", but that's getting picky.

Fun fact: Scraps actually dynamically modifies the interpolation delay to compensate for the latency of each player, so I can keep things smooth while also having as little delay on other players as possible. Scraps can also extrapolate a little bit, but only if it has to.


The Real Problem part 2: The real problem
Anyway, that's all fine and good. But in your average FPS game the other players are just a set of colliders that have no actual velocity or momentum. I mean, they "move" around, but it's more like they teleport each frame to a new position. Whereas in Scraps if an enemy vehicle collides with you they should be able to knock your vehicle away - not just keeping you out of their collision boxes but really pushing you with force based on their current velocity. They need to be actual physics objects working with the physics engine, while also just being data fed in from other PCs.

Scraps uses a networking library called uLink, and along with uLink came an example script for just this sort of thing. They had an interesting system, and I used the same sort of system for Scraps. It worked like this:



It only looked at the most recent data coming in from the other player, and it set their vehicle up with a velocity that would get it to that point at the right time. Therefore you had a vehicle with real physics that nevertheless always moved exactly where it was told to.

But what I noticed last week, and what I should really have thought about in the past, was that unreliable data could cause big velocity variations (of course this is also a lesson in trusting other people's code...). For instance if you didn't get any data from the other player for a bit, their vehicle would keep moving wherever it had been going for a bit and then suddenly have to do a big correction, giving it a big velocity - whether or not it actually had a big velocity on the other player's PC (although really big corrections would just teleport instead, it wasn't that dumb).

I noticed that the velocity actually fluctuated all the time, and I wondered why I hadn't just tried doing what a normal FPS would do, but interpolating the velocity as well as the position, like so:



So I did that - and it works really well! Why didn't I try that in the first place? Velocity is now interpolated along with position, rotation etc. The vehicles have real physics but still go where they are told to go, and the flying-across-the-map problem ended up fixed as well. And there's no additional delay in where you see the enemy - the interpolation is set the same amount in the past as it was before. Turns out it must have been velocity fluctuations that were causing it, and what I thought was a problem with higher latency was actually a problem with less reliable connections.

You will still see a delay on high-latency connections in the other player getting pushed back in a collision. You hit them, you bounce back, they seem to stay still for a moment, then they bounce back too. That's just because you're only doing physics for yourself, so you're waiting for the new collision to get sent out and then some back to you. The good thing is, everyone gets pushed back the right amount!

The bad thing is... no more exciting unplanned flights into orbit?

 

This week I've been mostly placing content in Gauntlet mode levels. I did make an SMG drone as a less deadly version of the the existing MMG drone:



I also made a little Unity editor prefab placer script which I'll share.



It lets you spawn arbitrary prefabs with the buttons, and it automatically raycasts to the ground and places things there. You can show a visual indicator for placing invisible prefabs, and there's an option to give things a random starting rotation. You could also rotate the selected object with the keyboard like in the gif above, but for some reason it often ran at like 1fps and was horrible to use, so I've removed that feature.

The code isn't anything special because it's just meant for my personal use in the editor, but I'll share it here as I think it could be useful to other unity devs. If you're using it, read the code comments as there are some changeable things within, but it should work as-is as long as you replace the paths in LoadPrefabList with your own:

Code (CSharp):

1.  
2. using UnityEngine;
3. using System.Collections.Generic;
4. using System.Linq;
5. using UnityEditor;
6.  
7. // GUI editor interface for easily placing a set of hard-coded prefabs on a map
8. public class SimpleThingPlacer : EditorWindow {
9.     // Set in inspector. Have this enabled to give prefabs a random starting rotation
10.     [SerializeField]
11.     bool randomYRotation = true;
12.  
13.     // Got prefabs that don't have a visual model? Put their GameObject names here to see a visual indicator when holding them
14.     readonly string[] prefabsThatNeedVisualIcons = {"VehicleSpawner"};
15.  
16.     // Your prefabs can be assigned to categories you define here, and will show up in these groups in the editor window
17.     enum Categories { NonEnemy, Enemy, Group }
18.  
19.     Dictionary prefabs;
20.     GameObject curHeldPrefab;
21.  
22.     // #### UNITY INTERNAL METHODS ####
23.  
24.     protected void OnGUI() {
25.         if (Application.isPlaying) return;
26.         if (prefabs.IsNullOrEmpty()) LoadPrefabList();
27.  
28.         EditorGUILayout.BeginVertical("Box");
29.         randomYRotation = EditorGUILayout.Toggle("Random Y rotation: ", randomYRotation);
30.         EditorGUILayout.EndVertical();
31.  
32.         // This is pretty basic - could be modified to auto-set NUM_PER_ROW based on window width
33.         const int NUM_PER_ROW = 3;
34.         const int ENTRY_HEIGHT = 64;
35.         const int ENTRY_WIDTH = 80;
36.         foreach (KeyValuePair category in prefabs) {
37.             bool isInRow = false;
38.             EditorGUILayout.BeginVertical("Box");
39.             EditorGUILayout.LabelField(category.Key.ToString(), EditorStyles.boldLabel);
40.             List p = category.Value;
41.             for (int i = 0; i ();
42.  
43.         // Replace these with the paths to the assets you want to show up
44.         // Or these hard-coded paths could be replaced by automatically loading all assets in a folder etc
45.         // Or maybe create an interface in the editor window itself to add/remove prefabs
46.         AddPrefab(prefabs, Categories.NonEnemy,  "Assets/Prefabs/Environment/SinglePlayerPhysicsDamageable/Walls/WoodenWall.prefab");
47.         AddPrefab(prefabs, Categories.NonEnemy, "Assets/Prefabs/Environment/SinglePlayerPhysicsDamageable/Walls/ConcreteBarrier.prefab");
48.         AddPrefab(prefabs, Categories.Enemy, "Assets/Prefabs/EnemyNonVehicles/Drones/MMGDrone.prefab");
49.         AddPrefab(prefabs, Categories.Enemy, "Assets/Prefabs/EnemyNonVehicles/Drones/SMGDrone.prefab");
50.         AddPrefab(prefabs, Categories.Group, "Assets/Prefabs/GauntletSets/GauntletEarthRoadblock1.prefab");
51.     }
52.  
53.     // Path should start with the Assets forlder, e.g. "Assets/Textures/texture.jpg"
54.     void AddPrefab(Dictionary prefabDict, Categories category, string path) {
55.         GameObject prefab = AssetDatabase.LoadAssetAtPath(path, typeof(GameObject)) as GameObject;
56.         if (prefab != null) {
57.             ISpawnedThing ist = prefab.GetComponent(typeof(ISpawnedThing)) as ISpawnedThing;
58.             if (ist != null) {
59.                 if (!prefabDict.ContainsKey(category)) prefabDict[category] = new List(1);
60.                 prefabDict[category].Add(prefab);
61.             }
62.         }
63.         else {
64.             Debug.LogWarning("Couldn't find prefab at: " + path);
65.         }
66.     }
67.  
68.     void CreatePrefab(GameObject prefab) {
69.         curHeldPrefab = (GameObject)Instantiate(prefab);
70.         // Remove any automatic "(clone)" designation
71.         curHeldPrefab.name = prefab.name;
72.         if (randomYRotation) {
73.             Vector3 eulerRot = curHeldPrefab.transform.eulerAngles;
74.             eulerRot.y = Random.Range(0, 359);
75.             curHeldPrefab.transform.eulerAngles = eulerRot;
76.         }
77.         Selection.activeGameObject = curHeldPrefab;
78.     }
79.  
80.     void ReleaseHeldPrefab() {
81.         curHeldPrefab = null;
82.     }
83.  
84.     // Returns true if the input transform or any of its parents, grandparents etc have the specified tag.
85.     static bool HasTransformInAncestors(Transform trans, Transform match) {
86.         if (trans == match) return true;
87.  
88.         trans = trans.parent;
89.         while (trans != null) {
90.             if (trans == match) return true;
91.             trans = trans.parent;
92.         }
93.         return false;
94.     }
95. }
96.  

 

You guys will know that Unity's terrain system has a special system for trees, separate from the one for placing glass and other detail stuff. Your trees must use two specific built-in shaders. Your trees must reside in a folder with the text "Ambient-Occlusion" in the name. They may have colliders, but other components on them will be ignored.

I tried the tree system out, I haven't used it before. It's got some nice features - for instance it'll automatically turn your trees into billboards at long distances to save rendering work (much like Jurassic Park: Tresspasser did way back in 1998). Although even that has its quirk - the billboards have a slightly different perspective to the meshes so they do some weird bending as they switch over.

I had it all working actually quite well, but the killer was the lack of support for custom components. The trees would have to be permanent; immovable. Scraps with indestructible trees? It wouldn't do.



Look at that realistic tree-smashing action (pls don't destroy trees IRL).

So anyway I added some trees.



(not to SandyBridge - I was just testing them there)

They're not using the special tree system. They're just meshes with a couple of LODs. LODs being levels of detail - showing the lower LOD at far distances. Works fine.

The trees I have actually came with two LODs already, but I wasn't exactly impressed. Does this look like a seamless transition to you?



The branches are fine. The leaves not so much. So I made my own low LOD versions that aren't particularly great either but everything looks OK.



I'm still adding level content. Each "world" in Gauntlet mode is big - but at least it does get reused for three levels. My new job is taking up a lot of time as I knew it would, but I'm still managing to get a little Scraps work done. See you next time.

 

Thank you for your extreme patience as I continue to bumble along with this game in what spare time I have. Last update, I suggested that I'd get Gauntlet mode's World 1 finished, and then work on the framework for Gauntlet mode iteself. In the end I decided to get the first two worlds done first, since both will be needed for a playable release of Gauntlet anyway. I've now got the content for the first two worlds complete.

The Gauntlet mode worlds will be loosely themed on the classical Greek elements: Earth, Water, Wind, Fire. Earth and Water now have all their content, and if I give them three levels each, that'll be enough for an initial release of the new game mode that you can try out. As in an actual game update, not just more progress news like this. What I still need to do first is write the framework around the new mode: How you enter levels, progress through them, repair between levels etc. It's stuff that's mostly in the game already but it needs to be strung together correctly and have some new concepts added. At the moment to test Gauntlet mode, I use dev tools to select a vehicle and drop into a level manually. I'm afraid I don't have a release time estimate because the amount of time I have for Scraps currently varies a lot week by week. It'll get done.

I've also been making a few other changes to the game as I go, that'll make it in when Gauntlet launches. One I can show off is a new primary firing mode:

It's something that was brought up in the forums a while ago. People were carefully building vehicles that didn't have quite enough power supply for their weapons, so the weapons would end up dropping down into a sequential firing mode instead of all firing at once - meaning less recoil, and more spread out power and heat. Now that mode can be automatic, but the old mode is still there as well. There isn't really any additional complexity to worry about for the player - left-mouse will be the new mode, or right-mouse will fire using the all-at-once mode that's in the game now.


Some new screens of the Gauntlet worlds I've been making
EARTH is sort of the Green Hill zone of the thing. It's grassy hills and rocks and trees, and combat is against lewer-level enemies: Basic machine gun turrets, mostly micro vehicles, hover drones.



WATER is snow and ice. AI vehicles are more expensive and more frequent, turrets are more powerful, and drones are less common. But your vehicle will be more powerful too.

 

I'm going to try and post news about what I'm working on a bit more often again. Here's my list of what I need to do for an initial Gauntlet mode release:


Gauntlet tasks to do before initial release
- Get local games fully working - DONE
- Object for holding game state in Gauntlet mode
- Auto-repair system + vehicle swap ability
- Gauntlet game flow from menu to end
- Score system
- Level generation tweaks
- Update scrap drop system
- Item unlock system
- Update How To Play screens
- Test and balance gameplay
- Music?

Looks a bit long and scary, and yes it is rather a lot, but not all of those things are major. I thought the first one was pretty major and I've already got it done. What I'm going to do is, each time I complete one of those, I'll make a post and talk about that line item in more detail. When they're all done there'll be a real game update.

Let's talk about "Get local games fully working".

Local Singleplayer
I'd like to start with Minecraft as an example here. When Notch originally made Minecraft, the singleplayer and multiplayer components of the survival mode were separate. Bugs would often appear in one but not the other - usually multiplayer because networking is hard, man. A lot of work had to be done twice, in the singleplayer game and also in the multiplayer one. I read an interview somewhere where Notch mentioned that one thing he'd have liked to have done differently was going fully multiplayer from the start, and having the singleplayer just run on a local server. Eventually that's exactly what happened: The game was changed to be always multiplayer behind the scenes, and that's why anyone can easily join your singleplayer game on LAN now if you choose to open it up.

When I built Scraps I decided that likewise, having one networked system that everything used was the way to do. In the interests of simplicity, the Melee game mode always runs a separate server. That's why it was easy to add the "Allow other players to join" option to singleplayer games. Whether you host a multiplayer game or whether you start a singleplayer game, a local server starts up and you silently connect to it.

I don't think I made a mistake in doing it that way because it works well, but there is an effect on CPU performance because some calculations have to be done twice (the graphics card gets away free here because I run the server with no graphics). For Gauntlet mode I want to have good performance on moderate PCs even on later levels with big vehicles, and getting rid of the need for the server is an obvious win there. Plus I'd done a lot of the work already as I'd needed it in the past for testing. The changes basically entailed writing new paths for things when there was no network present, so what usually had to wait for server confirmation etc would do its own thing.

Now, converting a singleplayer game to multiplayer is always a big job, sometimes such a major change it's just about impossible. But converting a multiplayer game to singleplayer has been a lot easier! Not least because things always get simpler rather than more complex. This class structure in Scraps:



becomes this:



I've actually still got a couple of minor issues to fix but it's basically all working. As a bonus, when the Gauntlet update comes out you'll also be able to play the Melee game type in a true local mode - I've got that working as well - if you have "Allow other players" unticked:



That should give a bit of a performance boost for people with low-spec CPUs (to be clear, you won't see this performance boost now, it'll come with the Gauntlet update).

 

You have amazing patience to work on this for five years. I gather it was part-time? I tried it on Windows 8.1 and it works smoothly.

 

I worked on it full time for a long time. It's taken a lot longer than I originally hoped (doesn't every game?...) so I eventually had to get some other work.

 

The "Object for holding game state in Gauntlet mode" list entry is done, but the news post I did for it has a lot of pretty basic technical stuff that actual game devs on these forums probably already know. I'll just link it from here for those interested rather than including it all: http://www.scrapsgame.com/gauntlet-game-state-object-technical-rambling

 

Awesome project! Great job man!

 

Thanks.

 

Gauntlet tasks to do before initial release
– Get local games fully working - DONE
– Object for holding game state in Gauntlet mode - DONE
– Auto-repair system + vehicle swap ability - DONE
– Gauntlet game flow from menu to end
– Score system
– Level generation tweaks
– Update scrap drop system
– Item unlock system
– Update How To Play screens
– Test and balance gameplay
– Music?


Free repairs
At the end of each Gauntlet level I'm giving the player some amount of free repair and rebuild time.



This is measured in "minutes" because I don't want people to think it's using up some of their scrap, but there's a straight conversion between "minutes" and "scrap". For instance one minute might give 50 scrap worth of repairs. The implementation of all of this could change, but at the moment I'm giving the player some amount of free repairs (which can include rebuilding lost parts) at the end of each Gauntlet level, and each level gives a bit more time than the last (covering the fact that that player's vehicle is probably getting bigger).



The free repairs are currently automatic, but they'll try to be not too dumb, and always repair cockpit and chassis first.


Why
The thing is, Gauntlet mode will be a series of levels where you keep the same vehicle, so if I don't provide any free repair time then there'll be a huge spread in potential vehicle value once the player has completed a few levels, which becomes hard to manage.

Say I want to have the player be able to, on average, increase their vehicle value by 3000 at the end of a certain level, and I also decide that I'd like to let them recover from about 50% damage. I calculate what I think their vehicle will be worth at that point following the formula - say it comes out that their vehicle might be worth 4000 scrap. 50% damage = 2000... So I'd put 5000 scrap in the level to cover 2000 repair/rebuild + 3000 upgrade. But of course they might take more or less damage than that, and compounded across several levels you have potentially HUGE ranges in vehicle value. Someone who takes no damage can increase their vehicle's value by 5000. Eventually, just by dropping enough scrap for an "average" player to repair 50% damage, the player who cleverly takes no damage could have a vehicle worth even more than I really want to allow for performance reasons. Or just totally streamroll through levels that are balanced for lesser vehicles.

The more free repairs I give, the more levelled the playing field becomes. With unlimited free repairs, all scrap collected could go to vehicle upgrades. I'm still experimenting with how much free repair time I actually provide. I don't want everything to be totally balanced and boring either.


How
That big repair/rebuild button that you see on the Build screen in Melee mode, I've actually updated that (in my dev version, not live) to use a GUI more like the above screenshot except with scrap showing instead of minutes. Then the end-of-level repairs are actually a special case of the same system. Internally instead of repairing using the player's banked scrap, a special temporary wallet is created with some scrap in it, and that's used to do the repairs. So the code path is exactly the same except the "money" for it comes from a different place. Keeps things simple vs. having two different systems to maintain.


Vehicle Swap
This just means you can swap your vehicle out somehow, so if you start with e.g. a Small chassis you can upgrade to a Medium or Large. I won't say much about this now because how I handle it might change.

Game Flow
The next task on the list is the flow between levels. I've already been working on that as well, with a major issue being level loading times. Loadnig a Gauntlet map was taking about 15 seconds on my relatively decent PC, but I've now got it down to around 5½ seconds. I'll talk about that next time.

***

I know there's been a bit of a gap between the last update and this one. I've actually been fixing a few other issues around the game as well. Nothing really worth talking about, although if you've ever done a repair/rebuild on a vehicle and had it error out saying a part can't be attached, I discovered that issue too and it'll be fixed when Gauntlet releases.

 

Gauntlet tasks to do before initial release
– Get local games fully working - DONE
– Object for holding game state in Gauntlet mode - DONE
– Auto-repair system + vehicle swap ability - DONE
– Gauntlet game flow from menu to end - DONE
– Score system
– Level generation tweaks
– Update scrap drop system
– Item unlock system
– Update How To Play screens
– Test and balance gameplay
– Music?

Gauntlet game mode flow
Most game development starts with the developer testing things by dropping directly into a level. No menus, no options, no worries about setup or unloading things on quit. But eventualy you've gotta make it playable for the masses.

I've posted enough boring flow charts already recently but in Gauntlet the player goes from the main menu, selecting Gauntlet mode, to a vehicle select (or build) screen, to Gauntlet World 1-1. Then they either die, taking them to an end game score screen, or they make it to the evac point, getting them some free repair time, and then time to spend the scrap they've collected. Then they drop into Gauntlet World 1-2. And so on.

I'm not happy with the look of my end-of-Gauntlet score screen (it's so boring) but it's got what it needs in it:



The scores are fake for now - that's the next task on the list. High scores are likely to be local only for the initial release of Gauntlet mode but barring any serious issues I intend to add worldwide leaderboards later.


Loading time saga
Soon after I started to code in the actual flow through a game of Gauntlet, I came across a loading time issue.

Gauntlet maps give the player a random chunk of a much bigger map to play through, with semi-random content spawned on it. I knew that loading the map with all the possible content and then deleting what I didn't need would be terrible for loading times, so I'd already written a system for packing the map's content into data and only spawning in what was wanted. I hoped that would be enough.

It wasn't. The map's terrain and extra static content still had to load in and loading times into a Gauntlet level were around 15 seconds. So I went on a bit of a mission to reduce it.

• Removed level walls that were only there for editor use. Now it was 12 seconds.
  
• Reduced detail on the walls that are generated when the level starts. Now 8 seconds.
  
• Wrote a packer to pack all the remaining terrains and static content in the level and only spawn in what's needed. Now 5 seconds.

That's Good Enough.


Extras
I also did a couple of extra things that'll make it into the inevitable Gauntlet release eventually. These took way less time than the game flow code but look a lot more interesting in a blog post.

Actual light cast by weapon muzzle flashes. Shown here in an artifically dark scene to make them more obvious:



Extra FX on plasma weapons. The side-ejected plasma FX were already there but plasma weapons didn't have a muzzle flash which was kind of weird. Now a burst of plasma residue comes out the front as well, along with the actual projectile:

 

Gauntlet tasks to do before initial release
– Get local games fully working - DONE
– Object for holding game state in Gauntlet mode - DONE
– Auto-repair system + vehicle swap ability - DONE
– Gauntlet game flow from menu to end - DONE
– Score system - DONE
– Level generation tweaks
– Update scrap drop system
– Item unlock system
– Update How To Play screens
– Test and balance gameplay
– Music?


Score
The trick to not making a terrible score system in a game is to make sure it rewards a type of gameplay that's actually fun. If it rewards playing the game in the way you actually intended, well that's a nice bonus.

In Gauntlet I've set the score to be based on total enemy scrap destroyed - get points for destroying stuff that shoots back, get more points for harder stuff. Then an added bonus for time to complete the level. I think I'm going to add a base score for just clearing a level as well.

Check this GUI out, it even has actual transition FX:


(ignore the time there - levels won't take 16 minutes...)

• If there was no time bonus, score for each level would end up much the same as long as you cleared every enemy, no matter how good you were.
  
• If there was no enemy scrap bonus, players could try to get a high score just be avoiding all enemies and going directly to the exit.

Although, I do like allowing different strategies which is why I might add a base level clear bonus as well. If the player avoids enemies they won't be able to collect scrap from them, which will leave them with a weaker vehicle, so there's still a balance in challenge there.


Turret revamp



The first Gauntlet level is mostly turrets because they're the easy enemy to fight, and it kind of sucked because you can't do much but sit and shoot at a stationary turret. I've tweaked their stats so they won't take so long to kill but that's still a bit boring, so I've also revamped them to have separate top components. All the gun parts will be separate components that can be shot off, meaning if your aim is good you can take out a turret more efficiently. Once the top is destroyed, the base automatically loses most of its health as well so it's not a chore to dispatch the remaining disabled foundation. Heatsinks/generators on the back are separate components as well and the guns overheat or fire less often when they're destroyed.

 

Gauntlet tasks to do before initial release
– Get local games fully working - DONE
– Object for holding game state in Gauntlet mode- DONE
– Auto-repair system + vehicle swap ability- DONE
– Gauntlet game flow from menu to end- DONE
– Score system- DONE
– Level generation tweaks- DONE
– Update scrap drop system
– Item unlock system
– Update How To Play screens
– Test and balance gameplay
– Music?


Level generation tweaks

Honestly not much to say about this one as I've already talked a fair bit about the level gen in Gauntlet mode in a few older posts. The work I've been doing on level gen recently is mostly code modifications that aren't very interesting to blog about - Just trying to generate nice levels and balance the game mode.


Zoomed in view

So I'm going to talk about something that's a bit more suited to a blog post.

Ever since Operation Flashpoint or even MDK to some extent, first-person shooters have tended to have an "aim down sights" mode where your view often zooms in a bit, it brings up your gun as if you're aiming down the sights, and you generally get some increased accuracy.

I'm not doing that, because the last thing I want is for close-combat vehicle fights to be full of confusing zoomed views of the action just to get slightly less bullet spread. And it'd make no sense to aim a gun first-person style in a third person game. But in Gauntlet mode there are some large areas and I noticed that I sometimes had trouble lining up the shot I wanted, so I'm putting in a minor zoom function, currently by default on the middle mouse button (not released, this is in my dev version only). It has no effect on accuracy and it can be safely ignored, but IMO it's kind of nice.

The simplest way to do a "scope" in an FPS type game is to simply decrease the camera's Field Of View. That method works perfectly if your aiming reticle is in the exact centre of the screen. But Scraps has an off-centre reticle - in fact it can be moved by the player as well.

This is what happens when you zoom with a non-centered reticle (click to view - the Unity forums don't seem to like displaying my GIF directly).

At the start of that for instance, I'm aiming at the bottom of the wall. When zoomed, my mouse hasn't moved but now I'm aiming at the ground. Not good.

Surprisingly few people seem to have this problem to solve; I think most games must have the reticle in the exact centre. However I found some genius had already solved it here. Like the best answers, he's answered his own question.

With that formula implemented, things look way better (click to view again).

Although notably not quite perfect. As far as I can tell I think any remaining error comes from the changes in the perspective of the scene, since the camera has to rotate to keep the reticle pointing at the same place, and that means things that are close shift visually a different amount to things that are far away.

Probably the only way to completely solve it would be to do something like raycast to the thing the reticle is currently pointing at, then tell the zoomed camera to look at that particular point. Or of course just put the reticle in the dead centre like a normal game! But honestly, the current solution is close enough, especially for a feature that doesn't really affect the game.

 

Gauntlet tasks to do before initial release
– Get local games fully working - DONE
– Object for holding game state in Gauntlet mode - DONE
– Auto-repair system + vehicle swap ability - DONE
– Gauntlet game flow from menu to end - DONE
– Score system - DONE
– Level generation tweaks - DONE
– Update scrap drop system - DONE
– Item unlock system
– Update How To Play screens
– Test and balance gameplay
– Music?

Long gap between updates, the end of the year was a busy time. Having said that I actually forgot that I'd put "Update scrap drop system" on the Gauntlet TODO list as a separate line item and I finished that a while ago. I'm working on "Item unlock system" now, plus some other bits that weren't big enough to get on the list.


Updating the wreckage drop calculations
The reason I needed to update this is that the amount of scrap you'd get to collect from destroying a vehicle in total could vary a lot depending on how it was destroyed. This was OK in the old Melee mode but kinda lame in Gauntlet, where I'd prefer to have a decent idea of how much scrap I'm going to be supplying per level.

The main issue was the reliant part system. In the current Steam version (and older versions), the rules work like this:

1. Look at the part that was destroyed. Are there any parts connected to the chassis ONLY through that part?
   
2. If so, add them to the list of destroyed parts (so you don't get parts floating in space).
   
3. Sort the destroyed parts from most to least valuable.
   
4. Pay out 100% of the scrap value of the most expensive part, then 77.5% value for the next, then (77.5^2)% and so on.
   
5. If the value multiplier gets below 10%, stop paying out.

For example say I built this thing:



And the outer 1x2 block got destroyed:



Then the wreckage would pay out in value like this:



I did it that way originally because it felt more fair, since it takes less effort to shoot off one part that takes out a whole lot, then it would to destroy them all individually. I also tried to be fair by paying out the more expensive parts at the highest percentages.

But maybe it's nice to reward skill for the shooter's aim and punish bad vehicle design too. Either way this wouldn't work so well in Gauntlet because it means vehicle scrap payouts can vary hugely depending on how the parts of a vehicle are destroyed, even when the vehicle design itself doesn't change.

So I changed it to just give an X% change to pay out 100% of the wreckage value for each part destroyed. So the payout is either 0% or 100% for each part.



And actually it feels fine, even in melee mode. If payouts end up too high or low, the percent chance can be tweaked. If it really doesn't work after I release it like this, I can roll back melee mode to the old version and keep the new one for Gauntlet. It ends up giving bigger payouts for destroying the final cockpit or chassis on a vehicle and less for destroying individual parts. Obviously this still results in variation in payouts since there's still randomness involved, but it's a sort of randomness now that averages out over time, which works better for Gauntlet mode.

 

It is really annoying hear from other devs: "hey, this looks like Robocraft".
I have personally recently worked for a period at Freejam, so I know very well the Robocraft game, of course.

Is like if you go to tell head dev of eg: CallOfDuty: "hey, do you know, your game really reminds me BattleField".
If I could understand the thousands FPS copy clone have this kind of issue, but here ?
There is just a vague similitude between the two.
So, here I want to share my appreciation to the effort of this indie developer because Scraps looks promising indeed! This game seem much more based on realistic Physics than robocraft. Robocraft looks more funny to drive, than vehicles in your game, if you get what I mean.
There is no other similitude, I don't see any mech warrior, choppers, flyers, or hover in this game, so...

I feel to share a tip:
Making a game is always a compromise of realism and "fakeism", just like in the movies.
If you want it fun, you should forget about 100% realism. Leave that for the movies CG.
A Game must be FUNNY, first of all. Then comes the rest.
I like your idea, you should just work probably /like you are doing already/ a bit the gameplay out.

Well done!

 

Scraps and Robocraft first appeared at similar times anyway - close enough that there's no way either one copied the other. I first started posting about Scraps a few months before the first Robocraft post but there's no way they could've copied my game in that time, and I doubt they were trawling forums for obscure indie titles.

Pretty awesome that you worked at Freejam. I'm impressed with the performance they seem to maintain with super complex vehicles. Wish I knew how they calculated their simplified hitboxes and then still detected hits on individual parts. My guess is once a projectile intersects the bounding hitbox, it's manually checked inside the bounds to see exactly which part was hit with something like bounds.IntersectRay, transformed in local space to get around the fact that bounds are unrotated. That's what I'd try anyway, and I need to do something like that myself.

And yeah, I've toned down the weapons throwing vehicles around so much over time as the "physics game" aspect seemed cool but it wasn't fun to play if your vehicle just got thrown over and you couldn't do anything. Really the biggest influence on Scraps has always been Interstate '76, which was far from realistic, and lots of fun to play.

 

Yea, Mad Max and Interceptor were great movies with superb ambience indeed!
Unfortunately I can't reveal any of the tricks and "escamotage" Freejam took to optimize their game.
But is not just about the game design or code optimization, is also about ECS.Svelto they used to code the whole game over 4 years now.
I have heard an ECS from Unity Technology is on the way, and this is definitively good news, but when the aim of a game is big and you have millions user registered, working as an indie would pretty soon put you in a situation you could hardly manage without a structured company and a very well structured base code, easy to maintain and to extend.

 

Nah, Interstate '76. Vehicle combat game from 1997. Insane amount of style, vehicle upgrades, other good stuff:

And yeah, I didn't expect any actual insider info of course. I've heard about that new Unity ECS in the works as well. Will be interesting. Sounds like it may be coming this year.

 

Don't tell me Interstate 76 doesn't get its ambience from Interceptor

 

The Pursuit Special, last of the V8 Interceptors...

 

Gauntlet tasks to do before initial release
– Get local games fully working - DONE
– Object for holding game state in Gauntlet mode - DONE
– Auto-repair system + vehicle swap ability - DONE
– Gauntlet game flow from menu to end - DONE
– Score system - DONE
– Level generation tweaks - DONE
– Update scrap drop system - DONE
– Item unlock system - DONE
– Update How To Play screens
– Test and balance gameplay
– Music?


Item unlock system

One interesting thing about Scraps is that most of what I've done on it is in the game. That might sound almost like a tautology, yet it doesn't seen uncommon for a lot of games to have something like 50% of their feature work not actually make it in to the final game - whether it's tossed out due to not being fun, from a change of vision, or just from being a bigger job than expected. Whether Scraps keeps more of its features because I had a clearer plan from the start, or because I sometimes keep features I should have ditched, you can decide! But man, it takes long enough to make a game alone without scrapping features as well.

Anyway, I say that because I sort of ditched a feature. I had a general plan that you'd occasionally get part pickups in Gauntlet, similar to the existing wreckage pickups. I started a basic implementation of it - here are some early test part drops:



So you'd start Gauntlet with only a subset of all parts available to you to build with. You'd pick up parts along the way that'd unlock that part for use on your vehicle. Some parts would be per-game only, and some would unlock permanently to use like how XP works now. The per-game ones could include some special/quirky parts that were fun but maybe a bit overpowered or unbalanced for Melee mode.

That sounded neat but in reality there just aren't enough total parts and there'd have to be a lot more for it to really make sense and not cripple the parts you start with. Additionally, I could have added the whole new system for dropping and pickup up parts (e.g. one part drops per Gauntlet level)... or I could just give out part unlocks at the end of Gauntlet levels using the existing unlock system, and it'd basically give exactly the same result.

So I ended up doing a thing where completing Gauntlet levels sequentially unlocks parts (permanently), as an alternative way of getting parts vs. the existing XP system on its own. I may end up basing it on score in Gauntlet mode instead of levels completed, but that'd be much the same thing. And any parts you've unlocked before can be used right away, which stops Gauntlet starting vehicles being too limited.


Cosmetic rewards

I also made these crown/trophy things that completing Gauntlet stuff can unlock.



And yes, they can go on your vehicle. They don't really do anything and they're a bit silly really but look how shiny they are.



They do have a bit of HP, so naturally they cost a little bit of scrap to add to a vehicle, but only about the equivalent of buying armour with the same HP. They're meant to be a free bonus that you can show off.

- Completing Gauntlet mode when I've initially released it but it's not finished yet (missing Worlds etc) will unlock the "Alpha" Crown.
- Completing Gauntlet mode when it's finished will unlock the standard "Gauntlet" Crown with the wreckage cube.
- Doing something special (maybe looping through Gauntlet twice?) will unlock the Master Trophy (far right).

 

Gauntlet tasks to do before initial release
– Get local games fully working - DONE
– Object for holding game state in Gauntlet mode - DONE
– Auto-repair system + vehicle swap ability - DONE
– Gauntlet game flow from menu to end - DONE
– Score system - DONE
– Level generation tweaks - DONE
– Update scrap drop system - DONE
– Item unlock system - DONE
– Update How To Play screens - DONE
– Test and balance gameplay
– Music?


Updated How To Play screens
The Scraps How To Play screens have always been a bit minimal. I wanted to update them to work with the upcoming Gauntlet mode, but also add a bit of a side menu so it wasn't just a slideshow and the reader could skip around.

Once I did that, the change in screen aspect ratio meant the old image-based screens wouldn't work well anymore. They were always a hassle as well because the text was baked in, so for language translations each image had to be swapped out with one in a different language. Then if the text changed, they all had to be updated.

So I ended up basically re-doing the whole thing, with a bit of painstaking copying across existing language translation text where possible because people have done hard work (for free!) on those.

I tried a few different styles and colours. Here are a couple of colour schemes:





I think the darker one above looks best. The items on the left can be clicked to skip to different sections, and arrow keys work as well.

The screens also scale automatically to some extent to different screen resolutions and aspect ratios, right down to 800x600.



* * * *

The next task on the list is a big one, because it's basically get everything in the first two Gauntlet worlds fully working and working well. A large part of that is just going to be testing and adjusting the gameplay. I really should add some analytics as well that'll let me know how far people playing are actually getting once it's out. It'd be anonymous data that you could opt out of, of course.

Will be working on it whenever I can.

 

The latest release of MacOS has removed support for 32-bit applications. This broke Scraps on Mac as it was previously 32-bit. On Friday I updated the Steam version of Scraps to be 64-bit on Mac, and it should now be fully working again.

Meanwhile a preview release of Gauntlet mode is getting close as well. When I went to balance everything, I ended up adding a couple of extra maps and some other changes to get everything working nicely, which has taken a while. Here are a couple of quick preview screenshots from previously-unseen worlds:

 

Finally got the first few worlds of Gauntlet mode ready to play and live on Steam for everyone. Merry Christmas.

0.6.0.0
- Added the first four worlds of the in-progress GAUNTLET game mode
- Completing the current in-dev version of Gauntlet bestows a little crown you can put on your vehicle
- Singleplayer games (Gauntlet, and Melee with "Allow other players to join" off) are now truly local without a separate server process, improving CPU performance and start time
- Updated firing modes. Primary mode now fires weapons in a staggered fashion. Secondary fire (mouse 2 by default) fires together
- Middle mouse button now zooms view (visual effect only - doesn't affect accuracy)
- AI players may appear using a new Micro chassis and/or a CPU brain instead of a cockpit in Gauntlet mode
- Rewrote the vehicle sound manager. No more sounds dropping out, smoother sound balance overall with any number of simultaneous weapons firing etc. Less sound sources playing at once
- Fixed a bug where sounds could get cut off suddenly when they shouldn't
- Revamped how parts calculate scrap to drop. You can now expect roughly the same amount of scrap no matter how a vehicle is destroyed (previously, destroying a part with other parts connected dropped less scrap than destroying each part individually)
- Weapon tracers are more visible with thicker lines up close
- Made wreckage stand out a little more against the background
- Significantly improved interpolation on other player's vehicles in networked games
- Radar GUI now includes off-radar indicators
- HUD: Weapon reticle edits, with a different design for weapons with bullet drop
- Balance: Decreased TTK - Everything has around 20% less HP, with weapons doing the same amount of damage as before
- Balance: Decreased all weapon hit forces significantly. Firing force (recoil force on the shooter) is unchanged
- Medium Cannon bullets are no longer affected by gravity (no bullet drop)
- Tweaked camera shake
- Completely revamped the How To Play screens
- Added light flashes to weapons firing
- Updated firing FX on Plasma Artillery and Plasmanator
- Added damage debris FX for weapon hits and collisions
- Fixes for labels above vehicles/things. Better damage indication effect
- Some terrain types now always leave wheel marks - not just when skidding
- New skidmark formula. Skidmarks also now show up while using the handbrake
- Containers are stronger, more expensive, and hold more scrap. Some other minor part stat tweaks
- Load vehicle dialog now shows vehicle scrap values in orange if they're above the currently available scrap allowance
- Load vehicle dialog now supports filtering out overpriced builds entirely
- Load vehicle dialog now remembers your filter settings
- Removed sounds that played when parts were damaged, they were poor quality and mostly unnecessary
- Some improved explosion sounds
- Standard colour coding for quit/continue buttons
- Improved in-game GUI performance
- Revamped the auto-repair sequence that happens when the repair button is pressed
- Revamped turrets - the gun part can now be destroyed separately to the base
- Shockwaves show up better and look kind of cooler in a late 90s game sort of way
- Added a momentary red flash effect on parts that take damage
- Destruction can now cause camera shake
- Adjusted wheel colliders so vehicles are a bit less tippy in general
- Shift key now doubles as the same modifier as Ctrl on the build screen: Allows deleting with one click, or duplicating on place.
- Smoothed out AI aiming; mostly obvious with laser weapons which are now less jittery
- Minor font changes

Bug Fixes:
- Tamed the occlusion culling. No more weird flickers when the game decides something is not visible when it actually is.
- Fixed rotation pivot point on small machine gun (visual fix)
- Fixed AI vehicles being able to trigger "Skipped rebuilding x: Connection point is missing." messages when doing their own rebuilding
- Fixed occasional failures to rebuild vehicle parts in the correct order, due to a sorting bug
- Fixed shockwaves flickering when multiple shockwaves were running at the same time
- Reduced some unnecessary garbage generation
- Fixed electrical damage FX being backwards, showing the most "lightning" at the least damage

 

New minor update, 0.6.0.1:
– Increased Gauntlet mode difficulty a little
– Made Gauntlet level lengths (from spawn to evac pad) shorter in general
Bug Fixes:
– Fixed a bug where the round ending while on the build screen could send the player to the wrong next map

Scraps was also rather kindly invited to participate in a one-week Builder Games Sale which started yesterday, with a lot of building games on Steam involved. Scraps is 75% off during this sale, which is the biggest discount it’ll have for some time.

The full Builder Games Sale page can be found here.

 

New update with major CPU performance improvements, a new turreted version of the Medium Laser, manual vehicle flip for if you get really stuck, and more changes listed below.

0.6.1.0:
- Significantly reduced initial game-start loading time
- Added a turret version of the Medium Laser
- Massive improvements to AI performance, greatly reducing CPU time when playing with many AI
- Can now manually flip your vehicle (max once every 10 seconds) with F. Key assignment can be changed in the game options. Must be grounded and not moving fast
- Auto-flip when upside down is a little more reliable
- Reduced AI max roam speed in Melee mode, so fast vehicles chill out a bit when just patrolling without a target
- Added a little camera shake to collisions
- Removed the small monuments that spawned at previous vehicle-destroyed locations in Gauntlet. They were more annoying than cool
- Increased static friction (friction when not moving). Vehicles are less prone to sliding sideways down slopes
- Demo version no longer uses the XP system. Previously demo could reach up to 900XP, now fixed at 900XP
- Demo version no longer shows help info for game modes
- Area-effect weapons were doing too much damage in general. Reduced area damage overall in several ways, and adjusted costs
- Minor tweaks to vehicle networking
- Adjusted some AI patrol points that were in bad spots on DustBowl and RiverRift
Bug Fixes:
- Fixed several bugs with Gauntlet mode level generation
- Fixed evac pad graphics glitch on TestMap
- Made an evac pad variant for when evac happens on the Gauntlet Water bridge, that looks a little less ridiculous.
- Fixed not being able to drive underneath the Gauntlet Water bridge.
- Improved evac pad height positioning in Gauntlet mode
- Fixed Gauntlet score counter sound

 

The game looks great!! Love the art, however, I can tell that the tanks are all low-poly, which isn't bad. However, looking at the ground gives me some concerns. I think you can just slap a "Poly' normal map on, but I think keeping the art style can draw much more attention. Also the same with explosions would be great. (One last) also, the game could use some vegetation, from what I've seen there is not much to keep the player from just straight up sniping the other tanks besides hills. Maybe some trees or houses would work. But anyway from what I've seen it looks great!!

 

Yeah, I essentially agree with everything you've said. There are some existing areas with more trees but they're not particularly dense (see attached image). The general problem has just been not having an artist on board and my rudimentary 3D modelling skills.

With terrain, I agree it looks too realistic vs. the vehicle style. The thing is I messed around a bit with a low-poly look initially but I couldn't get it to look particularly good so I went with the current semi-realistic option that I could get to look good. And low poly normals + realistic textures gives that sort of HD Minecraft Texture Pack look which never really meshes. Might be able to do better if I tried again now though, it's been a while.

Regarding houses etc, the problem has been that I can't use Asset Store stuff because it wouldn't fit my art style (same problem as the terrain), but it takes a long time to make custom scenery content myself, and it generally doesn't come out that good. So overall there's just not much scenery. In a world where I had unlimited time and/or money I'd love to have a city map.

 

Why don't you make scenery out of the same components, that are used for vehicles? Then you solve many art style issues. And also, make game more interactive. And if not for the last part, then make them static.

 

You mean like scattered wreckage of vehicles and vehicle parts? That's a possibility. I do re-use components in some cases - for instance the drones and turrets in Gauntlet mode re-use some bits from vehicle parts, which also helps show players that they might be able to destroy those bits separately.