![]() If however you want tiles to be able to discover for themselves who their adjacent tiles were, you could script that in too. Doing it manually may take all of 5 minutes to do, however tedious it might be to punch in the values on each tile. If it’s just to ship with a single regular ludo board design, then it’d be quicker to punch in the details into exposed (serialized) fields of the inspector of a bunch of game objects that make up the tiles, than it would to create some way of automatically deriving them. ![]() The features you plan to support will help determine what data structures you’ll need to create and reference. ![]() What’s your end game (rhetorical question). I would say yes there is, but I would also say, is the effort to do so going to be worth it? The good thing about creating a somewhat generic movement pattern like this, is you could create some custom crazy ludo board designs, and so long as the chain of tiles around the board can still figure out where it is placed, and where the next one around it is, the game code could automatically adapt to it - maybe a future advancement to consider once you’re happy with the base game. For example, I forget the rules of the game exactly, but I believe there’s a branch off one of the tiles to go up to the “end zone” for a coin, but you’re only allowed to enter it if rolling a specific number like 6 or something? The Move() code for the coin would then need to take that into account when querying the current tile for its properties and determining if it’s the right type to make these conditional decisions or moves.īut you can figure that out and add it in once you get the basic board movement sorted out. Something like that would let you handle the situation somewhat generically, at least until you get to any exception circumstances. Repeat for the number of tiles it has to move. Then the coin queries its current tile and says “hey, which one is next?”, gets the result, then queries the next tile to say “where are you?”, and then animates towards it. The coin would then want to animate its movement to each subsequent tile and so you probably want to represent the board of tiles in memory somehow (or just reference their game objects) and have each tile able to say which the next one is going to be. The coin/token could be responsible for its own movement, if it has (say) a Move(int tiles) method on it that can be fed the dice roll each time: Move(1), Move(4), Move(6), Move(2), etc.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |