Working on a game like Thrive, but 3D , but I have came into an issue, which is WELDS!
WELDING PROBLEM 1 (between cells)
All cells of the organism eventually connect to the Core cell, with each being welded to each other, but an issue is where to weld them together.
Here’s an example of a whole organism: (all are connected to the core, but all cells are the same texture as we haven’t made any other models for other cells)
(red sqaured indicate connections, where cells can connect to other cells. This is only visible in the editor if a certain setting is on, so that the next cell is placed to the closest connection to the mouse)
As of current in editor, everything is anchored. This cannot work in a match since organisms have to be moving AND have to be effected by collisions.
While the whole organism of a player will be a model, it doesn’t necesary mean it’ll be welded, and I don’t now what heirachy to use for welds.
WELDING PROBLEM 2 (within cells)
A cell is not one part, but many several parts, with the largest in size being the PrimaryPart (for radius finding reasons)
But inbetween cells, they have to be welded to themselfs.
How can i effectively weld stuff inbetween cells without strannge clipping behaviour?
(I don’t need code examples as I can do that myself, but I need help with theory on how to make algorithmns for the previous 2 problems)
Welding doesn’t change positions of parts and should do any clipping, you can just weld the parts together to make a cell.
For the connecting issue, since you already have red squares for the places that cells can connect to, weld the red squares to the main cell, then weld the same red square to the connecting cell.
The red sqaures are just for help with debugging, since they really just represent Vector3 values that these two functions work out:
local function getAtta(model)
local cyto = model.PrimaryPart
local cSize = cyto.Size
local radius = math.max(cSize.Z, cSize.X, cSize.Y) / 2
return
{{
cyto.Position + Vector3.yAxis * radius,
cyto.Position - Vector3.yAxis * radius,
cyto.Position + Vector3.xAxis * radius,
cyto.Position - Vector3.xAxis * radius,
cyto.Position + Vector3.zAxis * radius,
cyto.Position - Vector3.zAxis * radius
}, radius}
end
local function cacheAtta(model)
local caOLP = OverlapParams.new()
caOLP.FilterType = Enum.RaycastFilterType.Exclude
caOLP.FilterDescendantsInstances = {model}
local attadata = getAtta(model)
local ascosciated = CachedAttachments[model] or attadata[1]
for i, atta in pairs(attadata[1]) do
local inArea = workspace:GetPartBoundsInRadius(atta, attadata[2], caOLP)
for i, atta in pairs(ascosciated) do
local inArea = workspace:GetPartBoundsInRadius(atta, 1, caOLP)
if #inArea > 0 then
ascosciated[i] = nil
end
end
CachedAttachments[model] = ascosciated
end
end
But I suppose your idea will work if I make the parts invisible and have them do the same task you suggested.
A bit off-topic, but since the Core will have the LinearVelocity, and all parts are eventually welded to the core directly or indirectly, how can I make sure the entire organim is a set speed no matter number of parts, and how can I make sure that when the organism is moving, it isn’t off-center with the controls incase the organism’s cells aren’t in parrarel / even on either side.
edit: forgot to mention, the red sqaures are exactly where welds aren’t needed, since they only exist between cells and empty spaced. I.E there are no “red sqaures” inbetween the cells.
So if you want to connect the cells, find the position on which the parts collided, add a part on that position and weld it like i mentioned before with the red squares.
For controls i assume you want them to be in the center of the model. For that you take the width and height of the whole model, divide both of them by 2, and you have the center of the model. I hope this is what you were wondering about
Another issue that may happen, if a cell is deleted and cells welded only to it no longer have an indirect weld connection to the Core, meaning it would just experience gravity like any other part and fall straight down the map.
Only possibly algorithmn I can think of this is looping through the entire weld tree and seeing if deleting a certain cell interupts this weld tree and leaves other cells out of indirect weld connection with the Core.
I know the theory for this, but I’m worried about performance problems with pretty much looping through every connection / cell each time weld tree has to be checked
Controls would be based from the Core, which is like a regular cell but only 1 of these can exist per organism, and possibly for most builds, they would not be in the center.
If you want to delete a cell either just disconnect the other cells and have them float around until they reconnect (idk how the game works) or connect the loose cells to the closest cell.
Deleting cells happen in the editor, where everything is anchored, and reconnecting all loose cells would cause many problems, expecially when its a misclick and then the entire build is ruined.
Each cell has its own properties, that includes the Core cell itself. Doing this random swapping of cell types would just disrupt game smoothness and reliability
If you want the core to be the control cell, its going to be the control cell and not much you can do about it other than trying to prevent unbalanced models.
The editor is what the pictures from the original post were from. Its where the user designs their organism, where physics is not needed since everything is static.
If the user tries to delete a cell that has other cells attached to it, have them verify that they actually want to do that. For the mechanics i suggest you to just delete the other cells that were held on by that one cell to prevent other issues. If you don’t want to do that, you’d have to reconnect them and that is gonna take a lot of time and its gonna have a performance impact.
Hmm, or I could go the route that Evolve by @ClanAtlas works (similar to my game, but made in a 2D environment with cubes instead of a 3D environment with spheres), where the user flat-out can’t delete the object. But this may have a high performance cost when trying to delete something, but certainly less than reconnecting everything I suppose.
Yeah so either don’t let them delete it, have them verify that they actually want to delete it and remove the other cells attached or have the whole model basically recomputed.
excludeCell is the cell that will be deleted, and this function is run to ALL of the cells before the deletion, only if all of the returns from all the cells return true, then excludeCell can be deleted.
Haven’t tested it out yet but the theory works out. Only problem is that this has to loop in EVERY cell (Apart from core obviously) and has to loop until it finds a connection through brute force.
, but I have came into an issue, which is WELDS!
