Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1109899 Posts in 46247 Topics- by 37865 Members - Latest Member: 321-RG

April 18, 2015, 03:37:33 am
TIGSource ForumsFeedbackDevLogsScraps - Vehicle combat with buildable vehicles
Pages: 1 ... 12 13 [14]
Print
Author Topic: Scraps - Vehicle combat with buildable vehicles  (Read 28395 times)
Nition
Level 2
**


Some random guy


View Profile WWW
« Reply #260 on: February 21, 2015, 02:28:56 pm »

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

Nition
Level 2
**


Some random guy


View Profile WWW
« Reply #261 on: February 21, 2015, 04:27:44 pm »

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

https://www.youtube.com/watch?v=gUujEe3uqns
Logged

Nition
Level 2
**


Some random guy


View Profile WWW
« Reply #262 on: March 01, 2015, 06:26:59 pm »

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

Nition
Level 2
**


Some random guy


View Profile WWW
« Reply #263 on: March 02, 2015, 06:16:45 pm »

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

Nition
Level 2
**


Some random guy


View Profile WWW
« Reply #264 on: March 15, 2015, 01:52:18 pm »

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

eigenbom
Level 10
*****


@eigenbom


View Profile WWW
« Reply #265 on: March 15, 2015, 02:52:41 pm »

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

Nition
Level 2
**


Some random guy


View Profile WWW
« Reply #266 on: March 15, 2015, 03:47:45 pm »

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

The Uber Cannon
Manbaby
*



View Profile
« Reply #267 on: March 23, 2015, 06:55:28 pm »

Game looks really fun. Is it ready, or is it still under development?
Logged
grinmore
Level 0
*


I make fun.


View Profile
« Reply #268 on: March 23, 2015, 07:39:44 pm »

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...
Logged
Nition
Level 2
**


Some random guy


View Profile WWW
« Reply #269 on: March 23, 2015, 07:49:41 pm »

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
Logged

grinmore
Level 0
*


I make fun.


View Profile
« Reply #270 on: March 25, 2015, 11:06:31 am »

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.
Logged
Nition
Level 2
**


Some random guy


View Profile WWW
« Reply #271 on: March 25, 2015, 12:09:41 pm »

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

Nition
Level 2
**


Some random guy


View Profile WWW
« Reply #272 on: March 29, 2015, 01:11:28 pm »

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

Nition
Level 2
**


Some random guy


View Profile WWW
« Reply #273 on: April 11, 2015, 09:55:47 pm »

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

Pages: 1 ... 12 13 [14]
Print
Jump to:  

Theme orange-lt created by panic