Runtime Building System hints?

Hi everybody,
i searched a lot of threads about this topic but i haven’t found anything useful to create this system.

So what i want is to make a building system like Rust and similar game, not grid-based but free to place and snap near other and correct buildings (eg: foundation snap, pillar on top of foundation, wall, stair etc.)…

So i need some hints to start coding this.
Let’s say for example that:
I place a foundation in the contact point of a hypothetical raycast that intersects with terrain;
How can i snap other foundation on top-bottom-left-right of the original foundation?
Thus, let’s say that i organize my building with some ‘anchor point’:

The raycast is not enough for checking… if i look on top of my foundation, for example, my contact point /end point of the ray is unuseful for finding the nearest anchor point…
This problem is valid for all others: wall? stairs? etc.

The concept is: if i look at a point in open space (air), for example, with a ray of 3 length, the result of the raycast gives me 2 potential informations:
-The contact point intersected with X collider; OR
-The end point of the ray;

So, with a point in open space (air), i can’t find the ‘nearest to snap’, I should cycle all the buildings of that kind in the game (not possible…), in the same way, if i look between 2 pillar in order to place a wall, my raycast endpoint will be in ‘open space’, and that point is not related to any placed building, so, how can i understand if my ray look between two pillar?

Which is the correct approach?

I would like to get this result.

Thanks ahead.

Update: A possible solution is to create ‘triggers’ buildings, so if the raycast hits these triggers i can know that there can be placed X object at Y position… is it too much overkill?

What you can do is model your object in Maya and put joints (I believe they are called joints, maybe called bones?) on each corner of the base object. Then create another object that you want to put on top and put joints on the places where it will snap onto the base. In Unity you can then spawn both objects and then move the object so the joints (which will simply be gameObjects in Unity) are clicked together:)

Edit: Remember to name the joints in Maya to something that makes sense so it’s easy to know which to move to which.

Firstly thanks for the hint, but i don’t need to know where to place the objects… i just implemented in my system the anchor points (base model + upper model), but i need to know the best system to allow players to talk to the system and tell: i want to put this wall here; eg: oh, the player looks between two pillars, so system place the Wall in the Anchor X of foundation Y… or: the players looks near a placed foundation, so system place the foundation snapped near that foundation; how to detect this? Box trigger for all ‘possible buildings’ or something?

Read Edit first this all might be irrelevant hehe

Ooooh! I see what you’re asking now. What you could do is always be looping through all the anchor points and when the player is looking at a location that is closest to two anchor points combined then it would choose that spot as his/her focus point. I confused myself writing that so let me “draw” this :smile: By the way I’m just brainstorming with you here I have no idea if this is the best way to go about this, sorry!

|        |        |
|   x    |        |
|        |        |
+        +        +

| = game object for the wall

  • = anchor point
    x = where player is looking

so if the player is looking where that x is, if you find the distance between the x and the anchor points for both walls, the left side will have a smaller number so you would choose that section as the focused one.

So the same would go for if the player was looking at anchor points on the floor and you wanted to know what section he was looking at. So say this is a grid of anchor points where pillars can be placed (view from top down):

+      +      +

+      +      +
   x
+      +      +

If you loop through the anchor points you’d find that the lower left corner section will produce the smallest number and therefore is the section the player is looking at.

Would this work?

Edit: I re watched that video and it looks like he is just affecting each game object individually so you could just figure out which game object the player is looking at and then affect that game object according to what the player wants to do (for example if he presses b build a wall and if he presses x delete it)

Is that what you want?

This was the first solution that I thought, but there are a lot of problems:
-“looping through all the anchor points”, anchor points of which ‘base building’? if i watch on air with a raycast, it gives me only a point (intersected or not), so i can’t know what he is looking for (foundation? which foundation?)… if you think that there may be 100+ foundation around the scene, i can’t loop all foundation (overkill) to found the correct foundation…;

So the raycast hardly ever intersects the object, in most cases the raycast ends in ‘air’ and i haven’t useful data for found the correct base building for looping his anchor points.

Thanks again!

What about just detecting when the player is looking at the game object and then affecting it according to what the player does?

Sorry, how can i detect that the player is looking a foundation rather than another? What do you suggest me?
Consider this situation:

Thanks a lot for your help!

Sorry I’m still really confused about what the question is:(

If they’re in a build mode could you have a targeting reticule that then aligns with where they want to snap to? Have the snap measure the distance & only snap if it is really close (to allow slight inaccuracies in the player aiming but without having such a wide margin of error that it can’t determine what to snap to)

Mmm, I see what you mean now and how the video relates, but I’m not too sure how to do that :frowning: Sorry!

What do you mean for ‘targeting reticule’?

I’m trying with: trigger snap zone + anchor point:

This works very well, when my raycast hits a trigger zone, if the trigger type is of the correct building type i can snap to his anchor point, then instantiate the building and deactivate the trigger, in the new building instantiated i check if a trigger has a contact with one other foundation and if yes, i deactivate the trigger.

This can works?

I would rework the concept into a two stage anchor point locator. A ray cast and a moveable trigger.

You’ll still use a ray cast for fine anchor point selection but also use a moveable trigger centered on the mouse to act as an “area of interest”. You’ll be able to track colliders as they move into and out of your area of interest instead of multiple triggers per object.

So if your mouse ray cast lands directly on an anchor collider then use that point.
Otherwise use the nearest anchor point in the area of interest to the center.

There’s a few optimization methods that you can then do to cut down the calculations to find the nearest point such as reducing the update frequency of the calculation, ignoring specific collider types and using magnitude values instead of actual distance values.

This is very helpful! Thanks a lot for the incredible hint.
I rewrite my system to work in this way, a question: what do you mean with ‘anchor collider’?

For now, with triggers and a raycast it works very well… but i think that it’s not optimized.

I will test the performance and i will decide if switch to one other system.

http://it.tinypic.com/r/14312px/8

By anchor colliders I meant the specific points on your model where you’re going to do something if a user were to click on that point. In the video the individual anchor colliders would be the posts of the walls, the corner of floors that kind of thing.

Had a bit more time to kill:

To expand on what I mean. The video shows the “player” clicking / highlighting specific areas of the 3d world. Building from the terrain to a foundation, to walls, to stairs into finally a building. There are several behaviors exhibited. First there is a logical progression between structures influenced by adjacent, existing structures. Secondly players can advance the progression by either clicking on areas of the model, clicking off into space or clicking on the ground.

The player starts by clicking on the ground and places his initial piece, his foundation model. The foundation model could be a prefab or procedurally generated. To allow a player to click on a corner for instance there needs to be a point defined as clickable some how. This would be an anchor point.

At each of these anchor points you’d place a box colilder extending upward when it was appropriate for a player to click into space to select a post above a floor. You’d have an underlying collider that would represent an area that if clicked would represent a floor action. So now the player can add walls and floors by having the mouse over a specific area. They’ll be able to commit a build order or change options for that area based on a tree of acceptable options for that area.

As you moved your area of interest trigger around it will either contain or not contain other structure colliders. If you’re on the terrain and clicking then you likely want to place a foundation. As soon as the foundation exists, your trigger area now contains a list of colliders that intersect the area. You’ll have the floor collider, the corner colliders (the large circles) and the midpoint colliders (smaller squares) and likely wall colliders along where future walls would be. The player’s mouse focus point could be over any or none of those colliders at any given time.

Case 1: The player is clicking on the terrain and there is no structure colliders in the target area and the player is centered over the terrain.
Result : Place a foundation.

Case 2: The player is clicking on the terrain and there is at least one structure collider in the area of interest.
Result : Place a foundation snapped to nearest side of the model that is represented by the nearest suitable corner collider’s anchor point.

Case 3: The player is clicking on a model collider and there are multiple structure colliders in the area of interest.
Result : Place a new object based on the collider the mouse cursor point is over. If it’s the floor collider set or change the floor texture. If it’s a corner set or change a new column object on top of the colliders “bottom”. If it’s a column clicked near the bottom change the baseboard. If it’s a column clicked near the middle change it’s style and so on.

The logic to handle the progression can be stored in several ways either with the models or in a tree like data structure. For each anchor point type you could define a list of available options / effect if the player were to click it.

Firstly i thank you for your solution, but it’s the exact same thing of my current system.

The problem as i described above is performance, having multiple triggers for building increase the physics objects:

Actually this works, but for a full game it does not affect too negatively the performance?

If you consider that unlimited buildings can be placed, having triggers for pillars, foundation, ceils and other staffs influence the performance.

Is this a reasonable way?