This game has been Greenlit by the Community!

The community has shown their interest in this game. Valve has reached out to this developer to start moving things toward release on Steam.

October 11 - Nition

What's been going on in the two weeks since the DigitalNationz expo? Let's take a trip to the World Of Yesterday...

I've got some PAX prep to do that isn't coding stuff. Preparing booth content, contacting press etc. The PAX booth has a big double-banner - two tall banners right next to each other. I made some art for them:


Not as cool as Swordy[]'s awesome fiery banners, but my design skills have their limits. I hacked in a system to take a super high res game screenshot for the vehicles.

I also seem to be amassing various Scraps stuff:

I'm working on some tweaks and improvements to the multiplayer based on feedback from DigitalNationz a couple of weeks ago, but I also spent some time on the beginnings of an AI for single-player.

I've actually got someone who's probably going to do the AI work for Scraps. That's right, I might be hiring someone else to do something for once! It's a guy I know locally who I know is an excellent developer.

I set up a rudimentary AI system so he could get a feel for it and how hard it might be to do. My example AI drove around randomly and fired its guns. Not exactly super intelligent:

As of yesterday we already have AI that finds a path to their target using a navmash and drives towards it, and what I think is particularly cool is that even though it's still super basic, it can already be a lot of fun. Here I am messing around with the simple AI:

The current AI is also completely fearless and never stops driving full-speed towards the enemy for anything.

When Scraps is ready for an Early Access release early next year, it'll have some AI in it for single-player gaming. A much smarter AI than you see above.

September 14 - Nition

On Sunday I did some proper LAN play testing. The basic game mechanics are all working and synchronising nicely over the network. I've now got a whole lot of notes on minor bugs and issues, and game mechanics that need to be tweaked, but none of it is serious stuff. No crashes, no major synchronisation issues, no terrible problems with the game mechanics, and my playtesters didn't want to stop playing which has to be a good sign.

The game's still a ways from being publicly testable because I've got to set everything up in just the right way - player's can't join after a game starts yet, and they can't quit either. Cleaning up properly after people quit should be easy enough but correctly synchronising everything when people join mid-way through a game will be more difficult, mainly due to how players can transition between different states in the game as they're playing (in-game, evac in progress, build screen after evac, waiting for respawn...). That's not necessarily needed in time for demoing at events like PAX though.

I did a quick 1v1 playtest on Saturday and as I suspected, the DustBowl map was way too big for games with few players, so I threw together a sort of mini version in literally about an hour:

"SmallMap." It's sort of a figure 8 with a plain untextured bridge in the middle. This is not a map that'll be in the game, but something similar might be, just without being a blatant copy of the DustBowl map.

On Sunday I had a couple of people over to play a three-player game. The map actually played well apart from some awkward terrain around the bridge area. And here's some video of it!

Yes, I'm still using a 4:3 monitor. And a trackball mouse.

August 31 - Nition

I'll be bringing an early multiplayer build of Scraps to PAX Australia[] in Melbourne, and it'll be the only place to play multiplayer for a while. I've made a thread on the forum[], and if you're coming to PAX and you post your vehicle file in this thread before October 24th, I'll take it along with me. So if you're building stuff now, I can have it there for you to battle with on the day. More details over in the thread.

To facilitate that, and since the game's in a fairly stable place right now, I've also updated the Builder Demo[]. Obviously it's been a while since last time. Changes include damage with damage effects, wreckage, and some new block parts.

Changelog for
- Damage and damage effects
- Area effect + visible shockwave for projectile weapons
- Wreckage (collectable)
- Added undo (Ctrl-Z) on the Build screen
- Added new half-block and slope block parts
- Available weapon rotation range updates automatically when parts are destroyed in-game
- Vehicles now have a size limit of 20m in any direction from the centre of the chassis (so max 40m wide etc). This is a safety measure to ensure that vehicles won't overlap each other, for example when spawning at different spawn points. Existing vehicles that are larger will be truncated when loaded.
- Lowpass filter on the music while using some sub-screens
- Unified object pooling system for improved performance. Things like explosions are now pooled and re-used instead of always instantiated
- Tweaked some part stats
- More sound effects
- Updated part drop effect on the Build screen
- Entries in the language list are now always in that language
Bug Fixes:
- Fixed another aiming bug
- Various other fixes

There's a sort-of-bug where the chassis options on the build screen can take a while to appear the first time the game's run. This has been happening since I upgraded Unity (the game's base engine) past 4.2, and I absolutely can't work out what's causing the delay. Unity reports that everything is loaded and fine, but it seems to just really feel like hiding it for a while. Anyway, it's not a big deal so I'll look at it again in the future.

Over the last fortnight I've mainly been working on various components of multiplayer, but I also cleaned up the vehicle testing mode so that it works well with the new damage systems. I was hoping to get the respawning system working but ended up having to fix up a bunch of other stuff, plus one of my hard drives died - the one with Scraps on it - and that lost me about a day of work coming back from the last backup. So that was a bit annoying, but I'm still basically on-track with where I want to be for PAX.

This week I also want to share a little thing I wrote up that represents where I'd like Scraps to go eventually. This is somewhat representative of the vision I have (and have always had) in my head. One thing I like about Scraps is that it can be as much based around clever choice of different functional parts all working together as it can be about creative designs. I hope this sort of gives an idea of that too:

The Glass Cannon (a hypothetical Scraps combat scenario)

The “glass cannon” is a small and fast wheeled vehicle with an oversized energy weapon. To keep its speed up and cost down, it doesn't have enough power to use its weapon more than once or twice in a row before needing to wait and recharge. It has little traditional armour but maintains a small energy shield. For power, it uses a cheap reactor core that can be pushed above 100% - if the user's vehicle can keep it cool. The GC (glass cannon) only has a small heatsink, so it can't really do this. It mostly keeps the reactor on around 80% power.

The GC's driver wants to take out a large, powerful and slow target. If the large target gets a good shot in, it might be able to take out the GC in one hit – especially if the GC's shields are down.

The GC's driver flanks the target, hidden behind some hills. Moments before cresting the hill to meet the target, the driver shuts off the shields and pushes the reactor to maximum, now rapidly dumping excess energy into the capacitors. The heatsink is now glowing red hot and overheat warnings are starting to appear on-screen.

One shot, and the large target's shields are down. With its own shields off and the reactor on maximum, the GC's energy store is rapidly filling up again, almost ready for another shot. Meanwhile the large target is swivelling its cannons around to meet this small and vulnerable target, and the GC's reactor is overheating. But the GC's weapon is powerful, and it'll only take one more successful shot to bring this one down...

August 15 - Nition

It's going to be interesting when everything comes together and I can start seeing how full games of Scraps actually play out. The current intended structure of the melee mode is like this:

  • Pre-game Lobby: Starting scrap is set (plus the other game options) and everyone chooses a vehicle that fits within that price range. If they have scrap left over, they'll keep it banked for later.

  • Game starts and everyone is dropped off at spawn points on the map.

  • You can collect wreckage from destroyed parts if you've got a container on your vehicle.

  • If your vehicle is damaged, you can attempt to reach an Evac Pad. I'll make sure that all chassis provide a little bit of engine power and a little bit of generator power on their own, so you'll never be completely stranded.

  • After evac, you'll be safe back at the build screen. If you've got scrap to spend - either left over from your starting allowance or scavenged from wreckage on the map - you can repair your vehicle, add new parts, or remove existing ones. I also plan to add a system for collecting whole parts. Above on the right, you can see the new Repair Mode - more on that later.

  • Whenever you're done, you can get dropped off back in the game.
  • If your cockpit or chassis is destroyed, it's more like a traditional kill in an FPS game. You'll respawn with a new vehicle and your death will be recorded in the stats. Any scrap or parts you collected, or changes to your previous vehicle will be lost.
    The remains of your previous vehicle will have dropped on the map as wreckage, but I think I need to ban your new vehicle from picking those up. Otherwise you could build up a stockpile by blowing up on purpose and quickly reclaiming your previous wreckage with your new vehicle! Suggestions for game behaviour here are welcome, because maybe there's a good way to handle things that I haven't thought of yet.
This fortnight I've mainly been working on the Game -> Evac -> Build screen and Build -> Game progression, and the stuff you can do on the Build screen while you're there.

Getting it all working required a bit of a shake up of the current code because the in-game build screen has to run alongside the game map with everything still going on in the background. The other option would be that when you returned to the game, you'd reload the map and re-synchronise with the server, picking up the changes to everyone's vehicles, wreckage on the map etc etc since you were last there, all at once. I decided that the better option was to just keep running the game map in the background. Looking at other multiplayer games I own, that seems to be the usual solution. Team Fortress 2 is clearly just loading the character select screens etc on top of the game itself, as is Battlefield: Bad Company 2.

That took a bit of refactoring but things are just about working nicely now, with a few bugs remaining. I also got vehicle modification on the build screen working in multiplayer, so parts can be added and removed and it'll sync over the network, and there's a new Repair Mode.

Damaged vehicle at the top, Repair Mode at the bottom. Repair mode makes it easier to see how damaged each part is with colour-coding, and also changes interaction so clicking on parts repairs them (if you can afford it) instead of picking them up. There's now also a Repair All button (not shown).

I've still got some things to fix up in this area, then I'll be getting respawning working. You should probably be able to select a different vehicle to spawn with as well, as long as it fits within the game's starting scrap amount.

Bonus screenshot:

August 2 - Nition

This update goes into a bit more technical detail than usual. I like that sort of thing in game blogs, but feel free to skip that stuff.

Since I'll be taking scraps across the Tasman to PAX Australia at the end of October, I've worked out a roadmap of what exactly I need to have done by then. Without going down to task-level detail, it's basically have LAN multiplayer working nicely, plus some testing and balancing of the game, plus some marketing and other preparation work like refreshing the website a little and getting the booth ready. There's a little under three months to go.

Ideally I'd like to also have some basic single-player stuff to do at PAX - simple AI vehicles to shoot at or even just some towers etc that fire at you - but time is looking at bit tight for that. "Finish LAN multiplayer" might not seem like a big task considering that the basics of it are already in and working, but it's a bit like the coastline of Britain paradox[]. Once you break it down into individual tasks, suddenly it's twice as long.

My current plan is to take two laptops (which I already have arranged) and people can build and play 1v1 against each other. One of us manning the booth can play with them if it's only one person. If two people are on but one person is busy building, the other can mess around with building and testing as well until they're ready (it's fun enough playing with the builder demo, so I feel like doing that for a little while won't be too bad).

Right now I've been working on getting the Evac Pads working. The process will go like this:

  1. Collect some scrap in the game (or you've got funds left over because you're playing e.g. a 10,000 limit game with a 9,000 scrap vehicle)
  2. Enter an evac pad and wait for the countdown.
  3. Actual evac starts.
  4. Evac finished and you're transported to the Build screen. Your collected scrap is banked. That is, it's moved out of your vehicle's containers and into your "bank."
  5. Repair damaged parts or add new ones using your banked scrap (you may also be able to pick up whole parts to use).
  6. Re-deploy into the game when you're ready, and you'll appear at a spawn point. Unspent scrap stays in your bank and your containers are now empty again.
The server needs to control most of this just to be safe in case of attempted client hacks, but it'd suck to have bad latency and be trying to build a vehicle, always waiting for the server to confirm that you can afford a change. That's why I've implemented an...

Undo System

With a working Undo system for vehicle building, you can make a change to your vehicle right away. The server should usually always approve it, but if something got out of sync somehow or the client's cheating, the server can deny the change and tell the client to revert what they did, putting things back in sync. Of course, a hacked client could ignore the undo command from the server as well - but the vehicle would still only be wrong on their machine, and the server gets the final say on most things.

The other reason for putting in an Undo system is that players can use it too! This is pretty self-explanatory but here's a video (normal building section sped up):

It can also undo suspension settings. :)

People always seem to talk about Undo support as being something you have to plan for from the start, or it'll be a nightmare to implement. I was pleasantly surprised that I managed to implement it in a morning, and clean it up and complete it in an afternoon. As is common, my internal implementation is based on the Command[] design pattern. Basically each time you do something, you also remember how to do it backwards. Then if you need to undo, you just go backwards through the list of things you've done.

Area Effect Damage

My early just-get-it-working implementation of area effect damage was a simple thing like this:
  • Get where the projectile hit
  • Take a sphere of x radius around that point and get all the objects in that area
  • Apply between 0 and 100% of the explosion damage to each, based on how far the object is from the centre
Easy to implement and at first glance maybe looks like it'll work, but it doesn't take obstructions into account. Imagine your vehicle has thick armour for instance - the armour should protect the parts underneath!

A possible solution to this:
  • Get where the projectile hit
  • Cast a bunch of rays out from that point (like a koosh ball[]) to the edge of the sphere, and get everything they hit
  • Apply between 0 and 100% of the explosion damage to each, based on how far the object is from the centre
Things in front will now block things behind from getting hit. That's cool, but you're always going to have a tradeoff: More rays and you'll hurt performance, but less rays and you might miss small stuff. An alternative:
  • Get where the projectile hit
  • Take a sphere of x radius around that point and get all the objects in that area
  • Cast a ray from the centre towards each of those objects
  • If the ray hits the object, include it. If it hits something else, ignore it
  • Apply between 0 and 100% of the explosion damage to each, based on how far the object is from the centre
That way you make sure you include every object, don't cast many rays, and it's generally a bit faster. It still kinda sucks. Imagine something like this (terrible diagram alert):

[For a projectile doing up to 100 damage and affecting the yellow area.]

Something like a flat wall sucks because objects get blocked from the explosion more than they should. There's also the matter of whether you cast your rays towards the closest point on an object or towards its centre, but that's not so important.

My actual current solution is more like this:

First, I cast the original rays from slightly behind the actual hit point (based on the direction the projectile came from), which helps for a start. Then, for any objects that were blocked, I try again from further away - specifically from the edge of the area. It wouldn't be a good idea to do just the second check because you never know what obstructions might be in the way.

This system might need some more refinement in the future, but it seems pretty good.

Strangely I didn't really find existing info about this. Surely thousands of people have done area effect damage before. Anyway, that's partly why I thought I'd write it up a bit more thoroughly than usual here.

Damage Effects

I also added damage FX.

Everything with a health stat gets the "grunge" effect - the increasing black marks as health goes down. Additionally, some parts get custom effects.

Right now, engines smoke and flame, generators spark and smoke, and capacitors spark. All these FX vary depending on how damaged the part is.

One more thing: Some of this stuff would be cool to add to the builder demo, but I need to focus on making the game awesome for PAX at the moment. Putting out a builder demo update will take a few days of testing, fixing up and checking everything. You're not missing out on anything really game-changing, but I will put some of this stuff into the demo when I've got some more time.

< 1  2  3  4  5 >
Showing 1-5 of 22 entries