With last week being reading week, as well as how hard I've been pushing myself the days before, I decided not to write an entry last week as well as go easy with the workload this week. While I'm not saying I sat in bed all day doing nothing, I did enjoy myself and took things pretty easy.

Last entry had finished The AI. So what came after was the clean up. I've spend several days cleaning up the code and finishing simple stuff that I has just put aside and never really got to. I started with Over-world chests. While i had drawn the images before, I not finished the functionality for them. That, as you'll soon read, seemed to be the theme for the past few days. I re-did some of the materials for props that were sitting around as well as added materials to the building tool i made a while ago. I added a shader to the game itself (something to not change the materials but just give everything a cell-shaded look). I finished a story player that now allows me to simply add entries for the game to play out whenever needed. I finished the bit of code that was tasked with inflicting status effects onto units in battle as well as created a system to trigger and play custom battles that relate to stories (these come with custom game-boards that can be fitted to feel properly laid out for the terrain around it). And lastly, I did do alittle more drawing for sprites and battle animations.

While none of these tasks were difficult or all that groundbreaking, I am glad I took the time to finish these smaller tasks. This week, while not all games and fun, was needed. My mind was stressed and i was starting to feel burned out. Now that I've rested, I'm all ready to really get back into working on this game.

This entry is late due to the fact that I kind of already did it? This week I had to complete what my Profs liked to call a "Vertical Slice"- where I take on aspect of the project and complete it to the end. In my case, the Vertical Slice was my AI. The following is the write up i did on it. Cheers :)

​Vertical Slice


As a Game Designer, I was unsure at first as to what would count for my vertical slice. Would going over a single game mechanic be too little? Would drawing all the sprites be too much? For a good two or three days I was at a lost and couldn’t exactly pinpoint what I wanted to call my vertical slice. In the end, it took a friend looking over my shoulder to tell me “Just do that.” And so, I did.
                For my Vertical Slice, I decided to finish creating the AI for my game…as in, all of it: what it does in a duel, on the game board, what cards to pick and when to use them, the whole 9-yards.
 The following is detailed documentation on my workflow and any problems that came up:
 
 I started by thinking about what I needed it to do. Looking up games like Hearthstone, Smash bros, and the like made me realize that a simple list of what to do and not do wasn’t going to be enough. And so…I hijacked the white-boards in the lab.

​The hardest part about planning out behaviour trees like this is boiling down everything into very simple, yes or no questions. I was joking while doing the but the statement I made-I think- I still agree with. “Computers are ridiculously…. Dumb.”
Once everything was out for the world to see, I combed through every branch, thinking of any way an infinite loop or dumb result could occur and rewriting the trees several times, before I was finally happy with what I had.  Then It was time to translate that into code (Or blueprints in this case):

And so I finished with this, Enjoy :)

While it has been a while, I'm not back and ready to work. Over the last month, School's been chugging along and I've been hard at work. Here are the weekly log entries I've written but not had the chance to post until now (Enjoy ;) ):


Glori: Development Journal
Week 1 (Jan 11 2019):
And Thus, I begin…
            This week I started work on the necessities. I already had created my “Map Pawn” last semester while working on my proof of tech, and so I worked around it. I created a landscape based on the map I made during preprod and imported a water material that I created dur a different assignment (also last semester).
After that, I realised that with the day-night gameplay I had in mind, the default sky wouldn’t suffice and so I created an in-game “Time Manager” that changed the in-game time while the player is in the overworld and a custom sky sphere. This sky sphere has a sun, moon and two layers of clouds. The Light being cast from the moon has its light and colour based on how far up it is in the sky (I love the colour and the lighting at around sunrise 😊). Every in-game hour (about a minute of real time), the clouds will shift in density and size as well as direction.
After that, I started work on the encounter system. For now, I’ll create it like the rest of the world, a separate level that gets called in if the map pawn triggers an RNG check. It works but it’s choppy and doesn’t carry over information as smoothly as I’d like it too (also sometimes it just forgets to unload the overworld once the battle level is loaded. The tiles are simple, I placed 19 of them in a hexagonal pattern in the battle level. I’m thinking of modeling different backgrounds based on when the battle level is called but I understand that that’ll be a lot of work. These hexes tiles should know what is on them and react to the player’s mouse.
Lastly, I started white-boxing the area that’ll be present in the demo. It’s not much as of yet (just some cubes scattered around) but it’s getting there.
 
 
 
 
 
 
 
 
 
Week 2 (Jan 18 2019):
TOOLS!
            I’ve changed my mind (on a few things). Instead of modeling all the buildings (or modular pieces for the buildings), I’ve created a blueprint that is similar to a “SIMs” house builder. With this, I can set up every house or building everywhere and I’ll just have to come back and swap out textures later. I’ve also created trigger boxes That’ll determine if the area the player is in is safe or what enemies they could randomly encounter.
            The biggest change I’ve made this week was the choice to change how the battle field is spawned in. Last week, I thought to just load in a different level entirely (think in the style of “Pokémon”, or the older “Final Fantasy” games) but after getting that working (and yes, I did fix those bugs I mentioned last week), I found it too…disconnected from the rest of the world. I changed the hexes to spawn onto the overworld in a cascading matter before the pieces spawn from where the map pawn is (The map pawn hiding at this point) before walking into position. Doing this opens me up to having different board types and giving the player the option to position their units before the battle. Currently, I’ve made 5, pre-set board types: The Hexagon, The Huge-Hexagon, The Doughnut, The Wide Hexagon, and The Tall Board. I finished up the material for the hexagon tiles and used the “Niagara” plugin to add a nice after-image effect to the tiles as they cascade onto the overworld.
            I finished white boxing the village and went into “Substance Designer” and started making materials. I also created a 2D-ish tree actor and was point to place down a forest before realizing how long it would have taken me. So… I created another tool (Much like Unreal’s built-in foliage volume tool) and I had my forest in a few minutes. I ended the week by placing in the invisible walls around the world.
 
 
 
 
 
 
 
 
 
 
Week 3 (Jan 25 2019):
Under the hood.
            This week was a bit less flashy than the past 2. No fancy materials made, no giant new game-mechanic added. I was focused purely on optimizing what I did have and cleaning up whatever blueprints I had….and I sure needed it. While in the moment, with my mind racing and the music going in the background, I tend to be messy with my blueprints, naming conventions and file placements. The start of this week was used up going back and fixing everything that seemed messy. Game actors were renamed. Unused code was cleaned up or erased, Materials were simplified, and settings were tweaked.
            On Wednesday, I decided to hunt down the new professor for the second years and ask him for any tips or tricks he had that would or could help me. I’m happy to say that instead of a few words, I got a crash course in optimization, pointed towards several videos and online documents, and a nifty little cheat sheet that I’ve been reading and re-reading all week. For the blueprints, I’ve been going through every line and chain of nodes and removing redundancies as well as just plain replacing certain chains of nodes with single nodes that pretty much had the same functionality, for example, instead of having a foreach loop that compared indexes of entire lists before picking out the index I wanted, I just used a “Get at index” node (and felt silly for not doing so earlier).
            Once all the cleanup was completed (Thursday evening), I began working on the combat UI for the player. Surprisingly, (and happily) I found myself ahead of schedule this week.
 
 
 
 
 
 
 
 
 
 
 
 
Week 4 (Feb 1 2019):
Fight!
            I started this week by finishing up the encounter system. Now, each section of the overworld contains a few possible encounters with each encounter randomly picking through this list. I set up a system for managing the player’s actions deck and formations as well as added visuals to the encounters. After that I dove straight into working on the combat system. First, I created a system to keep track of not only who’s turn it is but also what phase of the turn is currently being played out. Battles are split into 5 phases; beginning, Prebattle, Duel, Post battle, and Ending. With these defined, I created a blueprint for the action cards as well as added a physical model to the game so that the player can see their deck sitting on the field. As their field spawns in, one of these card models would spawn in for each card in the player’s action deck and stack onto each other.
Next, I created a movement system that allowed the player to move characters they own at the beginning of their “Beginning” phase or at the end of their turn if they choose. After that, more visuals were added to the combat screen as well as a new, “pre-combat” screen that show’s the player’s chances of landing and/or getting a critical hit of their “first hit” of any duel that they initiate. This screen flips sides and colours depending on there the Player’s unit is compared to the AI’s unit.
            Then I added a nice visual for the ending and starting of turns before finally, ending work for this week by creating the “draw a card” function for the player where the model for the next card slides off and de-spawns from the deck stack and a UI widget slides onto the combat screen’s “Hand”. As of this point, all of the Player’s combat options are working. Next week will have the AI’s options and the actual Fight mechanics be the focus of development. Once all that is complete, I’ll shift focus to artwork and making the materials more appealing to look at.