Weekly Shiryo Update from The Shiryo Team #50

Attention Wolfpack, welcome back to another weekly update from our game development team.

This week features our legendary Lead Game Developer, Rick!

He shares with us his latest work progress and gives insight to the obstacles he’s been tackling, it’s about to get techy!

Hey all, Rick (Lead Game Dev) here, it’s great to be back sharing another behind-the-scenes look at Shiryo’s development.

After last week’s update, you know of the 3 major testing changes we have implemented to solve the following issues.

1. Beasts dying too quickly
2. Lack of draw cards
3. Lack of damage to the Avatar

Feel free to read the previous article with details from Connor for more information on the reasoning behind these changes.


These changes obviously needed to be mirrored in our current build of Unreal Engine, and so I’ll be sharing with you today the methods of how I achieved that.

1. Beasts dying too quickly.

This was a rather simple alteration due to our use of a Master CSV file that contains all the card data and parameters.

A small +2 addition operation to the health parameters within the CSV file to all beasts was fortunately trivial to add and then to reimport the Master CSV file back into the UE build.

2. Lack of draw cards.

This required an extra function to be created that would keep track of each player’s elemental type quantity, as well as whenever an elemental card is played and quantity increases.

This action communicated a request to the Match Server and back again to the Clients to “draw” the corresponding number of cards.

A few exceptions to drawing incrementing additional cards include;

– If the player already has 10 cards in their hand (0 cards are drawn)
– or if the player has already played their 5th elemental card of that type — to then revert back to a single energy cost and a single card drawn.

3. Lack of damage to the Avatar.

The simple solution for this change was the addition of the Manual Targeting System to “Lycan” beast card abilities.

The Manual Targeting System up to this point had been a barebones placeholder and was crude in its implementation. It has basic functionality, doesn’t look good, is unreliable, but is generally ‘fine’ for a placeholder.

Now during this time, I had also been working with Connor.

We’d been importing and adding the ability/card animations to the current build, and had started to make our way through the 30PAT cards.

It wasn’t long before we came across some cards that also use the Manual Targeting System.

Card ID 5 (Deal 1 damage to a hostile Beast. Earth 1: Immobilize it as well.)

Card ID 6 (Give Defender to a friendly Beast. Earth 2: Give it +4 health as well.)

It was now obvious that the placeholder would not do, and I needed to move on to the Manual Targeting System as my next top priority.

I was going to need to replace the barebones placeholder system with something with greater functionality… something that was robust and enjoyable for the player (so to include a visual counterpart).

To start, the original barebones placeholder system was fine to act as a foundation, as it was more than adequate for player selection from either side of the board and for RPC communication with the Match Server.

Like all RPCs and player action requests in Shiryo, all actions are checked and verified by the server to ensure that the action is a valid one.

Now the addition of a visual counterpart is another matter, as we are using a dynamic targeting arrow.

The arrow consists of 3 parts.


The (Base) is the initial start (Origin) of the targeting arrow. (Spawning on the active players card in their hand (10 different positions) + the Avatar.

The (Base) = initial position = (A).

The (Head) is the end position of the targeting arrow. The (Head) animation has its own origin of which it rotates around, but its position is tied to the mouse cursor’s screen location.
The (Head) = end position = (B)

The (Line) animation is connected or manipulated by the constraints of (A and B)

Would you look at that… It’s a Trig problem… High School wasn’t a waste after all 😀.

So let’s solve it.

We can set the angle θa to rotate the (Line) around its origin which is (A).

We can set angle θb to equal θa of the (Head) around its origin (B), so that it remains pointing parallel to the (Line).

Any fellow nerds might wonder why we wouldn’t just ‘bind’ the (Head) and the (Line) as a single object so that it’s always parallel?.

Well, that is explained by the (Line) animation. The way to ‘lengthen or shorten’ the plane that the animation is being displayed on, is by changing the Scale parameter of the length axis.

So if the (Head) was bound to the (Line) then (head) would also scale. Which is a result we don’t want.

So instead, we set the origin of the (Line) and scale its (length axis) proportionally to the length of © , (using good old sohcahtoa to calculate the hypotenuse ©).

And there we have it.

Now for the record, I too think it seems a lot just to get the arrow to move with the player’s cursor.

However, I still have some more ‘polishing’ to do with the Manual Targeting System, plus there are some additional offsets to add so that specific cards can be the initial location, not just the Avatar.

That’s all for this week’s update. I sincerely hope I haven’t sent you all to sleep or brought up some old high-school math trauma haha.

But with that, I hope that you have once again enjoyed this week’s ‘behind the scenes’ view, and I look forward to sharing more with you in the future.