Glori Dev Blog Entry 4, A New year of Blogs

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.