Dear Scraps players Scraps will soon be delisted from the Steam store. Scraps has been selling near zero copies for quite some time, and although I've kept it running for a long while, I can't keep supporting it forever. Apart from keeping the main server running, eventually some OS or hardware update is bound to come out that breaks something in Scraps, and it's running on such an old version of the Unity engine that it'll be impossible to fix without a huge amount of work to upgrade. I don't feel it's fair to continue selling a game that's unsupported. Soon Scraps will no longer be available to purchase, and the remaining USA server that I keep running will be shut down. Thankfully Scraps does not require a central server to keep multiplayer working. If you already own the game, you will still be able to download it in your Steam library and play it, and although there will be no permanent official multiplayer server running, anyone should still be able to host a server - be it either a dedicated server, or a game they're playing in that they've set to allow others to join. On LAN or Internet as always. Those systems run on Steam's own back-end. Thank you all so much for the great memories of making and playing Scraps: Modular Vehicle Combat.
Update: I've applied a 90% discount closing down sale price.

[ 2023-02-17 20:38:53 CET ] [ Original post ]

- AI now only shoots at its target if it has weapon line-of-sight (previously was based only on whether it could see/hear the target.

[ 2021-02-10 21:09:57 CET ] [ Original post ]

2021-02 - 1.0.2.1 - Fixed the Melee mode timer not pausing when the game is paused, when playing singleplayer - Fixed the end-of-round screen not working correctly if the round ended while a game was paused

[ 2021-02-05 07:21:56 CET ] [ Original post ]

1.0.2.0 - Increased AI hearing range a bit - Gauntlet vehicle test exit menu is less confusing - Modified post-loop Gauntlet vehicle spawns and costs Bug Fixes: - Fixed not being able to connect to a game with the correct password after previously attemping to connect with an incorrect password

[ 2020-12-23 08:41:21 CET ] [ Original post ]

- Fixed missing lightmaps for ColdHill walls - Fixed a text fitting bug on the Build screen - Fixed a bug joining LAN games from the demo version - Fixed some Kickstarter content not showing up - Fixed a bug with Kickstarter reward flag animation

[ 2020-12-19 23:05:25 CET ] [ Original post ]

Well, this has been a long time coming. Scraps is released, finished, done! I'll continue to support major bug fixes or issues if they come up for at least the next six months, as detailed in my previous post here. That post covers everything about this release already, so I'll use this post to look back at some Scraps history.

1.0 Changelog

- Added two new Melee mode maps: Desert Road and Cold Hill - Added gold/silver/bronze/spiked Kickstarter reward items - Added icons next to player label for Kickstarter backers at Knight and Master And Commander level - Added free repair time at the build screen after Gauntlet Final to the point where it should always provide full repairs - Had to clear existing local Gauntlet leaderboard scores due to code changes. Sorry! - Added slight randomness to the vehicle's position after an automatic flip over - Vehicle flip action now checks to make sure it won't be teleporting through a wall - Flipping your vehicle while inside a building no longer teleports you to the roof

Bug fixes:

- Physics objects (crates, barrels) now interpolate their position, don't look jittery - AI is now less confused by buildings - Fixed collision bugs on Gauntlet Earth retaining walls - Fixed container lid not showing up on Build screen - Fixed evac pad ramp sticking out of terrain on Test Map - Fixed Medium Cannon and Medium Cannon Turret invisible polygons on the base And now a bit of a look back.

2012

Scraps development begins. In these early screenshots from December 2012 you can see the basic layout of the Test Map already in place, as well as some placeholder part models and a primitive version of the small chassis (sporting a nice final version of the wheel model!). The guns require power and don't generate heat.


I took these screenshots to start a DevLog on TIGSource and on the Unity forums, where I described the game as "Like Kerbal Space Program except the spaceships are vehicles and they fight." I let people download a super early "builder demo" where they could try building and driving their own vehicles.

2013

[previewyoutube=x9XgX-VU6kw;full][/previewyoutube] Its early 2013 and some more of the models are done. You can build and test but theres no sound and the weapons keep hitting your own vehicle when they fire. Luckily theres no damage yet either.




Later in the year I produced this simple trailer, when I later re-did again with updated graphics for the Scraps Kickstarter campaign (December 2013). [previewyoutube=EITD1kE2iuQ;full][/previewyoutube] I was also beginning to work on multiplayer support.

2014

Multiplayer was a big job, but in September I had it stable enough to try out a real LAN game with a couple of other players. [previewyoutube=xMVma2lix78;full][/previewyoutube] Thats an extremely early version of the Sandy Bridge map. Dust Bowl was also in at that point, but I picked the smaller map since this was a three-player game. Not long after that I showed Scraps at PAX Australia.


The AI was also coming along; the only thing in Scraps that I contracted out apart from one nice piece of art. Although any work on AI since the original version has been mine. [previewyoutube=B1MVDB6zpKY;full][/previewyoutube]

2015

Scraps went through the Steam Greenlight process (which no longer exists), and got its official release on Steam Early Access in July 2015, with multiplayer (LAN or Internet) and AI for singleplayer melee.
But by the end of 2015 I was seeing that Scraps really needed another singleplayer mode of some sort to make it a worthwhile purchase, given the very low playerbase in multiplayer and the limits of the AI melee mode.

2016

I started working on Gauntlet mode, another major undertaking.


Too major, really. Scraps had been going on for too long already and wasnt really getting sales anymore. I couldnt justify working on it full time any longer, and 2016 was the year I got other, full time work. Scraps became a project I worked on in any remaining free time I had, which slowed down development further.

2017-2019

I kept chugging through getting Gauntlet done. I also refactored some parts of the game, as Id grown in ability as a programmer over time and some old bits were really showing their age. In December 2019 I finally released the first version of Gauntlet that was publicly playable, which included the Landing Point, Earth, Water, and Transition worlds.

2020

I added a release that included Gauntlet Wind, and finally the complete version of Gauntlet. And now here we are. Check out the two new Melee maps that come in this release as well.

Thanks so much for your patience. I hope you have fun with my game.

[ 2020-12-18 21:11:11 CET ] [ Original post ]

Scraps has been in development for a long time. I started this game in late 2012, working full time. I had originally hoped to get an initial version out by mid-2013. When it took longer than that, I ran a Kickstarter campaign in late 2013. It was relatively successful and kept things going. In late 2014 I had multiplayer working and showed Scraps at PAX Australia. In mid-2015 it released to Early Access on Steam after making it through the Steam Greenlight process (remember that?). In early 2016 things were really taking longer than I had hoped, and since the multiplayer servers were usually empty, I decided to work on a new singleplayer mode named Gauntlet that would make the game a much more worthwhile purchase even without an active playerbase. In late 2016 Scraps was taking much longer to complete than I had initially hoped, especially with the new Gauntlet mode, and Scraps sales never did very well. I reluctantly picked up another full-time job to provide an income, knowing that it would only prolong the trek to complete Scraps even further. I was very lucky to land a job making games at Facepunch Studios, and I continued to work on Scraps in the free time I had remaining, usually around an hour a day during the week. I never stopped working on it, and Gauntlet mode was recently - finally - released in full. It's got seven worlds to fight through against enemy vehicles, turrets, and drones, all while upgrading your vehicle. More content than I originally planned, and the levels you fight through are a bit different every time.

What's Still Coming

Within the next few weeks I'll be releasing Scraps out of Early Access and it'll be done for real. The main thing that's coming in that update are a couple of additional maps for Melee mode:
Desert road is set up like a simple racetrack, just as an additional option to play around with.
Cold Hill a king-of-the-hill type layout, with the spawns at ground level but the only evac pad located on the hilltop.

What's not coming

I've been working on Scraps for over eight years now. I wanted to get it finished and I have, both because you and others have paid good money for it, and because I'd always be disappointed in myself if I didn't, just like I would have been if I'd never taken the risk and started. But I need to have it done. It's been eight years of always feeling like I should be working on it, never really getting a break. I haven't let it consume my life - I've seen how that road goes for other indies. But I haven't started any side projects. I stopped recording music. I've done what I can but it's time to move on. So, I don't like to say it but two major features that I said would go in at some point are cut: Team Melee - Intended to be a two-sides version of Melee mode. With the lack of multiplayer interest, this isn't too much of a loss anyway. Tank Tracks - It would be a major undertaking to add additional propulsion types beyond wheels at this point. I'm really sorry that this one isn't making it in, but if it's any consolation I don't think it would have made a major difference to gameplay. I think Gauntlet mode (which was never originally promised) adds a lot to the game. I hope that helps make up for the missing bits above.

Some questions you might have

Here are a few more general answers. Q: Will Scraps still be updated after it leaves Early Access? A: Game updates no, bug fixes yes. I intend to fix any major bugs and issues that come up for at least the next six months. The only exception to that will be if something external like an operating system update causes a bug at the game engine level, as the version of the Unity engine that Scraps runs on is very old at this point and requires a massive amount of work to update to the latest. Of course, an update like that that breaks Scraps would likely also break many other existing games, so hopefully that doesn't happen. Q: What if Scraps becomes popular though and starts making money? It's not even out of Early Access yet - how do you know it's failed? And what about marketing? A: Almost always, Early Access performance is a strong indicator of post-release performance. It's very unusual for a game to be small in Early Access but get a big release. Usually an Early Access launch is basically the real release launch. So I'm not expecting much. I could do a big marketing push at release like I did in the early days, which may help or it may not (these days good marketing depends on a lot on things like getting through to big-name streamers, more than just paying to advertise somewhere). But I need to move on now, whatever happens. I think the final result is good, I'm proud of my little game, and it's something I always wanted to make. When I started Scraps the landscape was very different. I'd been waiting a long time for a game with buildable cars like this and there was nothing. Then soon after I started, Robocraft came out, and now in 2020 "buildable vehicle combat games" is pretty much a genre unto itself. Robocraft, TerraTech, Besiege, Crossout which looks incredibly similar in concept to Scraps. I was banking on the unique gameplay to be a major selling point and in the end it was one of many, which lost its selling power to a great extent. Oh well. At least we now have plenty of games in this genre to try, I always knew it'd make an excellent premise. Q: Will the price increase at release? A: No, and I'll do a pretty steep launch discount. If it gets a few players on the multiplayer servers for a while it'll be good for everyone. Q: What are you going to work on next? A: Something different, finally.

Thank You

I'm sure I'll say this again at release in a few weeks, but thank you for contributing to Scraps and coming along for the ride. I'm sorry it's taken so long to get here but I'm happy to have made something from my imagination that people really enjoy. This was my first real game project and I think some things (especially semi-authoritative physics-based multiplayer networking) only got done because I didn't know yet that they should be impossible. It's been quite a journey.

[ 2020-12-03 20:40:28 CET ] [ Original post ]

Gauntlet mode is complete with all worlds available. There are seven worlds to fight through while upgrading your vehicle to fight increasingly difficult enemy vehicles, turrets and drones. I hope you enjoy it.

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.

Thank you for your patience, truly.

Changelog

- 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

[ 2020-12-01 20:44:38 CET ] [ Original post ]

This update adds a new world to Gauntlet mode, adding three more levels to Gauntlet in total, along with other fixes and improvements.

Changelog

- 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

[ 2020-08-17 22:55:10 CET ] [ Original post ]

This update brings 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. You can expect the next major update to include a new Gauntlet world. Scraps v0.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

[ 2020-03-18 03:41:55 CET ] [ Original post ]

Scraps was rather kindly invited to participate in a one-week Builder Games Sale which is starting today, with a lot of building games on Steam involved. Scraps is a massive 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: https://store.steampowered.com/curator/4/sale/buildersale

[ 2020-01-12 08:37:54 CET ] [ Original post ]

A minor patch, mainly to fix a round end bug. But there's a little Gauntlet mode adjustment as well. 2020-1 - 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

[ 2020-01-10 10:26:12 CET ] [ Original post ]

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

[ 2019-12-20 07:55:26 CET ] [ Original post ]

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:

[ 2019-10-13 21:21:27 CET ] [ Original post ]

Gauntlet tasks to do before initial release

– [strike]Get local games fully working[/strike] – [strike]Object for holding game state in Gauntlet mode[/strike] – [strike]Auto-repair system + vehicle swap ability[/strike] – [strike]Gauntlet game flow from menu to end[/strike] – [strike]Score system[/strike] – [strike]Level generation tweaks[/strike] – [strike]Update scrap drop system[/strike] – [strike]Item unlock system[/strike] – [strike]Update How To Play screens[/strike] – 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.

[ 2018-05-24 11:26:16 CET ] [ Original post ]

Gauntlet tasks to do before initial release

– [strike]Get local games fully working[/strike] – [strike]Object for holding game state in Gauntlet mode[/strike] – [strike]Auto-repair system + vehicle swap ability[/strike] – [strike]Gauntlet game flow from menu to end[/strike] – [strike]Score system[/strike] – [strike]Level generation tweaks[/strike] – [strike]Update scrap drop system[/strike] – [strike]Item unlock system[/strike] – 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).

[ 2018-03-08 09:59:36 CET ] [ Original post ]

Gauntlet tasks to do before initial release

[strike]Get local games fully working[/strike] [strike]Object for holding game state in Gauntlet mode[/strike] [strike]Auto-repair system + vehicle swap ability[/strike] [strike]Gauntlet game flow from menu to end[/strike] [strike]Score system[/strike] [strike]Level generation tweaks[/strike] [strike]Update scrap drop system[/strike] [strike]Item unlock system[/strike] 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).

[ 2018-03-08 09:59:36 CET ] [ Original post ]

Gauntlet tasks to do before initial release

– [strike]Get local games fully working[/strike] – [strike]Object for holding game state in Gauntlet mode[/strike] – [strike]Auto-repair system + vehicle swap ability[/strike] – [strike]Gauntlet game flow from menu to end[/strike] – [strike]Score system[/strike] – [strike]Level generation tweaks[/strike] – [strike]Update scrap drop system[/strike] – Item unlock system – Update How To Play screens – Test and balance gameplay – Music? Sorry for the 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.  

[ 2018-01-24 10:08:40 CET ] [ Original post ]

Gauntlet tasks to do before initial release

[strike]Get local games fully working[/strike] [strike]Object for holding game state in Gauntlet mode[/strike] [strike]Auto-repair system + vehicle swap ability[/strike] [strike]Gauntlet game flow from menu to end[/strike] [strike]Score system[/strike] [strike]Level generation tweaks[/strike] [strike]Update scrap drop system[/strike] Item unlock system Update How To Play screens Test and balance gameplay Music? Sorry for the 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.

[ 2018-01-24 10:08:40 CET ] [ Original post ]

Gauntlet tasks to do before initial release

– [strike]Get local games fully working[/strike] – [strike]Object for holding game state in Gauntlet mode[/strike] – [strike]Auto-repair system + vehicle swap ability[/strike] – [strike]Gauntlet game flow from menu to end[/strike] – [strike]Score system[/strike] – [strike]Level generation tweaks[/strike] – 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.

[ 2017-11-24 10:21:03 CET ] [ Original post ]

Gauntlet tasks to do before initial release

[strike]Get local games fully working[/strike] [strike]Object for holding game state in Gauntlet mode[/strike] [strike]Auto-repair system + vehicle swap ability[/strike] [strike]Gauntlet game flow from menu to end[/strike] [strike]Score system[/strike] [strike]Level generation tweaks[/strike] 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.

[ 2017-11-24 10:21:03 CET ] [ Original post ]

Gauntlet tasks to do before initial release

– [strike]Get local games fully working[/strike] – [strike]Object for holding game state in Gauntlet mode[/strike] – [strike]Auto-repair system + vehicle swap ability[/strike] – [strike]Gauntlet game flow from menu to end[/strike] – [strike]Score system[/strike] – 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.

[ 2017-09-26 09:59:22 CET ] [ Original post ]

Gauntlet tasks to do before initial release

[strike]Get local games fully working[/strike] [strike]Object for holding game state in Gauntlet mode[/strike] [strike]Auto-repair system + vehicle swap ability[/strike] [strike]Gauntlet game flow from menu to end[/strike] [strike]Score system[/strike] 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.

[ 2017-09-26 09:32:22 CET ] [ Original post ]

Gauntlet tasks to do before initial release

– [strike] Get local games fully working[/strike] – [strike] Object for holding game state in Gauntlet mode[/strike] – [strike] Auto-repair system + vehicle swap ability[/strike] – [strike] Gauntlet game flow from menu to end[/strike] – 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:

[ 2017-08-23 11:04:09 CET ] [ Original post ]

Gauntlet tasks to do before initial release

[strike] Get local games fully working[/strike] [strike] Object for holding game state in Gauntlet mode[/strike] [strike] Auto-repair system + vehicle swap ability[/strike] [strike] Gauntlet game flow from menu to end[/strike] 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:

[ 2017-08-23 11:04:09 CET ] [ Original post ]

Gauntlet tasks to do before initial release

– [strike]Get local games fully working[/strike] – [strike]Object for holding game state in Gauntlet mode[/strike] – [strike]Auto-repair system + vehicle swap ability[/strike] – 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.

[ 2017-07-30 22:45:38 CET ] [ Original post ]

Gauntlet tasks to do before initial release

[strike]Get local games fully working[/strike] [strike]Object for holding game state in Gauntlet mode[/strike] [strike]Auto-repair system + vehicle swap ability[/strike] 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 includerebuilding 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'lltry 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 bea huge spread in potential vehicle value once the player hascompleted a few levels, which becomes hard to manage. Say I want to have the playerbe 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 about50% 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 unlimitedfree repairs, all scrap collected couldgo to vehicle upgrades.I'm still experimenting with how much free repair time I actually provide. I don't want everything to be totally balancedand 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 isexactly the same except the "money" for it comes from a different place.Keeps things simple vs. having two different systemsto 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 beinglevel loading times. Loadnig a Gauntlet mapwas 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.

[ 2017-07-30 22:27:40 CET ] [ Original post ]

Gauntlet tasks to do before initial release

– [strike]Get local games fully working[/strike] – [strike]Object for holding game state in Gauntlet mode[/strike] – 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? "Object for holding game state in Gauntlet mode" is probably the most boring entry on the task list (wow what a great way to open a blog post), but let's talk technical stuff.

Scraps and persistent state

The Unity engine that Scraps is written in has this concept of "Scenes." You can put stuff in a scene, like make a level for your game. You can attach stuff to stuff in your scenes, like lights and physics and scripts that run code. A nice thing about Scenes is that when you go to a different one, everything you put in the first scene is unloaded, so you know you didn't accidentally leave anything hanging around taking up memory[1]. But sometimes obviously you want stuff that doesn't go away on scene change. Scraps Melee games need to remember who's playing when the map changes, Gauntlet games need to remember the player's scrap amount/score/etc when they move between levels, everything needs to remember which vehicle the player has selected and so on. You can create code that doesn't get destroyed on scene changes, either by making it totally separate from the scene system, or by marking it in the scene with a special DontDestroyOnLoad flag. Anyway, in the Scraps system:
(click for big) Everything there except ServerStartupInit (which just gets things going on the server) is persistent between scenes. Server is an object on the server, sort of a master controller. Client (for multiplayer) or Local (for singleplayer) are its client-side equivalents. There's a ScrapsPlayer for each player in a game - both AI or human. VehicleBase is a script on the vehicles themselves. It's subclassed into Client and Server variants. Having a ScrapsPlayer rather than having a player be their vehicle means that a player can continue to exist and run code when they don't have a vehicle, like between being destroyed and respawning. Whereas having VehicleBase on the vehicle means that vehicle-specific actions can still be done on the vehicle itself. For instance say a ScrapsPlayer decided to set the health level on a vehicle in 1 second's time, and within that time the player's vehicle changed to a different one, it could end up setting that health level on the wrong vehicle. If the vehicle script decided to do the same thing and the vehicle got destroyed within that second, the command would get destroyed as well and never happen. OK that's a pretty contrived example, but I do remember something somewhat like that being a real issue at one point. Network latency in particular makes everything need a bit more careful protection. ANYWAY, I haven't needed to update any of that very much, that's just some random info about the whole system. What I have needed to do is add a new type of GameData, because GameDataServer/GameDataClient/GameDataLocal were more like MeleeModeGameData. I mean look at this stuff in GameData:
(SUPER SECRET SCRAPS CODE DO NOT STEAL™) Number of players, networking stuff, starting scrap and other melee game settings. None of that's needed for a new singleplayer mode and adding Gauntlet mode stuff to it would just make it a big mess. So anyway GameData is now MeleeGameData and there's a new GauntletGameData too. It stores the player's score, what level they're on, etc. When a new game is started the appropriate GameData object is created based on the game type. I'm not sure if the next item on the list completed will be "Auto-repair system + vehicle swap ability" or "Gauntlet game flow from menu to end". The former is part of the latter but I might be able to do the game flow without having the new build screen systems totally ready. [1] As with many things code-related, this is sadly true only in the most naïve, optimistic theoretical way. If you have anything that doesn't get destroyed on a scene change (like a static class or a class with DontDestroyOnLoad), and it references something that should, the thing will still stay in memory until the reference is cleared.

[ 2017-05-22 11:10:36 CET ] [ Original post ]

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

- [strike]Get local games fully working[/strike] - 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).  

[ 2017-05-08 10:53:03 CET ] [ Original post ]

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: https://www.youtube.com/watch?v=mJVNoWncFjQ 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.

[ 2017-04-23 04:46:02 CET ] [ Original post ]

I haven't posted for a while as I haven't had anything particularly interesting to show, so I just want to check in to show that I'm still here. When I get some time I've mostly been working on content in Gauntlet mode World 1. Once I've done everything in that world I'll be writing the framework that surrounds Gauntlet mode itself - that is, the process that you go through from clicking to select Gauntlet, choosing a starting vehicle, entering a level, going to the next level etc. The different parts of that are basically features the game already, but they need to be strung together and bolstered in the right ways. Luckily Gauntlet maps past World 1 will also be a lot faster to create because 90% of the time I've spent on World 1 has been in making tools and systems rather than the content itself - both creation tools, and code for the semi-random generation of the map's content when it's played. I'll check in again when I've next got something to show.

[ 2016-11-19 00:02:52 CET ] [ Original post ]

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.

[ 2016-09-25 20:35:25 CET ] [ Original post ]

Let's get the bad news out of the way first. Last week I got a nice job offer that I've accepted. And it had to be a full-time position, so it's not going to leave much remaining time for Scraps. 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 apologise to anyone reading this because development is gonna get real slow on Scraps. I don't like to let the community down even though it's small. You can still rest assured that I'm not going to abandon this project - Scraps is still gonna get done! But here's what I'm going to do: - I'm going to stop the current weekly news updates since I expect there won't be much for each one. I'll post whenever I have interesting new stuff to share instead. - I'm going to add information to the game's description on the Steam store page saying that it's a hobby/side project at this point and development will probably be slow. I don't want to deceive anyone here. - I'm not going to put the game in sales anymore (25% off etc) until either Gauntlet mode is in, or I go back to having more time to work on it. The Scraps community is so nice; I want to deliver you an awesome game. But as I said earlier I'd be silly not to take this job, which is exactly the sort of job I want. 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: vehicleLibrary.GetVehicle(VehicleFilters.TotalCost(minValue, maxValue), VehicleFilters.EachWeaponCost(weaponCostLimit)); Or for a vehicle in a certain price range with a small chassis: 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:

[ 2016-08-28 10:13:37 CET ] [ Original post ]

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. Here's the code: http://pastebin.com/E3xmmUWd

[ 2016-08-21 03:46:40 CET ] [ Original post ]

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 update 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://www.youtube.com/watch?v=ZGKtSYu71t0 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?

[ 2016-08-16 06:37:32 CET ] [ Original post ]

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

[ 2016-08-07 10:13:33 CET ] [ Original post ]

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

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

Hopefully that's now every feature it needs. I'll really try to stick to that because I know in gamedev it's all too easy to get stuck working on the "engine" forever and never actually make the game. I also think the level gen is all working correctly now (it's a pretty serious probability-processing machine at this point), it just needs some adjustments. I added some giant arrows in the sky for myself in the Unity editor so I actually remember which way is the world's forward direction...
Oh and I modelled some of those "taller barriers" that I mentioned were needed last time.

Gauntlet mode release TODO status:

Bold = currently working on.

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

[ 2016-07-30 22:38:26 CET ] [ Original post ]

This week I fixed some bugs with the Gauntlet mode level generation and I've been testing my level generation out. I looked at two things that I noticed were an issue:

Issue: A need for cover in the early game

In Gauntlet you start with a small and cheap vehicle, and I found that you'd end up shooting a machine-gun turret with a machine-gun and it lacked much room for strategy. You can sneak up to some extent but often you crest a hill or something and you both have line-of-sight and you might as well shoot or get shot. I can beat the levels easily enough but I've been playing Scraps for years - you shouldn't have to take x amount of damage every time. Solution: I'm just going to add some taller barriers around the place basically, so there'll be more opportunities to approach from a strategic angle.

Issue: Searching for that last crate

You want to shoot crates to collect scrap, and if crates might be out in the wilderness somewhere, you're going to want to scour the wilderness to make sure you find them all. I knew that would be a bit of a chore, so I made most things spawn along the road that goes through every Gauntlet level. But it doesn't fix the problem because there's still some chance that things will spawn out in the middle of nowhere, so you end up going looking anyway. And removing that chance entirely would mean no reward ever for exploration, so I wouldn't do that. RPGs have had this problem for a long time. The theory is of course that when there's somewhere out-of-the-way to explore, you get something cool to reward your exploration. And having something there is probably better than exploring and finding nothing. But it also means now you have to explore every boring side-passage because you might miss something cool.
Image credit: Possibly Adrian Chmielarz. Solution: I've added a radar mini-map so you can automatically know there's something out there from a good distance. I don't think I'd add a radar in melee mode/multiplayer because having a radar map would remove a player's ability to surprise the enemy. But in singleplayer I think it'll be fine.
Enemy units and yellow crosses, non-threatening objects that contain scrap are blue squares. Trying to think of the colour-blind in these design choices.  

[ 2016-07-24 08:08:42 CET ] [ Original post ]

The first week after I made the Gauntlet announcement post was a bit of a mess and I didn't have a lot of time for Scraps work. It was getting near time for an update post and I was left wondering what I could make the next one about. What could I do in a couple of days or so? I didn't really want to do another small Gauntlet mode work post because that's all I've been doing for a while. So my decision was, you know what, it's time to take a short break from the new game mode work and put something new in the game, for the players. I looked through my figurative bag of potential parts to add and the Plasmanator came out.

Changelog for v0.5.5.0

- Added Plasmanator weapon - Replaced uLink closed-source version with uLink source code - Reduced network bandwidth use a little

Plasmanator facts

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

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

I wasn't sure how a charged weapon should handle the "R" key aiming mode where weapons only fire if they're aiming inside the circle area. It's just not a great weapon to use in that mode really - and you can of course turn it off. Currently it works the same as any other weapon, which means that the firing state cannot be active for it when it aims outside the circle. Since it charges while "firing", it will charge while inside the circle if you're holding fire, but if it goes outside the circle while being charged it'll fire off a shot since the "firing" state is turning off. I also wasn't sure how the AI should use it. Well, conceptually I was, but algorithmically... well, I wish I could just tell it to "behave like a human." I'd given Dave an assignment to look at it sometime but then I ended up doing it myself today. Basically I told the AI that if it's firing a charged weapon, it should release Fire momentarily to let off a shot IF:

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

What I sometimes find is that in my code I'll go maybe a little overboard trying to find the perfect solution that covers every possible case, whereas Dave will code something super fast that's simple and yet more often than not turns out to work fine. Sometimes it'll need some tweaks and changes later, but usually the fact that it's simple at first means it's also easy to change. I feel like I might have managed a bit of a Dave-style solution here for once where I was worrying about how the AI was going to handle all these complex weapon scenarios, I ended up just adding a few simple rules, and actually it seems to do well enough to fool me that maybe the AI could even be somewhat intelligent. Of course as always if you find any bugs with things, please report them. This video was in my sneak preview update but here it is again. If you want to see something new with it, just load up the game - the Plasmanator is in the game right now! https://www.youtube.com/watch?v=9hKUO4t5y3M P.S. Take note of where your shots hit. If you don't seem to be doing much damage, you may be hitting in front of the enemy instead of directly on them. The bullets drop fairly fast so aiming a little above the target is key.

[ 2016-07-14 10:32:05 CET ] [ Original post ]

Since I’m being slow with the next update post, here’s a sneak preview. https://www.youtube.com/watch?v=9hKUO4t5y3M

[ 2016-07-13 10:45:37 CET ] [ Original post ]

The new singleplayer Scraps game mode I'm working on is called Gauntlet.
You know how games are prone to having some sort of epic conflict you've got to resolve? Yeah well, here that conflict happened, and now it's long over, and it left only ruins behind. Here, we fight over the scraps. And there's one place with the biggest stockpile of scrap of all. And it's well defended. But you're already on the road.

Overview

OK enough cliché. So how will it play? Well, it's sort of a Scraps Roguelike, or more like what's being referred to these days as a Roguelite or (and I realise this is the dumbest term ever) a Roguelike-like. I usually avoid comparing Scraps directly to other games in official posts as it always seems a little sad when someone can only describe their game in terms of other games. But to get a basic idea, take Vlambeer's popular Nuclear Throne for instance. Nuclear throne isn't much like Scraps in terms of how the game actually plays, but imagine the character is your Scraps vehicle, the Rads that you pick up are scrap, the mutations you buy are vehicle parts, and the end-of-level portal is an evac pad at the end of a road, and you might sort of have a picture of what Gauntlet mode is.

Gameplay Breakdown

Everything here is subject to change since a lot of this hasn't actually been tested yet. It has to play well. But the idea is: 1. Player starts with around 3000 scrap to create a basic starter vehicle.
2. They enter a semi-procedurally generated level in World 1. I talked a bit about level gen in preview#7. A piece of a larger map is selected, and the player and evac pad are placed:

Then out of a set of hand-placed content, a subset of that content is selected to use in the level:
(top-down view showing active stuff highlighted in green - you might need to click for full size to see it well) 3. The player traverses the level 4. The player reaches the evac point at the end of a level 5. The can spend scrap they've collected on their vehicle 6. Next level begins... After completing the three levels of World 1, they go onto World 2. If they manage to complete all the levels in all the worlds, they loop back around to World 1, but now they can no longer collect any more Scrap. The goal then will be to destroy as many enemy units as possible before their vehicle is destroyed. Final score will be based on:

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

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

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

ETA

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

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

TODO FOR INITIAL RELEASE

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

TODO LATER

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

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

[ 2016-07-04 01:33:32 CET ] [ Original post ]

Just a small update mostly fixing a couple of issues with the previous release. 2016-6 - 0.5.4.5 - Improved in-game camera collision avoidance - Made damage label colour more obvious Bug Fixes: - Fixed power management bug in previous release - Fixed false cheat flags

[ 2016-06-29 08:12:58 CET ] [ Original post ]

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

Slippery ice.

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

[ 2016-06-27 08:35:24 CET ] [ Original post ]

No special preview this week I'm afraid, but there is a game update. I didn't intend to do an update right at this moment but I've finally, finally fixed a memory leak on the Scraps server that I've been trying to track down for months. I've been looking at it on and off in the evenings so that it didn't impact development on the game, but I've also really wanted to get it fixed. If you ran a game, even a single-player one, for a long time with lots of vehicles being spawned and destroyed, it'd eventually mess up and weird things would start to happen - like all damage would stop registering. It also meant that dedicated servers needed much closer supervision than they should have needed. In the meantime while I've been working on the new game mode I've also been fixing other things, so there are some other bonus changes here as well.

Changelog

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

Info on the bug in the form of a technical description

The Scraps server was slowly using up more and more RAM, until eventually the whole thing would crash with a stack overflow exception. But the stack wasn't the problem - it was the heap. I knew that it was the heap because looking at the Unity profiler, it appeared that all objects were being garbage collected just as they should be, but the thing that grew was Other->ManagedHeap.UsedSize. In other words things on the heap were getting allocated and not deallocated, so the heap had to keep growing when new things were made. Unfortunately in Unity it's impossible to inspect the heap, although it is now possible on platforms that use IL2CPP. Being able to inspect the contents of the heap would have solved this much faster. I fairly quickly worked out that creating and destroying vehicles was the problem, but the profiler reported that everything on the vehicles was successfully destroyed. Yet the leak implied something big was being held onto. There had to be a reference somewhere to something on a vehicle from something outside of the vehicle, that never got freed. My eventual discovery after slowly hacking pieces of Scraps apart was that it was an event subscription to an event on a static class. Scraps parts have a Health class that's a MonoBehaviour, and Health has a non-MonoBehaviour class that acts as a sub-component to do different things depending on whether this is a client or server machine (remember that this leak only happened on the server). When the health script was created, the member class subscribed to a static tick event on a static clock class that the server has. When the health script was destroyed, it run its explosion effects and all that, and also told the member class to unsubscribe from its event... most of the time. The problem was that the Health script's call to the member class wasn't in its OnDestroy, it was in another method that did all the destroying actions for the part and then called Destroy() itself - and that method didn't get called in every situation. Thus sometimes the event never got unsubscribed, and the reference to the member class was held by the static clock class forever, preventing it from being destroyed. Much more was being retained on the heap than just that one class, so my theory is that Unity was managing to remove the vehicle's data on the C# side, but not in the C++ back-end. Thus the profiler would show that every object was destroyed successfully, but in fact the static clock class' reference held onto the non-MonoBehaviour class which in turn was holding onto the whole vehicle part with its memory-consuming mesh and textures. To fix the issue for certain I basically just moved the cleanup code into the OnDestroy of the Health script, guaranteeing that if the script is destroyed, its member class gets cleaned up as well. TL;DR: If your heap is growing forever and you aren't leaking any objects, one thing to look for is events that mightn't be being unsubscribed. And don't think that a GameObject being gone means it's necessarily really gone.

Info on the bug in the form of a story

Guests come to a party at your place and they want to use your dinnerware, but you want to keep track of who's taken some out of the cupboard so when a guest takes a plate, you also get them to tie a rope around their wrist with the other end tied to the cupboard (you're a particularly annoying host). When a guest leaves the party, they'll put back their plate, untie their rope, and leave. But sometimes, due to an oversight in your party planning, guests can leave without returning their plate - with their rope still tied to the cupboard! Later the party is over and it looks like everyone's left, but you find that you can't fully close the door because there are some ropes still tied on to a bunch of people outside. Over time and several parties, you accumulate more and more guests who are still tied on with ropes. You find that you cannot get all guests to return their plates before they leave (as a terrible host I assume you've also attracted terrible quests). But you can fix the problem. You revise your party rules so that instead of guests untying their ropes when they return their plate, they must untie their rope when they leave the party, no matter what. Now your house and yard are properly cleared out every time a party is over. And you buy some new plates I guess.

[ 2016-06-19 05:14:16 CET ] [ Original post ]

For the new singleplayer game mode I need three maps to start off with. You've seen the initial Gorge map:

Desert Map

Now I've started on a desert map. In my mind I have this basic idea of the four classical elements - Earth, Wind, Fire, Water - where the gorge map is Earth and is sort of the starting Green Hill Zone of the thing, and the desert is Fire. Artistically though I was inspired by the real Desert Road here in New Zealand:
Photo credit: Nicolas Leroy. So not a sandy desert, but more of a tussocky one left barren by volcanic activity.
I'm still working on the look of this but here are a couple more shots:

Other Part-Time Work

Something else I want to let you know about in case it affects development times (I do realise I'm not churning out updates fast as it is - I really try, but doing everything yourself always takes a while). I've got some other part-time work starting this week. I've been working on Scraps full-time for years now but it's never made the sort of money one could live off. That's fine, I'm making this game because I've wanted to play it since the 90s and not because I want to be rich, but I'm going to have some other work to do on the side. Please don't let this worry you about Scraps ever being left unfinished. I've been wanting to play this game forever, it's taken longer than I hoped but it's really starting to look like the game I've always wanted, and unless I die suddenly I'll be working on it and it's getting made.

[ 2016-06-12 09:25:54 CET ] [ Original post ]

Super secret new content preview #7/10: "Procedural and hand-crafted" This update is going to end up giving away a bit about the new game mode but that's OK, I'll explain everything at preview #10 and that's not too far off anyway. So, in the new game mode I wanted levels that are a bit different every time. Each one short but always something new. The standard solution to that is to use procedural generation, and have the code create something that's different every time. But procedural can also mean bland, generating the same things with the same rules in different places, and for every game where it works well there's one where it doesn't. I'm taking a sort of a hybrid approach here which with some luck will almost give you the best of both worlds. Here's a complete map for one "world":
That's big - it's over 7km long. But when a level generates it just takes a small chunk of that complete terrain, starting anywhere along it, and putting travel in a forward or reverse direction. I'm still tuning the exact length that'll be, but it's in the region of 1.5 or two kilometres.
Then within that area, things get more complicated. Throughout the whole level the road is your guide.
Spawn on the road, leave on the road. Within the level I can hand-place scenery, walls, turrets, enemy vehicles etc. A lot more stuff than the level will actually need. Then I tell the level generator OK, spawn some stuff in the level for a total of about x amount of scrap, and about 60% of it (or whatever) should be in stuff that attacks you, and the rest should be harmless (like crates). It then looks at all the groups of things and probabilities within the selected section of the map and decides what to spawn. I've set it up so I can pack the entire contents of the level up so instead of having a bajillion things spawned in the world and then deleting most of them (which would waste a bunch of time and RAM), everything in the level is stored only as information about that thing, and then only what's selected is spawned. Everything can be unpacked (basically, spawn everything) so I can edit it, and then packed again for in-game use. In Unity engine terms it basically stores the prefab used, the position and rotation, and then any other custom information that particular thing needs to configure it. But the key feature is that I've also set it up so I can create everything in groups with custom spawn probabilities. Here's an example of one group of things that could be selected to spawn:
This whole thing - the roadblocks, the turret, and the two crates - has a "normal" chance of spawning so it has about as much chance as anything else to be selected. If it's too close to something else that's already selected, or its scrap values don't work out with what the level needs, then it probably won't be chosen. But within the group itself, it can choose different subsets of things to spawn as well. This subset will be chosen as soon as the level generator looks at it, so that it can know exactly what scrap value it'll have.
The roadblocks in the middle are set to always spawn the concrete barriers OR the wooden walls, but but never both. So it'll never actually look like the above in-game. Neither the crates nor the turret are guaranteed to spawn at all, even if the group is chosen - you could get just the roadblocks. But somewhere between zero and all three will be chosen, with one of the crates in this case being a rarer spawn than the other. I could also set it to only spawn one thing out of three, or 1-3, or 0-2 or whatever. And the spawners can be nested so one of the choices could be another spawner with its own mix of guaranteed things and sub-choices. But even as it is there are 16 possible combinations of just that one small set. For AI vehicle spawns, I can now define patrol paths so they can patrol around, or just sit and wait.
Right now most of the code for level generation is done, as is most of the stuff to put in the levels, but I still have a lot of work to do in actually populating levels and in the actual framework of the new game mode. Sometimes it feels like things are progressing at a decent speed, sometimes it doesn't, but rest assured that I'm working on it. See you next weekend.

[ 2016-06-06 08:43:35 CET ] [ Original post ]

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

Part Wreckage

Ever since I started working on the scrap wreckage system for Scraps, I intended there to be two types of drops. When you destroyed parts, you'd be able to collect general wreckage that was like cash you could spend on parts during a game, after using an Evac Pad. That part's in the game now. But there was also meant to be a chance that a whole part would drop when you destroyed one on an enemy. They'd have some amount of damage already applied like say 0-50%. This got left out initially just so I could get the game out a bit sooner, but I wanted it for the new game mode. Some code was there, and I started adding the rest to get it all working. I got as far as having the part wreckage spawn, but not as far as making the interface for you to spend it, before I changed my mind.
My original idea was that if you picked up a part, it'd now be a free part to use on the Build screen (if you used an Evac Pad - if you died you'd lose it like with wreckage scrap). And so you could end up with a conglomerative scrap creation built of all sorts of scavenged parts, and I figured that'd be cool. But I weighed up the pros and cons again as I was restarting work on it, and I came up with: Pros:

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

Cons:

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

Ultimately I'm thinking it's actually a better idea to leave things as-is. If I did do it, I'd certainly make it optional in melee mode (the current game mode). If I really want some special weapon to drop from some special vehicle, it could instead drop a "token" that simply unlocks that special part as available to build normally (i.e. buy it with scrap). Edit: Someone reminded me about selling parts. Selling parts is another complication. If you put a part on your vehicle and then delete it, you get its current value back. But if you can sell salvaged parts for full value then the feature is almost pointless! - the only benefit vs. just getting scrap directly would be that you can't buy damaged parts so maybe you could use something that you couldn't afford new. If you can't sell scavenged parts for their full value, that's gonna be confusing if you're removing things from the vehicle to get scrap back. Not to mention complicating the code. I think this feature was a dumb idea from the start.

[ 2016-05-22 01:57:06 CET ] [ Original post ]

A small taste of things to come. https://youtu.be/gBy166Hnu5Y

[ 2016-05-16 06:07:19 CET ] [ Original post ]

Scraps vehicles so far always ostensibly have a human driver in a cockpit. Even if they're actually controlled by the AI, there's a cockpit that a person can fit in. I wanted some mini vehicles as a sort of starter enemy, more like a ground-based fancier version of the drones I showed earlier. Easy enough to code because they're still vehicles, but different. Instead of a human driver in a cockpit they have a Brain CPU.
It's still a key component of the vehicle so the vehicle is lost if it's destroyed, like with the standard cockpits. I made it a micro chassis to use, that'd be too small for a normal cockpit.
To be clear, the CPU cockpit and micro chassis aren't player usable, at least not with my current plans. They're just for fighting against. Look how cute it is though.

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

[ 2016-05-07 20:44:24 CET ] [ Original post ]

This week I made a flying drone enemy type.
They track you, zip around the place, and are fun to shoot. Initial tests were interesting, almost boids-like:
I found that for the drones I could use a surprising amount of the same code I used for the turrets which was nice. Apart from the actual flying code, a drone is pretty much a turret that moves. And similarly to the turrets I showed last week, they're made of functional parts just like vehicles. Here's a group of them where the one on the right has lost its heat sink and is starting to overheat, and another gets it heat sink shot off:
(sorry for the huge gif! Webm support will get better one day...) I gave the drones some basic AI. I won't claim it's anywhere near as interesting as Dave's vehicle AI but it doesn't need to be in this case. They don't "fake" their flying though, they thrust around with real physics, so of course you can shoot or crash into them to throw them off. Hitting stuff way up in the air is tricky and not really good fun, so I've designed them to hover along close to the ground. You can see the physics at work in this scenario when I first gave them weapons...
Yeah so, standard recoil is a bit much for them. Hence I must confess they are cheating a little now: It was either spend ages writing some smart AI that'd attempt to counter weapon recoil while flying somehow, or just let them have less recoil on their guns. I hate it when AI gets to cheat (vehicle AI never cheats by the way, it only sees what it can actually see and collects only scrap that it really collects) but the pragmatic choice here was obvious. So the drones you see elsewhere in this post are using specially engineered reduced-recoil MMGs. See you next week. Edit: I just decided to see if I could

[ 2016-05-01 06:09:34 CET ] [ Original post ]

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

I've also written some simple AI for them. Note that generator and those heat-sinks: They also have inter-dependent functional parts like vehicles. Here's a demo video of everything where I explain what's going on: https://www.youtube.com/watch?v=vWePrtx9OzE

[ 2016-04-24 04:43:00 CET ] [ Original post ]

[ 2016-04-24 04:38:47 CET ] [ Original post ]

Not the vehicle kind unfortunately. Every now and then recently I've been getting automated error reports of a stack overflow exception in Scraps. But no-one's actually reported a problem to me directly, everything seems to be working perfectly for me (and clearly most others), and the error report doesn't come with any additional information. So just putting out a general plea, if your game crashes or does anything weird, please do let me know and send me your output_log as described on the website Contact page.

[ 2016-03-30 20:42:53 CET ] [ Original post ]

I just wanted to do a small fix-up update today to tidy some things up: 2016-3 - 0.5.4.2 - Some performance improvements, mainly on CPU (the previous terrain graphics upgrade made CPU performance worse) - Added some grungy texture to scene objects in general - No more lag spike (one-frame FPS drop) the first time wreckage spawns - Added a little help dialog thing when first playing a game to point out adding AI players - Added hover tooltips to the server list that show the full game name, in case it doesn't fit Bug Fixes: - Got rid of grass growing through evac pads on the test map - Missing button click sounds added to lobby screen - Fixed AI info in the server list going away after 30 mins when the lobby refreshed By the way, I'm also aware that running the game in DirectX 9 mode (if you don't have a DirectX 11 compatible graphics card) at the moment causes some issues with how the terrain looks. I'm looking into it.

[ 2016-03-29 08:31:42 CET ] [ Original post ]

- Main Menu layout changes - AI players now show in the server info - If an AI player gets kicked from a game by a human player joining with no free slots, when a slot is free again they'll now come back... for revenge Bug Fixes: - Fixed rotation range calc bug - Fixed "aim sphere" rotation range visual bug - Fixed null reference exception that occurred on dedicated servers in no-GUI mode with the new terrain - Fixed music player playing the wrong track if the track was changed and then changed back to the original track while the original track was still fading out The main menu looks different, but it's actually the same functionally. The main aim is just to sort of encourage starting games that other people can join, but it also makes room for introducing a new game mode later. Equivalents: Playing single-player: Old: Singleplayer New: Play->Start A Game, have "Allow other players to join" unticked. Joining an Internet game: Old: Multiplayer->Internet->Join A Game New: Play->Join A Game Joining a LAN game: Old: Multiplayer->LAN->Join A Game New: Play->Join A Game, select the LAN tab Hosting an Internet game: Old: Multiplayer->Internet->Host A Game New: Play->Start A Game, have "Allow other players to join" ticked, and set to Internet Joining a LAN game: Old: Multiplayer->LAN->Host A Game New: Play->Start A Game, have "Allow other players to join" ticked, and set to LAN "Allow other players to join" is ticked by default, but it remembers what you last set, so if you always play Singleplayer for instance it'll stay unticked once you've set it that way.

[ 2016-03-19 04:55:09 CET ] [ Original post ]

The latest Scraps update adds a little air control, a save format upgrade, tweaked weapon hit forces, and a terrain graphics upgrade. Full changelog: 2016-3 - 0.5.4.0 - Terrain graphics upgrade. But no more switching to greyscale terrain when in low grav mode I'm afraid - Magically, vehicle save files are now also PNG image screenshots of the vehicle itself - Separated weapon recoil and hit force, so they don't have to be the same anymore. Reduced hit forces in general - should help with Medium Cannon spam in particular - Rewrote the weapon movement range calculation AGAIN. More bugs fixed with it. Hopefully very correct and consistent now - Added a little air control: Pitch = Throttle forward/back. Roll = Throttle + Steering. More engine power gives more control - Finally the test map side road is actually 100% flat, right up to the ramp - Updated uLink and Steamworks.NET to their latest versions - Added grass density graphics option Bug Fixes: - Tooltips now update their text to match language changes without requiring a restart - Fixed mass from held wreckage not being subtracted after wreckage was offloaded on evac - Stopped evac pad ambient sound from playing when the pad is turned off (Test map)

Air control

I showed this off in the last update, but now it's live. You can control your pitch with throttle and your roll with turning. You can't control yaw - it's a car, not a plane OK? Practising in Low Gravity mode is a nice way to get the hang of it.

Recoil

Weapon recoil and hit forces used to always be the same, which was arguably more realistic, but it meant that if I wanted a big kick on a weapon it also had to have a big hit. Often because of hit angles and multiple shots hitting in one spot, the hits would end up even worse than the recoil. I've changed it so that I can set them separately, and reduced some hit forces. Hopefully there's less of a problem with Medium Cannons and Plasma in particular throwing vehicles around now. Of course you can still push your enemies around to some extent.

Save Format

Those are actual save files. When you save vehicles now they'll end up in a new format, which is also a png image - so now it's easier to see what a vehicle is if you're sharing it around. The easiest way to see your vehicle saves is probably to open the Save/Load dialog in the game and click the button at the top right which takes you straight there. Hosting these on an image host will most likely break them - you can try, but you're probably better off using a file host of some sort. Anything that won't try to modify or re-encode the image file. Dev note: There are several ways to do something like this. Gimbal has awesome image saves, as does the Spore creature creator. One potential method is to use the image's metadata fields to add your custom data, although sometimes those have size limits. Another method is to use something in the image itself that's invisible or hard to see, like something in the alpha channel or the least significant bits. Or even just extend the image to have the data encoded in an extra part of it, using all the available colour data. However, I've done this with the dumbest and simplest method possible: Just dumping all the save data at the end of the file! It was one of the options I've read about so it's not totally unheard of. Sure image hosts will probably break it but all those other methods get broken by image hosts anyway. Seems like as long as you still end the png part of the file properly (works for JPEG too!), every PNG reader that I've come across reads the files with no problem. Scraps just ignores the image part and looks for my special marker, then starts reading the save from there.

Graphics

Scraps' terrain graphics have always been pretty meh, and I wanted to get a better system for new stuff, so I've also back-ported that to the existing maps.

 
What's actually better? Well, there's nice perlin shadowing on things (how much there is varies with the terrain texture):
Although I had to get rid of the black outline FX on terrain. Bumpy stuff is... bumpier:
And you can see there that the grass is better too, not just denser. The default Unity grass shader is a simple cutout thing: It takes a texture and says OK, if the alpha value is above whatever, I'll show that pixel, otherwise I won't show it. That gives really crisp but jagged looking grass. It also means that when the terrain engine tries to fade out distant grass, instead of getting semi-transparent grass you get grass that sort of gets cut down more and more at the edges. I did a literally one-minute edit to the grass shader to make it do "proper" transparency, and the difference is huge!
I don't think Unity has updated their grass shader for a long time. There's a comment about Mac OS 10.4 in there. I was sure I must've killed performance as a tradeoff, but if anything the grass performance seems to be slightly better. Here's my replacement WavingGrass.shader and WavingGrassBillboard.shader if any Unity devs want them, it's like jumping from 2002 to 2012 in one fell swoop. There's also now texture blending based on heightmaps:
What's happening above is, when there's a mixture of two different terrain textures, it used to just blend, but now it'll show the higher parts of the texture first (based on a greyscale height map I supply it), so the new texture sort if "raises up" out of the other one as it increases in opacity. For Unity devs, most of these new features come from using Tomasz Stobierski's Relief Terrain Pack (it's not exactly drop-in-and-your-terrain-looks-amazing, but it is very good once you bend it to your will). I also wrote some custom terrain editing tools of my own to let me make stuff faster:
The heightmaps and splatmaps (texture layout) used there are pre-created - my tools aren't that amazing - but it automates a whole bunch of stuff that was previously tedious. It also means I can edit heightmaps and splats and basically just click to update. Without much more work a terrain like the one above starts looking pretty good:
Still working on a new single-player mode.  

[ 2016-03-15 04:44:33 CET ] [ Original post ]

The last couple of weeks of dev have been a bit frustrating. I came up against an engine feature that I wanted which - my mistake - I had thought was in Unity 4 but was actually only introduced in Unity 5. Scraps has been halfway converted to Unity 5 for a while so I did a bit more on that conversion, tested the stuff I needed, and realised it still wasn't going to work anyway. Not a real loss of time because I'll most likely need to move the game from Unity 4 to 5 eventually anyway, but annoying because I want to get new content out as much as the next person. I can actually show some work on content rather than code for once though. You may have seen the new pile of crates and barrels on the Test Map in the last update:
In the editor the crates look like the left image, but when the game is run they take on some random colour variation to look a little more interesting. Giving them all different Materials with different tints would blow out the amount of draw calls in the scene, so instead they all share the same Material, and the tint colour is set via the vertex colour on the mesh itself. Pretty simple code: void SetTint(Mesh mesh) { // Tint is set via mesh vertex data rather than in the shader properties, // so that we can still use the same shared single material instance on everything! byte colour255 = (byte)(Random.value * 255); Color32[] colors = mesh.colors32; for (int j = 0; j < colors.Length; j++) { colors[j].b = colour255; // Setting the blue channel } mesh.colors32 = colors; } The meshes are simple so running through the array is super fast - but it only runs once on level load anyway. Then in the surface shader I use the blue vertex's blue colour channel value to do whatever - it's really just a way of getting information from the game to the shader. // Any extra tint stored in BLUE channel // fmod is % (mod). Using it to map all possible RGB values float4 tint = 0.7 + float4(IN.color.b, fmod(IN.color.b * 2, 1), fmod(IN.color.b * 4, 1), 1) * 0.3; if (IN.color.b > 0) { c.rgb *= tint; } You may wonder why I set just the blue channel and then calculate a colour tint based on that rather than setting the whole vertex colour RGB and setting the tint to that value. The reason is that a lot of things in Scraps are actually done this way - heat effects on vehicle parts, damage texturing on everything, and how shiny vehicle parts are (specularity) are all specified by modifying the different colour channels in the mesh vertex data, so that each vehicle can be shown with one Material and the environment can be drawn with another. So I need the red and green channels for other things. Otherwise every time something got damaged or heated up, it'd have to use its own Material and have its own draw calls, making graphics performance a lot worse.
I also made these barrels. The red one explodes of course. I wrote a generic script that I can attach to any world object to make it explode when destroyed and damage surrounding stuff.
Driving a vehicle by ScrapsEnthusiast there. Yesterday I also added subtle air control to the game, so that'll be in the next update. It's tuned more for gameplay than being realistic, but you can at least pretend it's created from the torque of the wheels spinning in the air.
And I made some light beam/forcefield-style walls that I can use to create more subtle level borders for some levels. Functionally they work the same as the current walls.
For the next game mode I need lots of terrain, so I've been improving my terrain creation workflow. I can now take a basic low-detail terrain and put it through my Scraps-specific World Machine setup to get out a terrain fairly quickly with erosion and varied texturing.
OK, the bottom one still doesn't look amazing yet, but that's without any grass, fog, sky, etc etc. It's a lot better than the top one considering the minimal manual effort involved. One thing that's not obvious in the screenshot is that the "after" terrains also have more fine detail - so I can map out a fairly low-res base terrain and then run erosion on it to make it into a more fully detailed one.

[ 2016-02-23 22:12:13 CET ] [ Original post ]

Today's Scraps update doesn't change anything exactly, but the install size of the game is now almost half what it was! Basically there was a lot of duplication between the main game and server components. This was OK when the game was very small anyway, but it's been getting steadily bigger, so I've refactored things so there's no separate server app at all anymore. Now a server is just the main game with a server flag passed in, and all the duplication is gone. You can still host a game and play on it at the same time.

[ 2016-02-03 23:11:19 CET ] [ Original post ]

The latest Scraps release is again focused on fixing bugs and generally making the core game better. In the background I've also been working on the new Singleplayer mode, but that's not ready to show off just yet. 0.5.3.0 - More efficient shader/material usage for environmental stuff - Bigger shockwaves move faster (just looks better) - Some new destruction FX - Fixed some lightmapping glitches and improved some normal maps on terrain - Added some new stuff on the test map that I've been creating for the upcoming singleplayer game mode - Using the lowpassed music track in the lobby instead of the full one, it's more chill - Added an additional vertical adapter block Bug Fixes: - Fixed multiple issues where games could get stuck at Dropship In Transit when starting games. Please let me know if this happens to you after this update - Fixed AI sometimes being lazy and just hanging out until being destroyed for the first time, causing it to henceforth spring into life - Fixed game start failing if scrap limit was changed lower, then deploy clicked right away, causing the limit to lower and make a vehicle selection invalid - Fixed some incorrect cube weights on the Test Map - Fixed shockwaves sometimes not showing up when they should Two Dropship In Transit bugs - one that happened on going from menu to lobby, and the other while going from lobby to game - were horrible timing bugs that only occurred when the stars were aligned just right. The issues I found are definitely fixed now, but please let me know if you still get stuck at a loading screen in the future. Of course, report any bugs you find - I do try to fix things!

[ 2016-01-31 08:50:16 CET ] [ Original post ]

It's been a bit longer than usual since the last Scraps update, so I just want to give some reassurance that I'm still working hard on things. There was a little time off over Christmas and New Years, but recently I'm working on something that I've alluded to a little in the past: A major new single-player game mode. My thoughts are that it should help a lot to flesh out the game content whether or not Internet multiplayer numbers pick up. I won't go into details of how it'll play just yet because I'm still testing things out myself, but I will in the near future. I think it'll be a lot of fun. The new mode is pretty major, and is going to take several months to finish completely. I'll attempt to get some stuff out to try earlier, but I'll also keep doing some smaller game updates in the meantime regardless. The next game update will be next weekend but it'll be mostly bug fixes and minor improvements. Still, things are happening, and I'll have more to show soon.

[ 2016-01-24 07:42:02 CET ] [ Original post ]

This update is mainly lots of bug fixing and code cleanup behind the scenes. I also did a smaller v0.5.2.14 update that I didn't make an update post for earlier, which improved CPU performance. The specifics: 2015-12 - 0.5.2.15 - Added heavy armour part - Better support for XBox 360 controller on Mac and Linux. Separate default key bindings keep actual inputs the same on all platforms - Engine sounds with multiple of the same engine work together better - Removed an annoying ridge in the RiverRift terrain - Added some subtle fades between scenes Bug Fixes: - Fixed occasionally coming back from testing vehicles to the build screen and your vehicle has flown off into space somewhere - Removed more false positives and not-really-bad words from the swear filter - "Open save folder" button now working on Linux - Fixed the loading screen getting stuck if your vehicle spawned in right as a round ended - Fixed visual glitch between light beams and edge wall glass - Fixed screen staying white if your vehicle was destroyed right at the moment of evac completion - Fixed game modifiers (low gravity) not being unapplied on connected clients if the server shut down - Fixed SkinnedMeshRenderer errors being generated in-game (in the background) if a vehicle had no moving parts - Lots of refactoring and fixing issues with chassis, propulsion systems and their hit points and other values - Tooltips for chassis select now include the extra HP gained from the wheels (so they show the actual full chassis HP now) 2015-12 - 0.5.2.14 - CPU performance improvements due to physics and rendering optimisation work - Tweaks to the RiverRift map layout - Swedish translation update Have a good Christmas everyone. I won't be able to join the Weekly Game tomorrow. Thanks everyone who reported bugs that are fixed here.

[ 2015-12-19 10:01:05 CET ] [ Original post ]