next »

[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?

[Nition]

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 for any Unity devs out there.

In Unity, if you want to add things to a scene you usually drag prefabs from the Project window, which is really just a folder view. It works pretty well but it means that you need to switch around in folders to find things, and you also can't see the object while you're positioning it. Unity provides pretty good tools to customise the editor so I made a little custom window instead:



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:

using UnityEngine;
using System.Collections.Generic;
using System.Linq;
using UnityEditor;

// GUI editor interface for easily placing a set of hard-coded prefabs on a map
public class SimpleThingPlacer : EditorWindow {
	// Set in inspector. Have this enabled to give prefabs a random starting rotation
	[SerializeField]
	bool randomYRotation = true;

	// Got prefabs that don't have a visual model? Put their GameObject names here to see a visual indicator when holding them
	readonly string[] prefabsThatNeedVisualIcons = {"VehicleSpawner"};

	// Your prefabs can be assigned to categories you define here, and will show up in these groups in the editor window
	enum Categories { NonEnemy, Enemy, Group }

	Dictionary prefabs;
	GameObject curHeldPrefab;

	// #### UNITY INTERNAL METHODS ####

	protected void OnGUI() {
		if (Application.isPlaying) return;
		if (prefabs.IsNullOrEmpty()) LoadPrefabList();

		EditorGUILayout.BeginVertical("Box");
		randomYRotation = EditorGUILayout.Toggle("Random Y rotation: ", randomYRotation);
		EditorGUILayout.EndVertical();

		// This is pretty basic - could be modified to auto-set NUM_PER_ROW based on window width
		const int NUM_PER_ROW = 3;
		const int ENTRY_HEIGHT = 64;
		const int ENTRY_WIDTH = 80;
		foreach (KeyValuePair category in prefabs) {
			bool isInRow = false;
			EditorGUILayout.BeginVertical("Box");
			EditorGUILayout.LabelField(category.Key.ToString(), EditorStyles.boldLabel);
			List p = category.Value;
			for (int i = 0; i ();

		// Replace these with the paths to the assets you want to show up
		// Or these hard-coded paths could be replaced by automatically loading all assets in a folder etc
		// Or maybe create an interface in the editor window itself to add/remove prefabs
		AddPrefab(prefabs, Categories.NonEnemy,  "Assets/Prefabs/Environment/SinglePlayerPhysicsDamageable/Walls/WoodenWall.prefab");
		AddPrefab(prefabs, Categories.NonEnemy, "Assets/Prefabs/Environment/SinglePlayerPhysicsDamageable/Walls/ConcreteBarrier.prefab");
		AddPrefab(prefabs, Categories.Enemy, "Assets/Prefabs/EnemyNonVehicles/Drones/MMGDrone.prefab");
		AddPrefab(prefabs, Categories.Enemy, "Assets/Prefabs/EnemyNonVehicles/Drones/SMGDrone.prefab");
		AddPrefab(prefabs, Categories.Group, "Assets/Prefabs/GauntletSets/GauntletEarthRoadblock1.prefab");
	}

	// Path should start with the Assets forlder, e.g. "Assets/Textures/texture.jpg"
	void AddPrefab(Dictionary prefabDict, Categories category, string path) {
		GameObject prefab = AssetDatabase.LoadAssetAtPath(path, typeof(GameObject)) as GameObject;
		if (prefab != null) {
			ISpawnedThing ist = prefab.GetComponent(typeof(ISpawnedThing)) as ISpawnedThing;
			if (ist != null) {
				if (!prefabDict.ContainsKey(category)) prefabDict[category] = new List(1);
				prefabDict[category].Add(prefab);
			}
		}
		else {
			Debug.LogWarning("Couldn't find prefab at: " + path);
		}
	}

	void CreatePrefab(GameObject prefab) {
		curHeldPrefab = (GameObject)Instantiate(prefab);
		// Remove any automatic "(clone)" designation
		curHeldPrefab.name = prefab.name;
		if (randomYRotation) {
			Vector3 eulerRot = curHeldPrefab.transform.eulerAngles;
			eulerRot.y = Random.Range(0, 359);
			curHeldPrefab.transform.eulerAngles = eulerRot;
		}
		Selection.activeGameObject = curHeldPrefab;
	}

	void ReleaseHeldPrefab() {
		curHeldPrefab = null;
	}

	// Returns true if the input transform or any of its parents, grandparents etc have the specified tag.
	static bool HasTransformInAncestors(Transform trans, Transform match) {
		if (trans == match) return true;

		trans = trans.parent;
		while (trans != null) {
			if (trans == match) return true;
			trans = trans.parent;
		}
		return false;
	}
}

[Nition]

Last week I got a nice job offer that I've accepted, but it had to be a full-time position, so it's not going to leave much remaining time for Scraps unfortunately. It's an offer that I would be silly to ignore in favour of my obscure little game that I've already been working on for years without much success (income-wise anyway). Of course Scraps could take off in success after Gauntlet mode is added, or after it leaves Early Access, but historically that's very rare: Almost always if a game's sales are slow at first during Early Access, they remain a small-time thing at full release.

So I'm going to stop the current weekly news updates since development is gonna get real slow. I'll post whenever I have interesting new stuff to share instead.

Here's what I did in my last week of freedom:

I made some more level content. Yeah, I'm still on world 1, because I keep making things like tools for level building or things to put in the levels rather than actually putting things in levels. Subsequent maps should be way faster to populate, like how the terrains for worlds 2 and 3 were done much much faster than the terrain for world 1.


A thing I did this week in that vein was make a new type of vehicle spawner. I already had vehicle spawners that I could place on the map with a list of vehicles they could spawn. Looked like this in the editor:


When playing, they'd randomly select a vehicle to spawn from the list, and that worked OK. Gauntlet mode is sort of half procedural, half hand-placed, and it's important to be careful with how procedural it is. Fully hand placed would make it exactly the same every time, which would get boring fast. But fully procedural almost always ends up boring as well - a million variations on the same thing. No Man's Sky is the procedural game du jour to complain about, but there are many.

However, in this particular case I realised that there were many scenarios where I really just wanted a vehicle spawner that would spawn any vehicle I had that was appropriate for the current level. Same potential set for every spawner. On top of that, really the vehicles should get harder as you progressed to another level within the same world, but to do that currently I'd have to place multiple spawners and limit them to just the level they were intended for.

So I made a vehicle library that loads up all the vehicles I've put in a folder, and lets me select them with filters. For instance if I wanted a vehicle in a certain price range with only cheap weapons on it I could do:

Code:

vehicleLibrary.GetVehicle(VehicleFilters.TotalCost(minValue, maxValue),
	VehicleFilters.EachWeaponCost(weaponCostLimit));

Or for a vehicle in a certain price range with a small chassis:

Code:

vehicleLibrary.GetVehicle(VehicleFilters.TotalCost(minValue, maxValue),
	VehicleFilters.ChassisType(VehicleData.ChassisOptions.Small));

"But writing code every time? That sounds like even more work than placing two spawners." Well yeah, it would be, but I made a new vehicle spawner that automatically detects which Gauntlet level the player is on and sets the appropriate filters. So there's no vehicle info to set in the interface at all:


And I can still use the old spawner type if I want specific vehicle options.

In other news, at one point I also accidentally broke everything in a fun way:

[Nition]

The Unity engine has a built-in terrain system that's been around for ages. It's honestly pretty great actually, but it has a few quirks. The tree system is maybe the quirkiest part.

There's 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.

[Nition]

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.

[Nition]

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

 

[Nition]

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 TIGSource 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

[Nition]

Gauntlet tasks to do before initial release
– Get local games fully working
– 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?


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.

[Nition]

Gauntlet tasks to do before initial release
– Get local games fully working
– 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?


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:

[Nition]

Gauntlet tasks to do before initial release
– Get local games fully working
– 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?


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.

[Nition]

Gauntlet tasks to do before initial release
– Get local games fully working
– 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?


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:



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:



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.

[Nition]

Gauntlet tasks to do before initial release
– Get local games fully working
– 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?

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.

 

[Nition]

Gauntlet tasks to do before initial release
– Get local games fully working
– 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?


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

[Nition]

Gauntlet tasks to do before initial release
– Get local games fully working
– 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?


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.

[Nition]

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:

[Nition]

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

[Nition]

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.

[Nition]

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

[Nition]

I released Scraps v0.6.2.0 yesterday. This update adds a new world to Gauntlet mode, adding three more levels to Gauntlet in total, along with other fixes and improvements. It's getting there; there's only one more proper Gauntlet world to do, plus a final boss kind of level.



0.6.2.0
- Added a new Gauntlet world, bringing the current total to eleven levels over five worlds
- Adjustments to existing Gauntlet systems. Earlier worlds are a little easier.
- Gauntlet game mode now automatically saves and allows the player to continue from the start of some worlds
- Gauntlet mode AI cars are now disabled when far away, as a performance consideration
- Can now see Gauntlet world info on the pause (Esc) screen
- Wreckage in Gauntlet mode can now be collected immediately with no delay (Melee mode still has a delay so others have a chance to grab it)
- Slightly increased weapon costs for laser and medium cannon
- (Kickstarter backers) Tesla Device now prioritises enemy targets above non-enemy ones like crates
- (Kickstarter backers) Tesla Device now ignores proximity firing mode (can keep shooting in all directions)
- Some adjustments to GUI fonts and layout
- Improvements to weapon hit forces, and reduced them overall
- Increased HP by around 15% on all cockpits and chassis types
- Laser weapons now have a SLIGHT inaccuracy, still highly accurate
Bug Fixes:
- Fixed the bug where skidmarks could join incorrectly, causing a big straight line across the map
- Game mode select buttons no longer animate if a dropdown is open
- Fixed dropdowns staying open in the background when pressing Esc to close UI
- Fixed AI in Gauntlet mode not following their patrol points in the correct order
- AI is better at transitioning from one patrol point to the next
- Time spent paused no longer counts towards Gauntlet level completion time
- Much reduced the jittering that often happened when a vehicle ended up on its side
- Fixed a couple of bugs with AI pathing

[Nition]

Gauntlet mode is finally done! There are seven worlds to fight through while upgrading your vehicle to fight increasingly difficult enemy vehicles, turrets and drones.

A few screenshots; Scraps isn't the most beautiful game but it sure looks a lot better than it did a few years ago:









Scraps itself is now almost done as well. I'll make another post in the next few days that will detail what's still to come. Much of it is actually already done in a separate branch, so we're not too far off now. What a journey.

0.7.0.0:
- All seven Gauntlet worlds are now available. Gauntlet mode is complete
- Added Gauntlet mode option to test a vehicle build before deploying to the next level
- Gauntlet high score list now automatically slots in high scores from any of your Steam friends
- Small Capacitor is now unlocked from the start
- Drone enemies shoot a bit more accurately
- Barrels and ExplodeBalls do a bit less max damage (same damage radius, and same force though)
- Did a balance pass on all weapons, various changes, nothing crazy
- Disabled edit and new vehicle options when selecting a vehicle for an AI player in the lobby. Fixes the human player's vehicle selection getting cleared as well
- Gauntlet progress now saves at the end of a world as well as when deploying into the next one, so if you quit during Build you'll still be able to continue
- Gauntlet mode no longer stores scores of 0 on the leaderboard
- Gauntlet mode saves now only permanently store the highest score achieved using that particular save on the leaderboard
- Increased the range from which AI will start shooting, some other minor AI tweaks
- Clearing progression no longer clears unlocked cosmetics. Particularly important as the "Alpha Crown" for completing Gauntlet mode while it was still in development is no longer possible to earn
- Increased max suspension spring setting from 62500 to 80000
Bug Fixes:
- Plasmanator now ignores proximity firing mode, so moving out of the radius doesn't cancel a held charge
- Clearing user data or progression in the game options now clears Gauntlet saved progress as well
- Leaving Gauntlet mode from the Build screen now goes to the Gauntlet end-game screen instead of straight to the main menu
- AI vehicles now try a lot harder not to drive off the cliffs on Gauntlet Wind
- Improved AI aim calculation with projectile weapons vs. moving vehicles
- Fixed transparent shader rendering order issues, particularly laser weapons appearing to be behind grass
- Fixed smoke damage FX decreasing with health lost instead of increasing
- Fixed a couple of bugs with how AI drives in close combat
- Fixed a bug with AI close combat where cars could think they were stuck on what should be good ground
- Fixed audio bug when using multiple Plasmanators