![duelist of the roses card codes duelist of the roses card codes](https://img.youtube.com/vi/Jc9tuGxxQwY/hqdefault.jpg)
The other argument is the amount of clients that we're syncing the animation with. This allows us to mix and match animations as we need to.
![duelist of the roses card codes duelist of the roses card codes](http://www.anotherretrothing.com/uploads/5/1/5/9/51590197/s336765613645824160_p399_i1_w1152.jpeg)
When it does, it tells the "SyncedAnimationControl" script what animation to sync via enum flags. The server looks at this situation and decides what animation to play. For example, P1 wants to attack a card that P2 has. This ensures that the animations are synced across clients. They don't know what cards are passed into it, they just take the arguments, store their initial positions and rotations, and perform the animation.Ĭlients request for the server to play animations. These IEnumerators get passed the arguments for their animations. It's surprisingly simple and has proven to be indisposable.Īll of the "field animations" are actually defined in static IEnumerators. Surprisingly, the system that I'm most proud and that has worked most consistently is my Animation Syncing system. So far, it's working fairly well but I do need to test it more.
![duelist of the roses card codes duelist of the roses card codes](https://i.pinimg.com/originals/d9/e1/c6/d9e1c62321dee393f5be2620dbd8c156.jpg)
I'm manually syncing this data via Commands and TargetRPC calls. That way, the animation is proper by the time the cards come in from the server. Before the player asks the server for cards, it tells the deck screen what our last drawn hand is so it knows what the hand looked like before we asked to draw. The server (DORGameManager) also stores the last state. The player still stores their _LastDrawnHand but it's no longer a sync list.
#DUELIST OF THE ROSES CARD CODES CODE#
I ripped most of that code out and opted for a much simpler approach. There's also occasions where there would be tragic mismatches that would cause exceptions. Then, by the time the data is actually sent the Player forgets they were even waiting for it. For example, the server tells Player 2 to wait for 5 cards and the event is called 3-4 times. There were race conditions and many reasons why this didn't work. As Player starts receiving items on the SyncList callback, it tallies up the changes and when the changes match the amount of cards we need, then we show the screen. Player says "OK server, I'm going to be waiting for 5 changes to my SyncList over the network"Ħ. Server tells the Player, "Hey, you need to wait for 5 changes on your SyncList before you show the drawing animation"ĥ. Server draws 5 cards from the deck and assigns the Player's "LastDrawnCards" (SyncList) to what they are.Ĥ. P1 tells the server (DORGameManager) that I need 5 cards from my deck.ģ. P1 looks at their last drawn cards and counts how many cards they need. Then, I thought I would be clever and make the hand sending a two stage thing:ġ. For example, I would sync the Player's last drawn cards (size of 5) and then get 6 messages in the callback: 1 clear, and 5 adds. Before yesterday, Player 2 definitely could not draw any cards and there were numerous syncing issues between the local state & network stored state.Īt first, I thought I could sort this out with SyncLists but those are even MORE of a problem than what I was trying to do. It still kind of is, but it's much better than what it was before yesterday. Sure enough, my code base had it and tweaking my code to follow recommended guidelines made this feature more stable.Ģ. These guidelines didn't exist when I started the conversion and provided solid examples of improper code. Card Faces/Holo/Card Pos (ATK/DEF) were Synced via SyncVars, but were NOT following the recommended guidelines for SyncVar ease of use. Some of the most major bugs I recently fixedġ. But then, there are days like yesterday where the entire game is buggy and nobody is quite sure why because it worked last time I played it a few months ago! The current state of the game is interesting because some days, I can play a few games against myself over a local network without any major bugs. Most of this has been figuring out and testing on my own! Not to mention if you have any problems with this library, because the keywords are so similar to Unity's old HLAPI/LLAPI, you end up getting people asking the SAME question but for an outdated tech stack. I chose Mirror because it was popular and recommended, but the problem is that documentation is actually somewhat poor. The Duelists of the Roses remake project currently uses Mirror as its networking stack. Though it's a simple game, networking introduces way too many challenges, like state syncing. Well, I grossly underestimated the work it would take. And when it all worked better than I expected, i felt more than confident enough to actually make this conversion work.
![duelist of the roses card codes duelist of the roses card codes](https://jogos.enternauta.com.br/wp-content/uploads/2012/01/yugiohto31.jpg)
When I started this crazy idea, I didn't even think it was going to work. Now that I feel the UI is at a solid point, I've moved back over to what I've been sketched out the most by: the netplay conversion of the game I created last year.