Weekly Shiryo Update from The Shiryo Team #53

Attention Wolfpack!

In this week’s article, our ingenious Lead Game Developer, Rick will be taking the spotlight!

Rick gives us an inside look at some of the optimizations he’s implemented to enhance our gaming experience.

Hey Wolfpack, Rick here again (Lead Game Dev), thrilled to once again share with you some more behind the scenes development here at Shiryo.

Over the past few weeks, my focus has been on the ongoing design and implementation of various card abilities. We currently have 225 cards (with more to come), each with an array of functions that vary in complexity when creating them.

Today, I’ll be talking through some of the intricacies of developing our card functions, showcasing examples that range from simple to intricately layered.

So, let’s dive in and explore the fascinating dynamics of our game’s development journey!

To start with, let me show you an example of some of the differences in our card functions.

Card ID — 1 (Earth Energy)
Ability Description — (Increment player’s Earth Energy value)

This card’s “ability” is simple and only has a single function – (Increment the players Earth Energy value).

There are substantially more “functions” that happen when this card is played, animations, sounds, anti-cheat…etc but these are shared by all played cards.

In regards to the unique gameplay function of the card, it is rather simple.

Card ID — 6 (Stone Shield)
Ability Description — (Give Defender to a friendly Beast — Earth 2: Give it +4 health as well)

This card exemplifies the concept of ability “complexity”.

In contrast to the card above, Stone Shield has multiple combined functions. It involves initial conditions that need to be checked, decisions to be made, and includes a targeting function.

When you start to add up the number of different functions necessary for all the cards, it quickly becomes an extensive and seemingly never ending task list of functions that need to be coded.

Reducing the total number of card abilities would certainly shrink the task list.

However, this would also reduce the variety of abilities, which in turn would diminish player creativity and make the game less enjoyable. Therefore, this “solution” is not an option we would ever consider.

So, what strategy can we implement to reduce the task list?

A major optimization can be achieved by identifying functions that are shared by multiple cards or by grouping abilities that are fundamentally similar with regards to the code.

By designing a “generalized” program that contains these grouped functions, we can reduce the total number of ability functions.

This approach aims to encompass a wider range of abilities within a streamlined coding structure.

A simple example of this would be grouping all the (Gaining Health) functions shared by multiple cards.

Card ID — 2 (Barkskin Pup)
Ability description — (Earth 1: Growl: Gain +2 health)
Card ID — 6 (Stone Shield)
Ability description — (Give Defender to a friendly Beast. Earth 2: Give it +4 health as well.)

A more complex example of a generalization I’ve implemented is grouping together all the different ways an ability targets.

This includes buffing a friendly beast, damaging an opponent’s beast, targeting randomly, affecting multiple adjacent beasts, and more.

However, not all card abilities can be grouped together this way. The key factor is whether it actually makes the coding process more efficient.

If there is a unique ability or if multiple similar abilities exist but the code structure wouldn’t optimize productivity, generalization may not be beneficial.

Here’s an example of some of the exceptions.

Card ID — 51 (Gaia, The Saviour)
Ability description — (Earth 5: Poisonous, Can’t attack, Taunt, Must be attacked first)

The highlighted part of the ability description contains a set of functions that don’t “group” with any of the other current cards.

Therefore, the extra time needed to generalize the function would be counter-productive.

Instead, an ability exception is created for Card ID 51, which is executed solely when this card is played.

There will still be a significant number of ability exceptions, as not everything needs to be generalized. However, as new cards are introduced to Shiryo, further groupings of abilities will emerge, allowing for even more optimization.

That wraps up this week’s update from me! I hope you’ve enjoyed this bts view of some of our optimization processes and I look forward to sharing more with you in the future.