next »

[gimymblert]

scraprim?

[Nition]

Scraps got through to be one of the games in the Play By Play exhibition in Wellington later this month.

Play By Play is a new little games expo this year, started by a few locals: http://playbyplay.co.nz/schedule/

It should be a pretty cool showcase of locally-made games. Stuff like Swordy, Poly Bridge, Automation... and there's an Australian games section too!



Scraps please don't crash because I won't actually be there to check on it.

[Nition]

I'm not going to push this because I hate it when games win on popularity or nepotism, but you can vote for your favourite game on the list here, and one of them is Scraps:

https://docs.google.com/forms/d/1kEq72hgREAEVGU2Z-DBBntMeUHO9aBhzi32Irw5UgVA/viewform?c=0&w=1

[Nition]

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.

[Nition]

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.

[Nition]

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.

[Nition]

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

A small taste of things to come.

[Nition]

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).

[Nition]

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.

[Nition]

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.

[Nition]

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.

[Nition]

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.

[Nition]

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!

[Nition]

The new singleplayer Scraps game mode I'm working on is called Gauntlet.



You know how games are prone to having some sort of epic conflict you've got to resolve? Yeah well, here that conflict happened, and now it's long over, and it left only ruins behind.

Here, we fight over the scraps.

And there's one place with the biggest stockpile of scrap of all. And it's well defended. But you're already on the road.

Overview
OK enough cliché. So how will it play? Well, it's sort of a Scraps Roguelike, or more like what's being referred to these days as a Roguelite or (and I realise this is the dumbest term ever) a Roguelike-like.

I usually avoid comparing Scraps directly to other games in official posts as it always seems a little sad when someone can only describe their game in terms of other games. But to get a basic idea, take Vlambeer's popular Nuclear Throne for instance.

Nuclear throne isn't much like Scraps in terms of how the game actually plays, but imagine the character is your Scraps vehicle, the Rads that you pick up are scrap, the mutations you buy are vehicle parts, and the end-of-level portal is an evac pad at the end of a road, and you might sort of have a picture of what Gauntlet mode is.

Gameplay Breakdown
Everything here is subject to change since a lot of this hasn't actually been tested yet. It has to play well. But the idea is:

1. Player starts with around 3000 scrap to create a basic starter vehicle.


2. They enter a semi-procedurally generated level in World 1. I talked a bit about level gen in preview#7. A piece of a larger map is selected, and the player and evac pad are placed:





Then out of a set of hand-placed content, a subset of that content is selected to use in the level:


(top-down view showing active stuff highlighted in green - you might need to click for full size to see it well)

3. The player traverses the level
4. The player reaches the evac point at the end of a level
5. The can spend scrap they've collected on their vehicle
6. Next level begins...

After completing the three levels of World 1, they go onto World 2. If they manage to complete all the levels in all the worlds, they loop back around to World 1, but now they can no longer collect any more Scrap. The goal then will be to destroy as many enemy units as possible before their vehicle is destroyed.

Final score will be based on:

• Total scrap value of enemy units destroyed (i.e. scrap in crates doesn't count)
• As a lesser factor, time to complete the initial run (i.e. before looping back to World 1)

Looping back should be difficult - it's not meant to be easy to complete. And if the player dies, that's it - they start again.



Some more details:

• Every level has a road going through it, with you spawning on the road at one end and the evac pad spawning at the other end.
• Every time you enter world 1-1 or whatever specific level, it will be generated with roughly the same total scrap value, divided in the same way between enemy content that shoots you and inanimate stuff like crates. As the level increases the total scrap in that level also increases.
• You do not have to destroy the enemies in a level to activate the evac point. You can sneak around (most content will be on or near the road) and just go straight there if you like. But you won't have collected scrap from destroying things, which will likely harm your chances eventually, and you won't increase your score.
• At the end of a level, you'll get some "free" repair time on top of the scrap you've collected - an equivalent scrap value of vehicle repairs that will be performed for free (including destroyed parts), but that can't be spent on additional parts. If you have more damage than your free repair time covers, you can still spend scrap on repairs to cover the rest if you have it. This means that more of your scrap collection can count towards actual upgrades - it levels out the results a bit and encourages actually going after dangerous enemy units.
• I'm thinking of three levels per world because well, I have to get a certain amount of use out of the content I'm creating, but it may become two.

ETA
I'd love to also be saying "and the Gauntlet update will be released on {date}!" here as well, but the fact is I'm not sure. I still have a fair amount to do on it especially with having other part-time work on now. What I can say is that I will keep writing updates on progress every week. I was writing updates every two weeks before I started doing the Secret New Content Previews; I'm going to continue that as weekly now. It's good motivation for me as well to get significant things done and not get bogged down in the small details and less important tasks. Here's what's done and what's not on Gauntlet:

DONE

• Created all enemy and inanimate unit types for the new mode - turrets, drones, crates, walls etc
• Created three maps for the new mode, which is enough for the initial release
• Wrote the AI for all the new unit types and updated (with Dave's help) existing vehicle AI
• Got some AI vehicle designs from people on the Scraps forum
• Got my semi-procedural level generation system working
• Wrote some tools to make creating new terrains super fast

TODO FOR INITIAL RELEASE

• Populate the three maps with lots more content for the level generator to choose from
• Write the framework around the new mode - handling game start, game end, scoring etc
• Finish up the level generation system
• Finish up the desert and snow terrains
• 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

TODO LATER

• Token system: Along with scrap wreckage, I want vehicles to be able to drop tokens that let you unlock new parts - either just within the current game, or usable anywhere. For example, a super big cannon you can use in the current game, or a cosmetic piece you can use anywhere that you can only get by getting so far in Gauntlet.
• More worlds: Ideally I want five worlds rather than three. Some level of extra content might depend a bit on how much people actually enjoy the game mode.

Thanks for reading!

P.S. I suddenly thought I might have accidentally mentioned the game mode name back at preview #5 when I got the comment on it. Well predicted.

[Nition]

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

[Nition]

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.

[Nition]

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.

 

[Nition]

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:

void DrawGizmoArrow(float xPos, float zPos) {
	Gizmos.color = Color.green;
	float arrowHeight = 300;
	Vector3 arrowStart = new Vector3(xPos, arrowHeight, zPos - 200);
	Vector3 arrowEnd = new Vector3(xPos, arrowHeight, zPos + 200);
	Gizmos.DrawLine(arrowStart, arrowEnd);
	Vector3 crossLineStart = new Vector3(xPos - 50, arrowHeight, zPos + 50);
	Vector3 crossLineEnd = new Vector3(xPos + 50, arrowHeight, zPos + 50);
	Gizmos.DrawLine(crossLineStart, crossLineEnd);
	Gizmos.DrawLine(crossLineStart, arrowEnd);
	Gizmos.DrawLine(crossLineEnd, arrowEnd);
}

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

[Nition]

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

[Nition]

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: https://youtu.be/ZGKtSYu71t0?t=98


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?