next »

[Nition]

There are some stats at the top-right on the build screen, although estimated top speed is one I should probably add.

[Nition]

Tried Scraps in Unity 5. Good to see the physics working perfectly without any changes needed.

[Nition]

AI Players in Scraps currently use a navmesh to work out a path from where they are to where they want to go. Unity comes with a built-in NavMesh system which is really nice and easy to use, until you want to do anything fancy. I've been trying to wrangle some better meshes out of it.

It feels like the NavMesh support is one of those Unity features that had enough work done on it to look awesome, but not quite enough to be great to use. You can set some parameters:



And then tell it to auto-generate a mesh based on all your static (non-moving) geometry. Here's an example on my SandyBridge map:



Using that generated mesh (the blue area), you can then simply ask it to calculate a path from one point to another, and it'll efficiently calculate the route. Now your vehicle (or other entity) can avoid hills etc and get anywhere effectively.

Except not really.

Entities can path anywhere within the mesh, and since they're always finding the shortest path, they'll often hug the edges. That path behaviour is unchangeable. You can't say "try to go down the middle." So the above mesh is actually too generous with its available area. A vehicle pathing on the bridge often falls off the side, while a vehicle pathing near the edge wall or an obstacle can get stuck on it. It doesn't help that scraps vehicles can be all different sizes, but the mesh must be baked to one specific size.

I can increase the Radius setting to bring the navmesh in, but that introduces another problem: The navmesh won't return a path - not even a partial one - to a target that isn't somwhere in the mesh area. Interestingly there is a path status called "partial", but it never seems to happen. Maybe it only happens when you use Unity's built in nav agents thing (which I don't use)? You might say well, maybe there's something to at least get a point on the mesh closest to a given point, like they have with ClosestPointOnBounds for bounding boxes? Then at least you could path to there instead, then go straight to the target from there? Nope.

So say you're on the mesh and the AI is on the mesh and they're chasing you, right? And they have a nice multi-point path to you that goes around a hill. But then you drive off the area covered by the mesh. Now the AI recalculates - suddenly there's no path! So it has to just drive straight at you, right over the hill.

The navmesh pathing is awesome when it works. You can even link different parts of the mesh and weight them to balance when they're chosen, like here where I told the AI it could do this sweet jump on the DustBowl map but only if it was a major shortcut:



You can also have different layers, with different weights and exclusions, so I can say "vehicles can drive on the hill layer if they have x or more engine power" or "only use the hills if it's this much faster than going around."

So I figure the best thing to make this work is to make sure the whole map is covered with navmesh, but there's a normal section, a hilly section, and a usually-out-of-bounds section just for chasing targets in crazy places. Then AI will be able to path anyway, but usually will only go in good places.

But the terrain can't be split up into layers. And you can export a generated navmesh to a 3D model and cut it up there (I wrote a script for it), but you can't import it back in - only generate another mesh from the first mesh, which is like photocopying a photocopy.

Using two separate NavMeshes and some 3D model hacking in Blender I added a hills layer:



But there's still lots of empty space, and I need to fill the rest with like an "out-of-bounds" NavMesh so that things can get a path.

Can I just put a big flat plane underneath and generate a mesh off of that to fill the gaps automatically? No! The mesh has to line up nicely with the other mesh layers or it won't join up. You can use "off-mesh links" - if you want to manually place a million of them. Trying to get different layer meshes to join up is an art in itself.

Oh yeah, and if your modified mesh doesn't line up well with the actual terrain, pathing won't work either. Objects have to been within a few metres of the mesh vertically, and that parameter can't be tweaked. I understand you have to allow for stuff like the over-and-under the bridge above, but I'd love an "automatically path using the closest mesh" option. Maybe I could use SamplePosition to get the y position of the mesh instead of where the vehicle is an get a path based on that...

Anyway, I managed to hack together a system for filling the gaps in my mesh with another mesh that could be the out-of-bounds mesh. But it's a terrible process that could replace the preliminary Mensa test in terms of mental leaps required. The process sucks, and it still gets weird gaps and things in it anyway.

That isn't even everything but this post is too long already. Right now I'm working on a script that will export my terrain already cut up into separate meshes based on slope; Then I can generate the different layers I want based on that. But I'm sure that's also going to have issues when I try to generate a navmesh from it. One day I'll probably have to throw out Unity's built-in solution and use another one - preferably one where I can edit the source!

Thanks for for following Scraps' tortuous development.

[Nition]

Oh man, I finally worked out a semi-automated method to generate nice slope-based layered NavMeshes for my terrain:


But now Unity crashes whenever I use it.

[Nition]

Yeah so, as I mentioned briefly above I wrote a script that would automatically split my terrain into layers based on slope, so I could hopefully then assign those as different layers in a NavMesh.That actually turned out quite nice.



From that I could finally generate a nice layered NavMesh in unity:



Slow vehicles can stick to the blue area, more powerful vehicles can include the purplish area in their path calculations, and almost everything is covered by NavMesh so targets outside both areas can still be pathed to. Basically what I wanted last week but couldn't quite get. Static obstacles still have gaps around them but that's not a big deal. It's almost too good to be true...

So of course it was. As soon as I tried to calculate a path with it, Unity crashed. Is there no end to these sisyphean trials? It seems like the extra detail generated from the layer joins is just too much for Unity to handle (although I notice that the actual path calculation, when it occasionally works instead of crashing, is still very very fast. So er, C+ for effort Unity).

A couple of people mentioned the A* Pathfinding Project as an alternative option after my last post, which I'd seen before but not really looked into. It seemed like an opportune time to give that a look.

In summary it basically looks good. It gets around some limitations in Unity's built-in system by allowing 3D model meshes to be used directly as navmeshes (Unity only allows generating navmeshes based on meshes), and not crashing when you use it is a nice bonus. But its interface and API is quite different to the built-in Unity one and it'd require a bit of time to convert things over - and this whole process has already been way too time-consuming!

So I simplified the Unity NavMesh to a point where it has as much coverage as possible while not crashing.



THAT'S GOOD ENOUGH.

Sometimes it's all about knowing when to stop and move on.

[eigenbom]

This looks pretty cool. I totally missed it at PAX, but maybe I'll check it out this year if you guys are there.

[Nition]

I don't think I'll be going to PAX this year, but I will be releasing the game this year, so you should be able to play it anyway.

[The Uber Cannon]

Game looks really fun. Is it ready, or is it still under development?

[metagrue]

This reminds me of something I have been doing in Unity involving modular buildings. How did you handle all the modular parts connecting dynamically? I've been using triggers. Lots of triggers. Bugs abound when you have two triggers stacked on one another...

[Nition]

A Scraps vehicle is a Rigidbody at the base with lots of primitive colliders on it - one (usually a box) collider per part when in-game. They're standard, non-trigger colliders. So a Scraps vehicle is basically one big compound collider with wheels.

Or did you mean how do I handle the actual snapping of parts together?

Game looks really fun. Is it ready, or is it still under development?

Still in development. You can try out an early demo though where you can build vehicles and try driving them on the test map: www.scrapsgame.com/download

[metagrue]

Or did you mean how do I handle the actual snapping of parts together?

Was my primary inquiry, yes. The game looks awesome.

What I've been working on - snapping together is as important as falling apart. A whole lot of fun.

[Nition]

OK so, the snap points on the parts are just GameObjects - the visual '+' symbol doubles as a representation of the location of a snap. Scraps isn't strictly grid-based - snap points can actually go anywhere.

When parts are added to the vehicle, I put them into an octree for fast search (I open-sourced it actually). When the player is holding a part they want to place, I cast a ray from the current camera position through all the snap points on that held part (so basically straight into the screen), and find the closest snap point to the ray on the vehicle. Then I snap the snap point on the part to the snap point on the vehicle. There's a distance limit too so if all snap points are too far away it won't snap.

In practice it's a bit more complicated (I also check the rotation of the snap points and their visibility, plus do some other stuff), but that's the gist of it.

Note that the into-the-screen raycast system means I snap based on how close the parts are visually on-screen, regardless of how close they really are. I think that generally works better.

[Nition]

Not a lot to write this time as most work has been on code that just isn't that interesting to show. I've been through the high severity bugs and fixed all of them (although I'm sure more will appear). I've been through all ~200 TODOs in the code and fixed all the ones that needed attention before release (luckily not very many).

Dave has been too busy to do much on the AI or Internet play so not much to report there just yet (he's got other full-time work).

I have been working on one interesting thing:





Part unlocks. Destroy enemy vehicles and you'll earn XP. As you gain XP you'll unlock more parts. Obviously a basic set of parts is also already unlocked from the start. This is actually the last major task on my list before the first release. The rest is marketing stuff, and a bunch of smaller tasks.

This serves a dual purpose:
- It gives the game some progression and changing content in the absence of a campaign/story mode.
- It functions as a sort of tutorial so players aren't overwhelmed with selection the first time they play.

Although I still need to add a better, proper tutorial thing before the public release though, even if it's just a big static HOW TO PLAY screen with a bunch of words and images for now.

No parts in Scraps are really "better" than others, because more powerful parts are also proportionally more expensive. I'd hate to make a system that put new players at a forced disadvantage. But I'm setting it so players tend to start with smaller parts and proceed to unlock bigger, more expensive parts as they go, so it's (hopefully) still exciting.

Anyway, really this system is more of a personal opinion thing, but I've always had more fun with games when there's progression. I enjoyed unlocking the levels in Rollercoaster Tycoon more than I enjoyed having everything unlocked from the start in Rollercoaster Tycoon 2. As counterintuitive as that might sound it really just seems more fun to have something to work towards (applies to real life as well!).

Having said that, this won't be some fancy cloud-deployed network-synced online-profile-linked DRM'd progression system. I don't need to protect any content. XP is just a dumb saved number on your local machine and certainly not un-cheatable. In fact I think I'll put in an official way to cheat and unlock everything, for people that would really prefer it that way. I know not everyone is like me.

[Nition]

Still making progress. Things have been pretty busy for me over the last couple of weeks, with some non-Scraps-development stuff to do. But work continues and we have Internet play basically working, with just a bit more to do on it.

Although we have what looks like a normal client/server system with a server browser, we’re doing it though Steam’s matchmaking system so we can utilise their excellent setup for making sure anyone can host a game – no port forwarding or other messing with your router required. Now if only they’d reply a little more often on the Steamworks dev forum.

[Nition]

I think I have about three months of work left to do including finishing the game itself, marketing work like making a new trailer, and a final testing run; not too bad considering the long 2½ years it's taken so far.

Right now I'm making some in-game help, for those people who are going to be playing this having never seen the game before and who really won't know where to start. It's a few static screens for the moment. I'm a fan of context-based help that hands out the info when you need it, but that can wait for a future version.

Here's a help screen with some vehicle design examples, to show how you can spend your scrap in different ways:


Internet play is working though Steam quite nicely now, with anyone being able to create a game and have others see it in the game list. Unfortunately it still seems a little bit hit-and-miss about whether it works perfectly so there's a bit more work to do there.

Looking through the SVN commit logs for the last fortnight, I also fixed some bugs, improved graphics performance (I did have to remove that nice Sun Rays effect though - it was causing a ridiculous 25-30% performance hit when turned on), Dave knocked out some CPU performance issues for the AI, I made it so the host or the server can kick players, added in-game chat, made dedicated servers better configurable and ready for release, added and updated some default vehicles that come with the game, and added some neat little flags to show what country a server is in. Actually let's talk about that.

Little Flags
Steam has two major ways to host multiplayer games. There are servers - the older system- which can be browsed in a server list and joined by players. Then there are lobbies, which are similar to servers, but have extra features intended for smart multiplayer matchmaking. Team Fortress 2 for instance has both of these systems available.

For Scraps I basically want servers and a server list, but we use lobbies to do it because (as I know I've said previously) they do NAT punch-through and other magic that makes it easier for Random Person X to create a game and have it show up on the public Internet, and the server system doesn't have those features. Dave has set this up cleverly so we can still get a nice server list out of it anyway.

Unfortunately we can get everything except the ping. That is, the network round trip time. And I don't know about you but a lot of the time if I'm looking for a server to play on in a game I sort by ping first. It so happens that Steam has that function for servers but not for lobbies - unless you want to actually connect to every one, and that doesn't sound very scalable.

Luckily there is something usable - lobbies are (ostensibly at least) always returned in order of how far away they are from you, which should give a reasonably good indication of best-to-worst ping. As far as I can tell that's basically how the normal matchmaking works in other games.

Unfortunately the actual distance data is internal and we can't get to it, so there's no fancy number to show in the ping column. Right now I'm just showing a "Distance Rank" instead, which is just an ordered one-to-whatever for distance away. If you choose number 1 then you're choosing the best one, which is all fine, though the problem I have with that is for all the player knows they could be all super close or all super far away.

However, there is a function to get what country Steam user is in. So I have the server get what country it's in, save that value, the server list on the client reads it, and you get this:



With a little flag under Dist. Rank that should give a decent indication of how far away a server might actually be.

NavMesh Sadness
I also thought Unity might have actually fixed the NavMesh crashes I was getting because the Unity 4.6.4 release notes say:

• AI: Fixed potential hang when NavMesh connecting wrong side of thin polygons to neighbor tile.

And in some early tests with my stuff it looked like that may actually be the case. Unfortunately it turned out that it just crashes a bit less quickly than before. Unity QA hasn't actually even confirmed my bug report yet - I wonder if they've pretty much abandoned 4.x QA for Unity 5 because usually they're pretty fast. Unfortunately Unity 5 has some other major issues that make upgrading right now seriously not worth it.

[gimymblert]

following

[metagrue]

I really had to go a similar route with a current project as well. Attractive as Unity 5 is, I just can't make the upgrade without adding a huge development overhaul to the project. And so I've had to keep to 4.6 as well.

I did enjoy that video of your early Unity 5 tests. I didn't catch the sarcasm at first, added to the humor immensely.

[Nition]

[Flatgub]

I think I have a really old version of this on my PC somewhere, its incredible to see how much its changed since then!
Definately Following this!

[Nition]

Thanks! A public release where you can actually buy the full version and play proper single-player and multiplayer games is almost ready as well. I think it's 2-3 months away.