Games Scraps: Modular Vehicle Combat - Vehicle combat with buildable vehicles

This looks good. Cant wait for it to be finished

 

This may be a bug.

 

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 0.2.11.0:
- 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 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...

 

That scenario sounds like a lot of fun!

Time to play with new builder

 

Just a quick note: If you have an issue with the previous builder demo release where some of your vehicle parts are solid black, I've fixed it in the current download.

 

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.

 

A couple of people have reported vehicles getting all floaty-feeling after losing a lot of mass in parts. This was pretty confusing to pin down because all my vehicle stats seemed to be correct. Like, I build a vehicle which starts off the same as a floaty vehicle ends up after taking the damage - so it's a duplicate of the post-damage vehicle. Centre of mass seems to match. Suspension values match. Weight matches. Anti-roll matches. But they clearly behave very differently.

I've just worked out that it's some sort of issue with changing mass on vehicles with wheel colliders: http://forum.unity3d.com/threads/or...f-mass-affect-wheel-collider-behaviour.269657
I'm still trying to work out a way to "reset" the system so the wheel colliders will behave like they should if the updated values were the initial values.

 

Fixed the floaty vehicles issue, and a few other issues, plus added a Russian translation. As always, you can just delete your old installation folder and replace it with the new download. Vehicle saves and settings are stored in a different location and will be saved.

Scraps is also going to be at DIGITAL NATIONZ in Auckland, New Zealand again this year. It’s this coming weekend (the 27th and 28th), and although I only got final confirmation that I was accepted last week, yes you will be able to play multiplayer. As with PAX, I’ll have two laptops for 1v1 matches.

Changelog:
2014-09 – 0.2.12.0
– Added Russian translation (I still haven’t sorted out text cutoff issues etc in translation files – will do eventually)
– New game logo. Removed the old background which didn’t match well
– Test map cubes are a bit harder to destroy
– Game now checks for invalid part placement when vehicles load
Bug Fixes:
– Fixed doubled-up “would you like to save?” message
– Fixed the game not recognising the cockpit being destroyed if it was destroyed as part of a stack rather than directly
– Fixed stragely floaty vehicle behaviour after losing a large amount of mass. Unity bug: http://bit.ly/1uTfX9X
– Fixed some issues with allowable part placement and wheel suspension (invalid vehicles will get parts removed when loaded)
– Fixed an issue on Mac where using an anti-aliasing type other than MSAA would cause the Unity resolution offset bug: http://bit.ly/RxZLfx

Who knows what’s going on internally in the Unity engine to cause the correlation in that last one.

 

Like the new logo

 

Thanks. The old one I did myself, but I had some help with this one.

 

The vehicle builder is way too addicting.

 

I took Scraps to Digital Nationz in Auckland NZ all day on Saturday. Set up two laptops with 1v1 mutliplayer.

It was good times. I have lots more notes from seeing people play plus some suggestions. Good to have something proper for people to play, and some people stayed and played for quite a while which was good to see.

For PAX I'm going to try and source another laptop. 1v1 is okay but often someone is building a vehicle and the other person is stuck waiting, which isn't so great. Four laptops would be even better, but I don't think I even have that much booth space.

Dev work continues - in the last week I've been mostly bug fixing and getting through the rest of my list of minor changes from the last lot of playtesting. Now I've got three more pages of notes, but it's all good stuff (meaning it's things like "repair mode should allow..." rather than "game crashes if...").

 

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.

 

Not much time for a big update today. Scraps will be at PAX Australia in Melbourne this time next week with playable multiplayer. And here's a video of the in-progress AI fighting amongst themselves:

They don't know how to repair yet, they always fight to the death.

 

Awesome work with the latest updates, keep on cracking away at it!

 

Thanks! I appreciate the support, it's been a long journey (and one that's not over just yet).

 

looks like a really fun game!

 

Scraps PAX review here: http://www.scrapsgame.com/scraps-pax-australia-2014

 

Shame you couldn't save the banners - those are wall-worthy!

Nice point about the swag to social media phenomenon - maybe you should have taken pieces of scrap metal and had the Scraps logo stamped through them!

 

That's a good idea!

 

Hi,

was nice to meet you. Unfortunately had to dash off so didn't have a chance to chat.

Multiplayer was great fun. Interesting playing against different players (and bots for that matter), can imagine it was pretty rewarding to analyse different strategies in action. Hope you were able to collate useful data!

 

Yeah, events are always great for usability testing and seeing how people play as well as just getting exposure.

 

Recently I've been finally adding some new parts that are needed for the full version. Remember this diagram from the Kickstarter?



I'm filling in the ???. I'm considering the minimum remaining parts needed before the initial early access release of Scraps to be the following:

• 1x Passive cooling part
  
• 1x Active cooling part (drains power to provide more cooling)
  
• 1x Energy weapon
  
• 1x Laser weapon
  
• 2x Special Kickstarter backer weapons

I've coded the heat and cooling systems and added the cooling parts already. Two passive heat sinks (they're easy to make) and a small active cooling unit:



When your weapons generate heat, they try to pass that heat off to any cooling parts you have. If your cooling system reaches max heat, the weapons will start taking the heat themselves. If their heat gets too high, they'll start taking damage. I think having overheating parts taking damage will be more fun than just saying "it's too hot - you can't shoot now." You can push it to the limit!

It's visual too. I made a mistake while coding the heat system that generated way too much heat - it made a good demo of the heat effect!



I've also been making the necessary weapons. I made a plasma artillery energy weapon:




The bullet drops pretty fast so it shoots in more of an arc, but it has a wide area of effect.

I'm also working on a laser weapon, but the 3D model isn't finished. It kinda works though (plasma shown here too):

Now, this all means switching the standard gunpower weapons to mostly require cooling instead of power (they do still need a little bit of power). This was always the intention, but it's been a while coming, so I know what you're saying: "I'll have to change all my existing vehicles to use cooling instead of power?" Yeah, I'm afraid you will. That's why I'm adding this stuff before the full paid release. Please remember this game is still pre-alpha right now. I feel I should take a bit of time to update the builder demo though so at least it matches the new systems. I need to get everything into a nice stable state but I should have that up at the next update in a couple of weeks.

In terms of an overall timeline of what's left to do before the first full release, it's actually still quite a lot. I recently estimated out everything that's left and it came out to finishing in...May. That's looking further than I'd like and I'm sure it's further than you'd like, but I really want to make sure the first release is worth buying as-is. Don't ever fear that this project will just be abandoned though. The general TODO list looks something like this:

• Finish adding the new parts
  
• Improve the DustBowl map and add one more map (3 maps + test map at first release)
  
• Game balance testing, and writing some code to make part stat balancing easier
  
• Proper setup for running a dedicated server (this might be able to skip being in the first release, but it's near done anyway)
  
• Add ability for players to join multiplayer games at any time (not just in the lobby)
  
• Allow players to quit multiplayer games (they can quit now, but the server doesn't handle it properly)
  
• Internet play (LAN is working, but not Internet)
  
• Scoreboard
  
• General cleanup of bugs, TODOs etc
  
• A bunch of other small tasks
  
• Non-game stuff: Contacting press, creating a new trailer etc

The "players can join a game at any point" and the Internet play are the biggest tasks remaining. The guy I have doing the AI work - Dave Leaver - will probably also help with the Internet networking side of things as he has more experience in that area and he's a top-notch programmer. Of course I've never set an official release date and I'm not about to, things will take as long as they take, but I really want to get this finished too.

Oh yeah, I've also done some tricks to get a decent performance boost in-game (mainly, combining everything I can on a vehicle into one since mesh instead of many), paving the way for more vehicles on-screen. You'll also see when I put out a builder demo update that the in-game GUI has been redesigned a bit and now scales automatically to screen resolution.

Oh yeah, and the cockpit part now also looks a bit different (better?):



Phew. That was probably too much for one update but at least you know I'm working.

 

That's brilliant! I like the idea that cooling could be damaged incrementally too, resulting in decreased effectiveness- knocking off cooling fins would be a good visual representation, as would a leaking radiator on the active variant.

As the guns overheat, you'd expect some sort of material warping to occur, also resulting in less accuracy- does the damage they take while overheating have this effect?

I prefer the newer cockpit, the level of detail is a better contextual fit for the other components.

 

The damage effects are fairly simple compared to that at the moment. There's a damage texture that increases in opacity as damage increases, and some parts have additional damage effects like smoke/flames/sparks etc. Parts falling apart, leaking fluid etc would be cool, but I'm trying to keep it fairly simple or I'll never finish the game.

Weapon effectiveness currently doesn't change, but an accuracy reduction wouldn't be toooo hard to do.

 

Yeah, fair enough, feature creep is lethal.

Completely ignoring the above statement for a moment, it would be interesting to have power units that might themselves be overclockable with some optional cooling, with a sprint key to activate them- see here. These power units could then drive their own active cooling units, so you have a sort of water-cooled engine with a bit of excess cooling to go towards weapons when the sprint key isn't engaged.

Because you're actually allowing the player to risk damage for extra performance rather than applying an FPS-style cooldown period, you get another layer of emergent dynamics.

 

I really like the general idea of being able to on-the-fly reroute power, temporarily boost systems etc, kinda like the weapons/shields/engines re-routing that you got in the X-Wing/Tie Fighter/Freespace games. At the same time, it conflicts with my goal to keep things simple and automate as much as possible for the player. I don't want new people to have to learn a whole lot of keys and gameplay tricks to be competitive. Of course there's always the option of having some sort of simple/advanced switch.

 

Weapons
All parts that I want to be in for the initial alpha release are now done.

Since last week, I finished the Medium Laser:



Yeah it's kinda boxy, but I think it's OK sometimes to sacrifice a bit of visual appeal for practicality. Like with the Medium Cannon, it's nice having some weapons where you can snap stuff other parts around it. Here's a vehicle with four lasers shooting an AI:



Everyone who pledged $35NZD or more on the Scraps Kickstarter was also promised a special exclusive weapon. Enter the Tesla Device:





The Tesla Device is a short-range tesla coil. It auto-aims at anything nearby that has health and zaps it until it's dead or the power runs out (...or the player gets too far away, or stops firing). It can also zap multiple targets at once (with reduced damage to each).

Part Stats
I wrote some code to export stats for all the parts in the game to a spreadsheet, and import them back again. Now I can concoct formulas to help balance stats and costs for parts, and I've been doing some of that. Real-world testing is still needed as well since there are lots of little factors that don't necessarily show up in stats: For instance the Small Machine Gun is hard to aim, so it deserves to do a bit more damage relative to its cost.

Builder Demo
I'm just fixing some bugs and cleaning things up at the moment in preparation for an update to the Builder Demo. I'll do a mini-update when that comes out sometime between now and the next news update in two weeks.

 

Neat effects with the Tesla Device. Makes me wonder what the code for it looks like (to decide on the electrical-stream paths), and how it looks in-game/how it's animated. Projects like these are inspiring for other one-man indie development 'teams'.

 

I think I paid for the alpha some time last year, but didn't follow the topic for a while. Is it out yet?

 

Not yet, it's taking a bit longer than I hoped it would I'm afraid, but it'll get done. If you backed the Kickstarter you'll get a key when it's out next year. Thanks for supporting the game.

It's not actually too complicated in this case. I basically call an OverlapSphere in the area around the weapon and get up to [max targets] things that have health scripts on them, ignoring the player's vehicle itself. I just use a LineRenderer to draw a line between the weapon and the target for the main lightning effect, with some random jittter on the position of the mid points. I might write a custom LineRenderer at some point in the future since apparently the Unity built-in one adds a draw call for every line, but it's good enough for now. I see there's one on the Asset Store as well.

The actual material for the lightning isn't animated at all. I thought I might need to, but with it jittering around like electricity does, you wouldn't really notice anyway. There are a couple of animations that play on the coil itself though - the idle particle effect that you see in the gif, and another one that plays while it's active (which also helps to show that it's working, since it won't actually be firing lightning if nothing's in range).

I send the actual damage through at a certain tick rate, using Scraps' existing health/damage systems.

 

I missed the kickstarter by a day, and you sent me a paypal link via PM if I remember right

 

All good, I have those too.

 

"So what sort of game are you making?"

"Well, it's a bit like



"

 

This is supercool, i love games where you can build your own stuff!

 

The Scraps Builder Demo version 0.3.0.0 is now available, bringing a lot of changes from the internal dev version of the game to the demo.

You can download it here as usual.

Changes:

2014-12 - 0.3.0.0
- New Plasma Artillery and Medium Laser weapons
- New cooling parts and a heat management system
- Updated, auto-scaled in-game GUI
- Test map cubes are a bit harder to destroy
- Can now drag parts from the inventory on the build screen (clicking is still suggested, because you can rotate the view while holding parts)
- Real-time shadows and baked shadows work at the same time
- More bump mapping etc in terrain graphics
- Major game performance boost
- Partial redesign of cockpit part
- Build screen categories are now icons with tooltips
- Tooltips show right away on Build screen parts, and sometimes have some more information than before
- Updated the game engine from Unity 4.5 to 4.6
- Improvement to part pickup so held parts are more centered on the mouse
- Some driving physics tweaks (still needs some major work at some point)
- Some weapons now have a max range
- Finally changed Test Map skybox to something that isn't one of the ones that comes with Unity
- Major balance pass to part stats. Many costs and other stats of parts have been adjusted
- Can't watch vehicles being built while loading them anymore. Sorry.
- NOTE: The cockpit vis check camera had to change a little, which may potentially make previously OK vehicles not OK
- NOTE2: Large cannon collider also changed a little - this could invalidate parts on old vehicles
- NOTE3!: Gunpowder weapons now need mostly cooling instead of power
Bug Fixes:
- Fixed vehicle naming so "New Vehicle" isn't reused when a vehicle of that name already exists
- Stopped smoke moving in the "up" direction of the vehicle instead of world-space up
- Fixed large cannon barrel starting partially retracted
- SMG auto-adjust for really old vehicle saves now handles rotated SMGs correctly
- Various other small fixes

 

The recent demo update was a big jump from the last version so there were bound to be a few un-spotted issues with it. I've just updated it to fix a few things.

The main issues were that the scrap container had its snap points turned off, and there was a bug with the available range calculation for weapons. There's still at least one other bug with the range calc but it's an old one and I'll track it down some other time - it doesn't show up in most situations.

Some part stats were also incorrect and have been updated in this release. The small active cooling unit in particular was way too expensive,but some other parts were using out-of-date values as well.

Download page.

 

The last two weeks have had a lot of minor bug fixing and various small stuff that isn't really worth talking about, so let's talk about Scraps' aiming system.


The aiming system in Scraps
So what do all those cross-hairs on the screen mean anyway?

The short answer is that the white cross-hair is where you're currently aiming, and the various coloured cross-hairs show where your selected weapons are actually aiming, which will be as close to the white cross-hair as they can get. The different colours are for different weapon types.

But even accounting for weapon movement range limits, and the time it takes for them to move to a new position, the cross-hairs don't always line up. In this screenshot, 2/3 of the weapons on the the player's vehicle are shooting the other vehicle, even though the main (white) aiming cross-hair is way above it. And the 3rd gun is aiming right at the cross-hair! Why is that?



It's because you're not looking straight down the gun barrel, you're looking from above it, so your point of view and the gun's point of view are different. Because of that, something can be in the way of the guns (in this case, two out of three guns are blocked by the other vehicle) but not in the way from your perspective (your main aiming cross-hair isn't hitting the vehicle at all from your point of view).

In an FPS game, your line of vision and the angle of your gun are often considered essentially the same. In third person games, the character is sometimes placed with their gun right in the middle of the screen, which also removes the problem (since your view and the gun's "view" are then the same). Neither of those were appropriate for Scraps.

In Scraps, your weapons always try to aim directly at whatever the main, white aiming cross-hair is currently aiming at, though they may not be able to due to limited movement range. Since you're dealing with two different points of view, the coloured cross-hairs exist to show you what your weapons will actually hit, assuming they fly dead straight. For projectile weapons, you may also need to manually account for bullet drop due to gravity.

This can sometimes be a little counter-intuitive. For example:



Here we're aiming at the box, and so is the machine gun. The cross-hairs line up.



Now we've aimed up a little, and the gun has aimed...down?

This is because we're now aiming at the back wall instead of the box - and hence so is the machine gun. But the box is in the way of the gun and not in the way of our view, since our point of view is above the vehicle. The gun has adjusted its aim to (theoretically) hit the back wall exactly where we're aiming, and the blue reticle is showing that the gun will actually hit the box, at that point.

Now you might be thinking, wouldn't it be way better if the guns just always aimed so they lined up exactly with the cross-hair?! Avoid all this weirdness!

But it's actually impossible:



If the gun aims high enough to clear the box, it'll be aiming way up, above where the cross-hair is. If it aims down to meet the cross-hair again, it'll start hitting the box, ending up below the cross-hair. There's no valid solution that makes the cross-hairs line up. Unless....well.

A point for potential discussion
There's an aiming issue I'm currently thinking about. It's nice being able to have all your weapons selected at once to get maximum fire-power, but as the weapon options in the game increase, this becomes less viable due to different projectile speeds. A projectile that's meant to be lobbed at an enemy at an angle will hit too early when aimed straight from a distance, but other weapons may need to be aimed straight to hit.

I have some nifty code that I wrote for the AI to use that automatically adjusts the aim angle of any projectile to hit any point within range. I'm tempted to have it on for players as well because although it'd remove some skill required in aiming, I like it when things just work without being fiddly.

The problem is that with AI, I know what they're trying to hit. Scraps doesn't have a targeting system and I'm not keen to implement one just for this - there are enough buttons to press already. So my best guess for targeting is what the player's aiming at.

For slow projectiles, you'll often want to lead your shots, aiming in front of your target if they're moving perpendicular to you. If projectiles auto-adjusted their angle to hit what you're aiming at, in that case it'd be something behind what you actually wanted to hit, and they'd sail over your target. So manual weapon switching may remain the best option. Or just select all and shoot all over the place because really that's the Scraps way.

 

I remember dealing with the same issue a while back with one of our games and I'm not sure why the double crosshair solution didn't occur to me - good solution to a tricky problem

 

Another thing I think I've seen is tinting the cross-hair red when its path to the target is obstructed.

 

Hello again in 2015.

I sort of a had a week off over Christmas to go and visit family, plus catch up with things around the house. But I have also had a week of work since the last update.

I made a mock-up of a scoreboard for Scraps games. One that you can show by pressing a key while in-game, and also see after a game ends or you quit (click for full-size).



I just need to write some code to populate it with actual values instead of fake placeholders. In-game it's semi-transparent so you can also see what's going on while you're viewing it (like you're getting shot).

I also did some multiplayer work (like players can cleanly quit the game now!), but I also seem to have been burdened with an unusual number of difficult to track down bugs this week. I think it's easy to look at a game and say "well it'd probably take about two weeks to do that feature and a month to do that...", but (and I'm guilty of this as much as anyone else) there are so many little things that can't be easily predicted. Weird and hard-to-track-down bugs are certainly a part of that. Some people choose to take an estimate and just double it.

You also sometimes hear comments like "programming is really hard - you can get just one letter wrong and the computer won't understand it!" I wish my bugs were that simple!!!

Highlights of annoying bugs I fixed in the dev version this week:

#1

Problem: Sometimes, rarely, when a vehicle should have been destroyed it would only lose its chassis and the rest would survive, which should never happen and would throw a whole string of errors.

Analysis: In the Unity engine you can destroy an object, and any child objects connected to it will also be destroyed. The actual destruction happens at the end of the current frame.

I found this bug quite hard to track down. I discovered that if you destroy an object and then destroy one of its children in the same frame, occasionally only the child will get destroyed. When a key part on a vehicle got destroyed, I was destroying the whole vehicle, but still destroying the part that got blown up as well, which was triggering the bug.

Solution: Made sure that if I destroyed the whole vehicle, I didn't destroy the part.

#2

Problem: I was checking if an object had been deleted, but the code was happily going straight past that check and trying to use it even if it was gone, throwing null reference errors.

Analysis: This is a technical one, but Unity overrides the null operator, basically because when they delete some things they don't actually delete them, but they want to make it look like they did. I knew about this but I missed a special case.

I had a Unity class (a MonoBehaviour) that I was referencing as an Interface. Because I wasn't looking at it as a MonoBehaviour, == null wasn't overridden, causing it to say it was NOT null when it had been deleted.

Solution: Changed the == null check to .Equals (null). If you cast a MonoBehaviour to an interface and you delete it, == null will return false but .Equals(null) will return true!

#3

Problem: I was getting frequent errors claiming that "curSource->m_Channel != NULL" in the Unity console. Weird to get an error that something isn't null for a change. This was coming from deep within the Unity engine and came with no indication of what was causing it and in fact no other text at all.

Analysis: An Internet search turned up that it was related to audio, but was officially "fixed" long ago. I tracked it down to being caused by assigning an audio clip and playing it when weapons fired, but I couldn't work around it (without not playing the sound at all), and I couldn't reproduce it in a separate test app when trying to replicate the conditions. Eventually I discovered that it was caused by calling that audio code from an InvokeRepeating method. What.

Solution: Changed the InvokeRepeating to a Coroutine that did exactly the same thing and ran exactly the same code. No more errors. I've reported this one to Unity but unfortunately I still can't reproduce it in a simple test app, so there must be more involved somehow.

#4

Problem: Sometimes the AI wasn't firing the large cannon on all computers in networked games. It might fire on one PC but not always fire on another.

Analysis: The way the Scraps AI works right now, it tends to fire for one frame, the very first frame that a weapon is ready to fire again. This happened to be just the right scenario to show up an issue that human players don't usually trigger.

Scraps only sends player inputs over the network to control vehicles. It doesn't send "weapons 5, 7 and 9 fired", it just sends "player pressed fire" or "player released fire" and the vehicle is expected to do the same thing on all machines because it's an exact duplicate.

I'd quite like to avoid syncing things like "weapon fired" because:
1. It paves the way for hacks of fire rates etc. Like a player says they fired their gun 100 times at once.
2. There can be lots of weapons on vehicles and there's only one on or off "firing" state, so it's a lot less data to send over the network.
3. It's just simpler to send only the inputs!

But this was the problem: Imagine the AI presses Fire at time 0. Anther PC receives that message at time 100 due to latency. Then the AI releases Fire and they send that message too. The weapon fires on both machines (with a slight delay on the second one).

Say the weapon has a min time of 500 between shots. Now the AI presses fire again right when the weapon is next ready to fire, at time 500. The message is sent - but what if latency has reduced in the meantime to 95 instead of 100, so the message is received at time 595? 595 - 100 = 495 and the weapon isn't quite ready to fire yet!

If the AI kept holding Fire it'd be no problem, but right away in the next frame it releases Fire again, the message comes through as well, and the weapon never fires on the second machine.

Solution: Fixed for now by imposing a short minimum time for holding Fire before releasing it. This doesn't prevent all possible issues, for instance think of releasing Fire just before a weapon is about to fire again. I have a couple of better fixes for the future in mind, though in practice, any other issues like this are actually very rare.



By the way, I updated the Builder Demo slightly the other day. Weapons were taking on the heat they produced when firing for one frame before the cooling system would attempt to take it away. Mostly it wasn't a big issue but it meant that some weapons - particularly the Large Cannon - could end up taking heat damage even though the cooling system was well below max capacity. The download is now version 0.3.1.1.

 

Your pax display looked really cool. Do you mind revealing how much setting it up cost and if you thought it was value for money?

 

Yeah, it cost $1300AU for one of the standard indie booths, and they come with the two big banners (you just submit your art). I'm not sure if it was worth the money - it'd be easier to tell for a released game where you could look at the sales increase, although even then a lot of it comes later from slow word-of-mouth etc. Note that it's also a good place to talk to other devs and there are XBox/Playstation/Wii people coming around and chatting about developing for their systems etc.

More in the post about it: http://www.scrapsgame.com/scraps-pax-australia-2014

 

Thanks. Sucks you couldn't keep the posters. I would of been pulling them on the plane with me!

Sadly I couldn't stay for pax but I did go to Unite and GCAP. I couldn't convince my work that it was better way to spend my time going to a game expo! I am already hell bent on turning my work in a hub for game development and don't need encouraging.

 

They're big enough that he could have used them as wings and flown home himself! Got to think outside the box people...

 

They were seriously big banners, probably even bigger than they look in the photos. A 2m high banner that doesn't bend is a very unwieldy thing.

 

I did make my scoreboard system functional after the last update, which was a nice opportunity to make some AI vehicles battle each other and see how their different difficulty levels stacked up.



Left column is Randomly selected AI player name + its difficulty setting. Points is "kills" and Lost is "deaths". Looking OK; Medium needs a bit of a difficulty nerf.

But mostly I've been working on players being able to join games that are already in progress. I feel like it's a pretty important feature to have at release because if someone's looking at a list of game servers, it'll vastly increase the amount that can be joined (otherwise you'd only be able to join games that were still at the Lobby stage). Some other games let players join but make them wait for the next "round", which would be much easier to implement, but that forces the game to have short rounds or long waits and I don't want that for Scraps.

Getting everything to synchronise with a new player joining in the middle of a game is a big job - possibly the biggest single task left on my list before the full alpha release. If you're in the game from the start, the network can get away with sending you only what changes: A player pressed fire, some wreckage spawned, a part got destroyed, someone changed their vehicle...

But when someone joins in the middle of the game, I need to sync everything. It's not an insane amount of stuff (at least it's not hundreds of physics objects or something) but it's still server settings, everyone's player data and their current inputs, and everything about their vehicles and what they're doing right now.

Scraps is a bit more complicated to sync than your typical FPS. Players might be in the middle of a transition while using an evac pad (in which case I actually wait until they're done before syncing that player to the new player - it's simpler that way). They all have different vehicles with various parts that can all take individual damage. Complex situations can present themselves. For instance what if a current player has a vehicle, and the new player's building it so they can sync to the game, but that vehicle loses parts or gets destroyed while the new player is building it?*

Conceptually it's straightforward enough: Just send the new player all the stuff! But going from broad concept to actual execution is like determining that we need to draw a landscape, and then having to do it via mathematical equation.

*You probably queue that stuff up.

 

I got players joining games that are already in progress working last week, then I cleaned up the lobby and the menus so it all works like it's supposed to, and I'm starting to actually feel like things are really coming together. Stuff is working and hey, it's fun too.

The biggest single thing left to do before release is Internet play (single-player and LAN are working now), and I'll be spending some time with Dave (who also did the AI) next weekend to delve into that. Then there's a bunch of other smaller tasks, bug fixing, finishing up TODOs, and creating a new trailer etc for marketing... but it'll get there.

The lobby is a bit more functional now. Here's the single-player lobby:



What's "AI Infighting" you ask? Well, it determines whether AI players target everyone, or only human players. It's like extra difficulty, or instant boss battles!



Bonus graphics glitch. Somehow some textures got messed up and sort of created Steampunk Scraps?

 

Aaargh, Steamworks integration is driving me crazy. Things that work sometimes and just randomly don't work at other times. Things that work with some settings but not with others. Too many layers of things going on to easily debug.

I don't ask for much. I load up the Steamworks.NET example project in Unity, App ID set by default to 480 (Spacewar). I run it and it Steam shows me as playing Spacewar. Awesome.

I change the App ID in steam_appid.txt to another game, say Counter-strike (10). Now Steam doesn't show me as playing anything when I run it anymore. Why? But if I quit Steam it says "Waiting for Counter-strike to shut down..." so it clearly knows something about it.

I change the App ID to my game's ID. It still doesn't show anything. Well, that was expected by now. But when I quit Steam it says "Waiting for to shut down...". The name is blank? Why doesn't my game have a name? I've set it on the Steam partner site... I think? It shows up everywhere there.

I set up some basic P2P networking in my actual game. It's simple and it works perfectly - I'm connected over the Internet through Steam! But then it doesn't work. Sometimes. Most of the time actually. It's seems like it didn't disconnect properly or something, but that's just a guess. And Steam still doesn't show me as playing it and the name is still blank. And sometimes the Steam overlay doesn't show up, even though I can always (and this is the one thing that seems reliable) get my Steam username and ID. And the problem could be at the Steam level, or the Steamworks.NET level, or at the uLink networking level because I'm using that on top of Steamworks as well (with traffic routed through Steamworks P2P). The problem could even be at my level, but there are enough layers involved now that the code no my end is only a few lines - it looks pretty hard to mess up!

What. Is. Going. On. I've asked on the Steamworks forums but they seem pretty quiet so far, although I realise it is the weekend.

This post will also probably look really dumb when I find whatever simple, obvious thing it is that I've been doing wrong.

 

Hey Nitition.

I understand the pain you are going through. Steamworks is super annoying and I didn't even had to use the server hosting integration. I was getting that error when having the editor opened together with the actual build in Steam.

Seriously took me two weeks until I managed to understand the system and correct all the problems

My advice is to talk to Riley Labrecque. He knows a lot regarding Steam and Steamworks.NET, since he made the project He helped me iron out most of the problems and it cost me like 50 bucks or something. (his project is free but his councelling is not, which is fair).

Good luck.