Shoot for the Stars Devlog 36: Huds and Maps and AI, Oh My!
Hello Everyone! As a reminder, devlogs will now be on a monthly schedule, posting on the last Friday of every month. We have changed the format now that we have a different schedule. Where we won't be including skits anymore, we've decided instead to have a unique cover image with more details included. Where they may be less frequent, mark our words though as this now means you get one giant devlog full of juicy information! We have now split the devlog into The artistic side as well as the technologic side, this time with write ups from all 3 members of the team. Grab yourself a hot beverage, sit back, and enjoy our month long stride!
Rob C. Miller
Lead Illustrator/ Game Design
Since our last update via Devlog, one of the things I’ve worked on were some of the last of the concepts needed for the game’s demo. This included room layout and a top down view of everything in the room. This is done so Kayla can model the room so I can add on the official linework for the scene before handing it back to her to color and render.
Speaking of linework, I also finished all of the linework needed for the game’s intro sequence. This sequence briefly shows each of the game’s major characters as they get ready for school. With this done, I handed it off to Kayla to color and render.
I also finished off a few card images needed for the demo, as well as a few others. One of the newly finished cards is a boss card. If you’re reading this on release, I may be revealing that card fairly soon in our Discord server’s Card Reveals channel.
Lastly, my big task at this time is putting the game’s story together with the help of our Event Editor application. I just finished stringing together the entire intro sequence. After reviewing it with my team, we’re all pretty satisfied with it.
One of the tasks I’ve been working on are the event stills in the game. These are the “special” subtly animated stills that show during important moments of the game. Specifically I’ve been modeling the backgrounds from Rob’s concepts in Blender, as well as color and animate them. I usually color them in Clip Studio Paint and animate them in Spine afterwards. Recently, the animated scenes that show at the very start of the game have been completed.
I have also been redesigning the isometric background after we decided to reconstruct the overworld map. Seeing how most of the Cards and Comics shop was already complete, I decided to go off of that background and essentially “pivot” the angle to match our new, true isometric angle. We came to this conclusion after carefully looking over the overworld's existing map, and found the "double isometric" often was too easy to cross into intersecting sort lines on the map. In the back of our minds, we had a feeling we may need to go to a full "true" isometric, but wanted to first try a more unique approach in it. Seeing how the first idea didn't work out, we instead went to our backup plan and plan out a "true isometric" view. Not only that, but when overlooking the map, we found the texture sheets where absolutely enormous and were eating way too much memory much like a gluttonous kid eating too much candy on Halloween night.
After witnessing that personal horror show of a memory drop, Together, Ryan and I started "cutting" the map into literal chunks, which greatly reduced the size of the texture maps for the overworld. We love to consider all our wonderful gamers out there, even the casual players when optimizing our game's FPS.
I’ve also been working on card artwork specifically for cards that will be seen in the demo of the game. I went back and refined some existing artwork as well as reconcept some of the already existing ideas we had for the cards. One of my personal favorites being in the works currently "Ferocious Flame Feline."
Lastly, we've been doing some serious clean up in our game's Asset browser and well, I may have stumbled upon a very peculiar picture. o_O;;
Glad to know Sky's puppet no longer has to suffer XD.
Programmer/ Game Design
Last I left you guys, we had discussed the inclusion of UI hover elements for the cards on the battlefield. I promise the past month has not gone to waste, as quite a few new elements have now been included in the game, as well as some massive overhauls to other internal systems.
We’ve finally begun work on battles running through their natural flow. The very first task to make this happen was giving the player a way to select cards from a list. I designed a new window that could take in a list of cards as well as numerous arguments to determine the way the user is limited to selecting from those cards. This allowed me to give players the option to select their starting Reserve cards, as well as giving the player the option to mulligan their opening hand. Suddenly, just like that the entire opening procedure to a battle was complete! (This isn’t completely true, but hey. Let’s think positive, ok?)
I next found myself neck deep in the trenches of an individual player’s turn. Upon simply waking all cards on the turn player’s field and giving both players a Willpower during the Wake Phase, as well as making the player draw a card during their turn, I was feeling rather mighty. After all, all this functionality was already in the game. As I braggartly sat there, waiting for approval from my colleagues for my hard work, my heart sank as they reminded me of how the player needs to have the option to draw an extra card at the end of the draw phase.
I was suddenly at the foot of another mountain to climb. I had to design another window for the player to make confirmations with. While a little fatiguing, it was nothing I hadn’t done already, but as I was working on the window I slowly came to the realization that the TaskManager we had discussed in our previous devlogs wasn’t up to the task. (I’m Sorry...I'm not sorry.)
It was apparent that while the TaskManager was functional from a theoretical standpoint, the implementation was lacking. My first mistake was the implementation was using a queue to store the tasks in waiting. The last in, first out approach of a stack is a much more appropriate data structure for this type of work, as it allows tasks to be more modular and most importantly in this case to be able to branch logic.
Swapping from a queue to a stack was a painless transition. The more difficult change was fixing the disgusting way sending events to the TaskManager was handled. I’m sorry to say this code is too explicit for the kids reading this devlog. I decided to improve this by creating a subscription system for all my battle listener objects. The TaskManager contains a hash map, made up of keys that listeners can subscribe to by providing it function pointers for an action to complete, and a ready check for that event where applicable. As the TaskManager is a Singleton, any object is capable of pushing tasks, which the TaskManager will continuously pop a new task to run each frame. So yea, basically I reinvented the wheel and made a standard event system! You wanna fight about it?
Upon changing the entire way the TaskManager worked and crushing every trace of the old system’s implementation from the game’s architecture, I was able to complete the new confirmation window with ease. The team’s attention was then redirected back to the map portion of the game. On my end it was time to finally include the HUD!
The display elements of the HUD itself was fairly simple and more of the same implementations as previous objects in the game. The problem came when I realized the state machine I had built was not sufficient for creating new objects in states that were not the topmost state. While the fix to this problem was far more simple than that of the TaskManager, it was scary to make such a drastic change to an object which touches or is touched by almost every other object in the game. Needless to say, the transition was fairly painless, and we now have this beauty to show for it:
Lastly I had returned to the battlefield. While still a work in progress, my new project is bringing everyone’s favourite TerraZone club president to life. Seon already is making some interactions with the game by himself; however, I’ve rambled enough for one devlog. Tune in next month to find out more about the AI if SeoNet has not enslaved humanity by then!
Thank you everyone for tuning into another update. Ready to see how smart Seon gets? Or perhaps some new Maps in the town? The next big update will be 4/30/2021. Make sure to follow us on Twitter for all the latest updates. The demo gets closer and closer to complete with each passing week, so see you next time TerraZone Fans!