Construction script or seeded random.

privateunlimited

Hi. I was hoping someone could help me figure this one out. In UE4, I am making a Ludo game (basically a board game for two to four players, in which the players race their four tokens from start to finish according to the rolls of a single die). I am not sure where to start in the blueprint, I did some research on how can I make the platform and made something like image1 using construction script. I am not sure if I can make all the movable tokens using construction script also are there any drawbacks of using construction script, if yes please suggest some better solution by which I can control all 16 tokens turn by turn. I came across this seeded random command, unable to find enough on the internet about this, please let me know if this will work and please suggest any good tutorial that explains how to use it. Also, should I keep all the tokens in one Blueprint so they all share the same logic? Could anyone point me to a solution? Thank you.

Obscura

You should have a blueprint that contains 1 token not all. Construction script is good for initialization only.

privateunlimited

Obscura said:

You should have a blueprint that contains 1 token not all. Construction script is good for initialization only.

Thank you for replying, i am concerned how would i place that token in desired locations 

Obscura

using set actor location node, through another actor that actually controls the gameplay.

Obscura

If you make a blueprint that properly implements tokens, you only need to make it and wire it once. On the other hand, if you do it like you did, you will need to hand-hard-wire all of them. Thats a really bad practice because all of them can share and use a unified logic.

What you have currently, is like having a bunch of skeletal mesh characters inside a single blueprint in case of a multiplayer game. Even worse, all things are controller from within a huge, messy blueprint. If I understand your current setup correctly. I would suggest to break down things into simple managable part. Like having a token actor, and a separate gameplay actor for example.

Another example: token vs stack of tokens shouldnt be the same thing as they need to act differently, so its better to implement them as 2 different blueprint classes.

About the "random seed" - Thats a type of data called random stream, which has an integer property that is called the seed. You can make a variable in your blueprint, set its type to be random stream. Then, there are several related nodes. Random float from stream for example. You can hook up the random stream variable, and the random float generator will return the exact same random number, until you change the seed.

privateunlimited

Obscura said:

If you make a blueprint that properly implements tokens, you only need to make it and wire it once. On the other hand, if you do it like you did, you will need to hand-hard-wire all of them. Thats a really bad practice because all of them can share and use a unified logic.

What you have currently, is like having a bunch of skeletal mesh characters inside a single blueprint in case of a multiplayer game. Even worse, all things are controller from within a huge, messy blueprint. If I understand your current setup correctly. I would suggest to break down things into simple managable part. Like having a token actor, and a separate gameplay actor for example.

Another example: token vs stack of tokens shouldnt be the same thing as they need to act differently, so its better to implement them as 2 different blueprint classes.

About the "random seed" - Thats a type of data called random stream, which has an integer property that is called the seed. You can make a variable in your blueprint, set its type to be random stream. Then, there are several related nodes. Random float from stream for example. You can hook up the random stream variable, and the random float generator will return the exact same random number, until you change the seed.

Hey thank you so much for responding....and also for putting so much effort in making it so detailed.  It will require me some bit of research to understand all that. I am glad that you responded, it certainly has given me an idea of where i should be going just one thing that is bothering me and i am not quite sure if i understood it, which is how do you mean token vs stack of tokens should act differently.... I know i am asking lot of questions, but i dont know anyone who knows all these stuffs and learning whole thing in one go is overwhelming and exhausting. Thank you 😊

Obscura

Ok no worries. I don't know the rules of a Ludo game but I can see that the 4 players has 4 "figures". Maybe I should have called them initial tokens or group. 

Now how you would implement that, is to have a thing that is next to the board for every player and those don't need any logic, its just for displaying the amount of them left. The actual token that is placed on the board may have some logic. So even those should be different classes. Maybe not in such simple case, but usually player objects has logics running on them which can take performance unnecessarily. they could tick...

I hope its more clear now. Basically I would suggest to make separate classes for a lot of things that are different from each other. For more complex things, also look into "inheritance". Unfortunately this is where basic understanding of programming and its concepts comes in handy

privateunlimited

Obscura said:

Ok no worries. I don't know the rules of a Ludo game but I can see that the 4 players has 4 "figures". Maybe I should have called them initial tokens or group. 

Now how you would implement that, is to have a thing that is next to the board for every player and those don't need any logic, its just for displaying the amount of them left. The actual token that is placed on the board may have some logic. So even those should be different classes. Maybe not in such simple case, but usually player objects has logics running on them which can take performance unnecessarily. they could tick...

I hope its more clear now. Basically I would suggest to make separate classes for a lot of things that are different from each other. For more complex things, also look into "inheritance". Unfortunately this is where basic understanding of programming and its concepts comes in handy

Thank you for answering, I need to try this once in the engine. There are few things I am still unsure of but I will understand better once I start implementing it in the engine. Thank you so much for all the time you have spent in explaining this from the basics.