next »

[Nition]

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 blank spaces. 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.

[Nition]

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.

[dynasty9]

I get so jealous after looking at the realization of your game idea. I love the idea of having simple parts that you can integrate together in unique ways.

[Nition]

Thanks, it's something I've wanted to play myself for a long time.

[Nition]

"So what sort of game are you making?"

"Well, it's a bit like



"

[Nition]

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

[Nition]

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.

[Nition]

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

.

 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.

[Nition]

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.

 

[Nition]

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.

[marcgfx]

pretty interesting to hear what you are doing network wise. It's something I haven't dare touch (I'm working on a racing game) as I am worried about the correction algorithms to prevent things from going out of sync. your approach of adding players later on sounds like it could require quite a lot of data to be synched. you did mention it was not 100s of physic objects, but your vehicles look like they are made of hundreds of parts

[Nition]

That's true. It doesn't come out too bad though. All the uncompressed data about a vehicle's parts is maybe 10kb (more for complex vehicles, less for simple ones) uncompressed, and can be sent compressed a bit. Add say 2kb for health data on those parts. So even a 56k modem user should be able to download all the vehicles in an 8 player game in a few seconds.

[Nition]

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?

[Nition]

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.

[Nition]

Turns out my Steamworks issues were due to a bug on Valve's end. They've recreated me a new App ID which unfortunately has wiped all the config I'd already filled in, but fortunately has also fixed all my App ID troubles. Not sure about networking troubles yet.

[Nition]

Yeah, so, most of my Steamworks networking issues seem to be fixed. I still have a remaining issue with the case where a user wants to host an Internet server and play in the game on the same machine, but a couple of potential solutions have presented themselves there.

In other news, I sent out a build with single-player and LAN play to a wider group yesterday. Looking for bug reports and gameplay feedback from that.

Someone on the forum pointed out that force from explosions pushes everything in the same direction, so I fixed that (internally - it's not in the builder demo now): 



Vehicle shoots, projectile hits on the far side of the cubes. Previously that shot would have pushed all the cubes away from the vehicle. Now, an object hit directly will still get pushed in the opposite direction to the projectile, but objects caught in the explosion will be pushed away from the central hit point instead (with less force for objects farther away of course!).

I also gave a reply on Reddit about the genesis of Scraps which might be worth reposting here:

"One of the things I really liked about I76 (apart from the amazing 70s campaign) was the vehicle customisation. Changing your weapon loadout, moving your armour around etc.

A while after that I remember playing demos of a couple of games where you build your thing more from scratch: Stratosphere: Conquest of the Skies (well done anyone who remembers that), where the game itself was pretty bad but you built your own flying fortress, and Lego Racers, where you built your car from scratch but it had very little effect on how your car actually behaved.

So then I wanted a sort of mashup of those where you could build a car from the chassis up, but the parts all had actual functions and appropriate physics, so you could build terrible cannon towers that fell over when they fired or ones that overheated and blew up or y'know, actually something effective if you were good enough.

I waited a decade or so for that to actually exist and then eventually just started making it myself."

[Nition]

Quick demo of some single-player Scraps with different weapon types:

[Nition]

Trying to make my maps look a little bit nicer. This is the older DustBowl map that I haven't touched in a while.



Although I think it also looks better in motion.

[Nition]

In other news, I told the AI that they could make this sweet jump:

[marcgfx]

watched the video, looks good. I like the simplicity of editing a cart, but I didnt quite understand how the parts themselves interacted. maybe it would be good to get some stats before returning to the game (expected top speed, power/weapon requirement). I believe darker shadows would be good, there is a visual disconnect between vehicle and ground in my opinion.