next »

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

[Pineapple]

those maps are looking really gorgeous

[Nition]

Thanks! I'm using a hacked-up version of RTP for the terrain which helps a lot. The snow in particular is all a shader effect, with parallax so it sort of rises out of the ground instead of just fading out at the edges.

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

 

[Zireael]

This looks awesome!

[Nition]

Thanks Zireael.

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]

Work on Gauntlet mode level flow is going quite well, except load times are ~15 seconds. Working on that...

[Nition]

Got loading times down to ~9 seconds last week, then got it down to ~7 seconds over the weekend. Not amazing, but less than half what it was. Going to stop soon since each optimisation gets harder than the last.

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

You know, I've been thinking that I must have come up with the idea for a buildable vehicle game when I was around 13-14 years old, combining the likes of Interstate '76 with the building in the likes of Lego Racers or Stratosphere.

But I recently remembered seeing this Sega Master System game for rent in the video store, and being highly intrigued by the box art claim that you could "start out by building your own space ship"!



That must have been around 1992. So maybe I always wanted this sort of game really.

I know I haven't posted any news in a long time. Life has been busy, but I'm still working on Scraps when 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: