Monday
On Monday to get things started, we started with our regular ‘beginning of the week team’ meetings, standardly covering our tasks for the week, any organization and double checking schedules for other team meetings (such as an awesome design meeting on Tuesday we had coming up with Marcin, who’s now our full-time Chief Creative Officer) and scheduling our team meetings and 1-to-1 sessions.
Afterwards, the appropriate tasks were allocated to each member of the development team. Tomat continued with the animation system and Connor had been creating and making prototypes for some amended animations we’d discussed last week.
After which I continued with AWS work (specific detail on this towards the end of this article)
Tuesday
Then on Tuesday we had a meeting that lasted around half of our working day with the Game Development Team (Shiryo Studio) and Marcin. During this meeting we discussed modifications and gameplay to Frozen and Thunder element cards.
Part of this was due to the ability ‘Frozen’ and ‘Immobilize’ needing some discussions — as their actual in-game appearance was too similar and something was a little lackluster.
See when you take Fire — which if you recall has the inner fire ability, and Earth which has poison, they’re really cool with lots of small detail. Along with this the actual way you play the game with them is very interesting from the animation style to the gameplay. They simply look brilliant and play brilliantly in the game.
However when we looked at Frozen and Immobilize — they had a similar kind of look to them which was a problem. Also Frozen’s gameplay was relatively weak compared to Fire or Poison.
Then when we looked at Thunder as an element, the main elemental animation was supposed to be ‘Rapid Attack’, which in practice rapid attack was a lot more suited to be neutral movement — a generic ability across all types that any kind of elemental card could do. It wasn’t really capturing what we’d envision as opposed to looking like a dedicated Thunder attack. It simply wasn’t enough.
After significant discussion, debating, brainstorming and concepting — we had to do some mental gymnastics and in the end we went with the choice to modify Frozen and Immobilize animations to differentiate them and make Frozens gameplay far more interesting.
With Thunder elements, rapid attack is now a ‘minor’ ability of them. Rapid attack will be used by quite a lot of the Thunder element cards as they’re meant to be fast playing type cards, they’ll move very quickly — and we made a more interesting ability for Thunder which for the time being we’ve called ‘Charge’ (which we’ll be asking for community input on changing and finalizing the name)..
It’s a lightning ability that will have a large area of attack, so instead of hitting one card it’ll hit multiple. If you can imagine a card using the ability “Charge”, one of the configurations might be, to hit *adjacent beasts* with a ‘cascading’ lightning animation conveying this kind of ‘Chained targets’ in the attack.
Rapid attack will be aimed more now as a utility ability that can be used by almost all types (but Thunder elements using it more often). In the same way any elemental card can have growl — Rapid attack was more suited as a wider used ability, given Rapid Attack just means instead of waiting a turn it can attack right away when your card is placed on the board.
Kind of like the way a lot of beasts in Pokemon can learn ‘quick attack’ but not all cards can learn ‘Hyper Beam’ which is a strong signature elemental attack. You wouldn’t use strong elemental features with every kind of card, and we needed a more definitive attack for the Thunder types.
Tomat then created a design document with these changes and Connor then began conceptualizing and prototyping out a lot of ‘chaining’ lightning thunder animations. They’re already looking pretty great.
Wednesday
On top of the above we’ve had to work a lot on our written work — as we had quite a lot of internal criticism on things like card description names and ability names, the descriptions were heavily made to support the artists during the creation process of the wolves. Our full descriptions in our sheets contain art description then an actual ‘about’ description, and if you read through there’s a lot of repetitiveness (i.e this is a Wolf from Edra repeatedly written), since many different people would read many different wolves so a lot of information needed to be repeated.
There are also thousands of individual pieces of writing that need to be done, like whenever you hover over a UI element such as the start button, a player character, the hero, a card, main menu system ect, anything like that for good UI and UX you typically want a system that when you hover over an interactable display or element, you hover your cursor for a few seconds and a pop up will come up giving you a small description of it.
Now you can imagine how many ui / ux elements and pieces are needed, it’s literally a thousand different pieces and it needs to be written up in a matching style across them all, and you maybe even want easter eggs in there. There would be emotes, instead of just directly talking (because voice chats aren’t typical in a card game), you use emotes instead. These will have character voices, a happy one, sad one, angry one, bored one etc, and we’ll want these to have a voice actor play them eventually, along with a written element for just reading it. As well as these we have the about sections of the wolves (mentioned previously) future wolves, internal game lore (and more Shiryo knowledge).
One of the ideas was instead of solely using the Shiryo team was to see how a professional writer would do. As such I’ve interviewed a professional writer and asked them if they wanted to dabble and test out writing some of these descriptions — after of course reading EVERYTHING about Shiryo, our manga, lore, website, full card collection, then review the first 5 cards and test write new descriptions and start refining what would be a theme/style for Shiryo’s Art and information.
Thursday
Unfortunately I suffered from a personal issue, I occasionally get chronically severe migraines which of course isn’t ideal given I work on computers which can exacerbate them. As such I was personally out of action for personal tasks on Thursday, however I was able to oversee and communicate tasks with other team members.
Connor was working more on the animations we’d discussed above — and Tomat was continuing with the coding of implementing the animations into the game in a very complex CSV driven system.
The CSV System: It’s a large system that we attach all animations, textures and card info to, so instead of having to write individual code, it’s a generic system that all cards run through and operate there. Even the skeleton of the cards, how it moves in space, the delays involved and the order in which they fire is all controlled and works automatically and is always scalable with new cards as long as new cards are created in the same compatible format. This allows for easy scaling without having to do further huge updates to the system.
Friday
A lot of time was spent reviewing work the team had done throughout the week (where we’re up to with animation systems etc), allowing me to have better foresight for our next working week. Along with this I had further conversations with our new (potential) writer. I was able to give him a lot of critique and give him new tasks for next week.
After which I simply continued to work on AWS.
AWS Specific Updates
As far as AWS is concerned for this week, I’ve been making good progress, it’s at the point now where the vast majority of the required code base is functional of the newly implemented code — to the point where we’ve started doing local network testing.
The testing has highlighted some bugs that we’re currently working through that NEED to be fixed. Once these are fixed, the remaining code will be able to be added. The remaining functions are basically ‘garbage collection’ (the unassigning and freeing up of resources) and cleaning (any events that weren’t fired off that are now ‘waiting’ that are looping in their checks — are also terminated).
To elaborate, there are certain code functions that are event driven — waiting in the background waiting for the right event so they themselves can fire. Until then the ‘events’ are taking up RAM doing nothing.
In garbage collection and cleaning, you’re freeing up resources from previous sets of code that aren’t going to be used, you don’t want the games client holding onto these events in RAM doing ‘nothing’. Same for animations and textures simply filling up ram. If it can’t clear then you get constantly increasing ram usage just playing the game because you’re not ‘collecting the garbage’ and subsequently lags the game.
Then the final pieces of code are essentially a mix of security (like parental code) so if something unexpected happens — like if you join as someone leaves and you’re left in a game that won’t start, you need supervisory pieces of code that fix outlying issues when they occur.
Typically networking issues, like if a player leaves mid game how is that handled? does the game end? how long does the game wait for player to return? is there a way for a player to be reallocated to their old player controller?
Basically taking care of issues, problems or mistakes, there could be infinite pieces of code like this for every edge case that gets rarer and rarer. They obviously don’t all need to be done at first, but there needs to be a level of robustness even at an alpha testing phase, it’s simply good practice
Currently what’s stopping me from going ahead and implementing those functionalities (last 15% of code) is 4 bugs that are being worked on that are related to this.
Bug 1: When searching for a game there’s a period of time when not only are you searching for a game, but you’re also joinable by someone else searching for a game.
There is a small period of time (a locked period) where you can both join each other, so you swap places and you end up in each person’s own lobby, unable for the game to essentially know this has happened, like a limbo effect waiting for the other person.
It can’t search for a game 10000s of time a second, it looks for a game periodically and if a suitable result is found then it starts the process of requesting to connect and then the joining process. During this period you yourself can be joined by someone else.
So I didn’t expect that initially, there’s a period of time that isn’t ‘miniscule’ where you’ll end up swapping places. This is one of those supervisor outlier situations, where instead of creating code to fix (band aid), I’m amending the underlying code so this is unable to occur.
Bug 2: If you start a game, you join a server — a different server. Think of it as joining another player, so from your lobby (one server) you join another game (another server), so when you finish and end game conditions are met you want to get returned back to lobby you own.
But sometimes it would seem as if your lobby is being garbage collected and terminated with those resources allocated somewhere else, so you can’t return to your original lobby and get stuck in a ‘limbo space’.
And so that needs to be amended, so if you leave your lobby it doesn’t think you have disconnected (like as if you’ve turned the game client off). So I just need to add its ability to check if you’re on another server and retain your own server, it needs to know if the client is still active or not and not assuming it isn’t.
Bug 3: Tied to to the above, sometimes even when you leave a session like a match server, what’s meant to happen is when both clients leave it automatically sends all of the results and info to the portal so we can gather all the data and information we need, then it’s supposed to terminate the session, this includes the unique i.d for session and the player sessions created for it, it needs to reallocate all the data and resources — but sometimes it simply doesn’t.
Sometimes when the end game condition is met and players left, that game session doesn’t get terminated, it’s left in limbo, that starts accumulating, before you know it we have hundreds of unusable game sessions becoming a giant pile, there’s a bug that’s causing it to not terminate which I’m still working through.
Bug 4: There’s a timing issue with packet loss. There’s a small timing window when you join a game, because when two individual players join a game session and obviously because they can be from all over the world – there’s latency involved in the sheer distances of where players can be.
There can also be unexpected networking issues, so sometimes when a player joins a session and is waiting — within the maximum time frame for the second player to join, if the network issues are within a certain timeframe then the data packet is lost. The main result of this is the second player’s cards and their hero don’t spawn, they don’t exist. So the game proceeds to try and load up cards and draw cards based upon players data but the data is missing. I’ve not got any exceptions or code to check for this, then to re-ask for that data.
So right now you can join as a second player with no cards allocated to you, the game will try to play and it can’t, it becomes a stuck loop where nothing can happen.
I’m still aiming to be done with the AWS side of things by the end of next week, however it really depends on these bugs, however we’ll keep the community informed as transparently as we can. Please bear in mind there are still other tasks we need to continue with after this is finished (as mentioned in last week’s update), however it’ll be a huge task that we’ll be grateful to be completed.
