Implementation help for Train Game

Arbee

Hey, I need some Ideas for my Game I'm trying to do. I am currently creating Train Tracks with Path3Ds that can be placed by the player using raycasts from the camera to the "Ground" mesh, but I don't really know how I'd properly do junctions. I thought about splitting the Path into multiple paths on every junction and save the points where junctions are in an array or somthing similar and then create a PathFollow3D by combining these Paths into yet another one which describes the full way the train needs to go from Point a to b. Is that how you'd do it or is there a better way?

Secondly I'm currently using MultiMeshInstance3D to create the track planks, but it behaves very weird when I add multiple tracks to the scene. Could you take a look at the code and tell me whats happening?

And lastly my code which adds new Points to the path is very messy rn. Do you have some sources where I can get inspired on a building system? Preferrably some open source project doing something similar.

(I'm using this project more as a learning opportunity rather than a project I want to release soonish)

All my code is on GitHub in the "development" branch: https://github.com/Arbee4ever/Train-Game/tree/development

award

Arbee Hey, I need some Ideas for my Game I'm trying to do. I am currently creating Train Tracks with Path3Ds that can be placed by the player using raycasts from the camera to the "Ground" mesh, but I don't really know how I'd properly do junctions. I thought about splitting the Path into multiple paths on every junction and save the points where junctions are in an array or somthing similar and then create a PathFollow3D by combining these Paths into yet another one which describes the full way the train needs to go from Point a to b. Is that how you'd do it or is there a better way?

I think it will help if you tell us a little bit more about how you want the player to be able to create junctions. How do you want that user experience to work in your game? That will affect what is the best way to approach implementing junctions.

Arbee

award I'd like the junctions to be created by clicking on some point on the path and then clicking on a point somewhere else.

award

Gotcha. I think a good approach would be to use a graph. Think of your junctions as the nodes in the graph, and the tracks as the path between them. So for one piece of track, you'd have:

Junction A {
    neighbors: [
        { Junction B, Track AB }
    ]
}

Junction B {
    neighbors: [
        { Junction A, Track AB }
    ]
}

Create another track from the middle of that one, and you'd have:

Junction A {
    neighbors: [
        { Junction C, Track AC }
    ]
}

Junction B {
    neighbors: [
        { Junction C, Track BC }
    ]
}

Junction C {
    neighbors: [
        { Junction A, Track AC },
        { Junction B, Track BC },
        { Junction D, Track CD }
    ]
}

Junction D {
    neighbors: [
        { Junction C, Track CD }
    ]
}

and so on. You'll still want to store your junctions in a dictionary or array for quick access to whichever junction you need quick access to.

I'll look into your code for your other questions too, but it's late where I am and I'm going to bed first. Maybe someone else will get to it before me, maybe not.

award

Looking at your project now. It seems like all of your instances are sharing one multimesh, including the "preview". The code for extending the track also seems to have a bug causing it to be unable to extend from the end point properly, only working when I click a point in the middle.

I think it would help to separate the model, view, and control for what you're doing. The model, i.e. the data, is just the path or graph of paths that you want representing your train tracks. The view is the 3d meshes being placed according to the model. The view doesn't need to have any functionality other than to look good. Then your control is selecting your track and clicking to place points. When the player does that, you update the model (the path) and then regenerate the view (the meshes).

Currently you have each object controlling how it is placed when the user clicks, and most of them seem to fail to interact with the path. It's very messy and difficult to manage. Instead you should have one single script which is responsible for translating user input into path data.

I would advise to tackle one part at a time. The most important thing is making sure your path works correctly. I'd suggest watching this tutorial. It shows how to extrude a CSGPolygon3D along a path. Keep in mind that CSGPolygon3D is too expensive and inefficient for an actual game. Its best use is for prototyping. You really only need to get working the "road" that it shows in the tutorial. You just want to see that you are able to properly generate good paths.

When you are laying down a path, I suggest using a "state" enum or a bool to represent what the user is doing. When the user clicks to start a path or path segment, we see from the state variable that we aren't constructing something, and so we begin constructing and then switch the state. Then, when the user clicks again, we know that they are finished, and at that point we actually apply our points to extend or create a path.

It can be very helpful when in the "construction" state to see some real-time indication of what you are doing. The way games often handle it is by drawing out the track piece you're about to create, but we can start simpler by just drawing a line while the user is constructing a segment. It will help the user see what they are about to create, and it will help you debug your path generating.

Once your paths are working properly, then will be a good time to move onto procedural mesh generation or to actually moving the train along your tracks. For moving the train, again I would suggest the concept of a graph of junctions. The train can follow a path from junction to junction, then switch to follow the next path to the next junction.

I hope this helps at all. I'll try to help more if you have questions on how to do a specific thing.

Arbee

award It seems like all of your instances are sharing one multimesh, including the "preview".

How would I avoid that?

Arbee

Arbee I think I was able to do it by checking the "Local to scene" checkmark