At a Glance

I accomplished numerous quests last week. I learned to iterate the hierarchy in code. I tried, failed, and learned lots about 9 slices. I stopped Unity from nag…, uh, warning me about CS0649. I started a side quest to complete 100 days of code.

On the technical side I made ten commits to my local git branch, QuestArea. I realized I overcomplicated my design. I created a class WorkingQuest to wire up the selected quest to the display area. I created DisplayQuest class that takes a Quest and displays all the details. I created a prefab ProgressBar and learned how to read the hierarchy without creating public or [SerializeField] private members. I created a ButtonProgressBar which will help with an autobuy feature in the future.

Accomplished Quests

Over the past week I got almost ten hours devoted to my game dev quest, and I felt good about it. This week I might not get as much because this Friday I celebrate 28 fantabulous years with my wife. Woot! However, before then I fully intend to work on finishing the main Quest area, which is the core mechanic.

Reading the Hierarchy

When I don’t know a framework, in this case Unity, I tend to write a few lines of code and then test it to make sure I understand how it works. I used this extensively the past week as I didn’t have a good idea on how to iterate over the hierarchy so I could update multiple text boxes on twelve prefabs. In the screenshot below, you can see the twelve encounters and the associated prefabs in the hierarchy.

I needed a way to update the quest title, and the twelve copies of encounter name, completed amount, cost price, income, and action text. I knew I could create a script that referenced all those items, but that’s sixty items, that seems crazy. After some research I found I code tag those items and then do some LINQ to get them in a list. Bam I had all the updatable text items for all twelve encounters saved to a separate Dictionary<string, List<TextMeshProUGUI>> object.

_encTextList.Add (item.name, item.GetComponentsInChildren<TextMeshProUGUI>(false).Where(x => x.tag == "UpdatableText").ToList<TextMeshProUGUI>());.

(WBD’s note: I need to find a new theme, I can’t use code blocks in this one as the ‘>’ get turned into ‘&gt’.)

9 Slice Trial and Error

I created a progress bar prefab this week and tried my first 9 slice. First off my wife had a great idea to create a copper pipe look for the border, we want a steampunk theme so great. The initial picture looked good enough to start. We ran into our first error when setting up the 9 slice. The image turned out fuzzy and not centered in the frame.

Ultimately, I moved the images around to hide the background and the fill colors and ended up with a decent progress bar. This works for the alpha stage.

Warning, Danger Will Robinson

By this time Unity nagged me with multiple CS0649 warnings “Field ‘field’ is never assigned to, and will always have its default value ‘value'”. So I learned something new I can use the default operator and C# will assign the default value to a variable, which is null for objects. [SerializeField] private Transform t = default; solved my warning issue.

Side Quest: 100 Days of Code

On August 23rd I started the 100 days of code challenge, and successfully posted to my forked repo on Friday and Saturday. In Motivation Is a Fickle Friend I mentioned I wanted to write code everyday and created a plan to do it, then a week went by and I didn’t do it. At the same time, my wife has completed nearly 30 days of her daily sketch journal which you can check out on her Instagram account, Comfort Creatives. I thought to myself I can code everyday and post it like she does, so a little research lead me to the 100 Days of Code challenge. I have completed day 4 (today) and will post it after I publish this blog.

Technical Specs

I learned more about using git, well as much as a solo developer can learn. I made ten commits to my local branch, QuestArea. I learned how to pretty up the log entries so I can easily post to my 100 days of code repo.

While I worked on wiring up the selecting and displaying of a quest I realized I overcomplicated my initial design. I used a familiar design from my business dev background and made a few non-MonoBehaviour derived classes that I didn’t need. However, now I have them and it would take more time than I want to spend to refactor them out – Technical Debt 1, WeirdBeardDev 0. Well at least I will know better for the future and it stopped me from “staring at the blank page” and get started coding.

I created a WorkingQuest class which derives from MonoBehaviour. I initially designed Quest as a non-MonoBehaviour class so it would not have the overhead, but I saw the problems this caused. Namely, I had to create a separate MonoBehaviour class to deal with quests and interact with the non-MonoBehaviour class. I created some technical debt for myself, assuming I continue developing the game past the first release.

I created a DisplayQuest class to handle all the display logic when the player selected a quest. Initially, I had this in the WorkingQuest class but decided it fit better in its own class. I learned tons of good stuff about reading down the hierarchy, in fact the Transform implements IEnumerable which means it works in a foreach loop. However, Unity doesn’t expose any sort of AllChildren property so instead I had to write foreach (Transform child in transform)... to loop through it. Intuitive it isn’t, however, it does work.

I created the ProgressBar which I showed off earlier in the blog. What I didn’t mention earlier is tweaked the functionality of the ProgressBar with my own script. I based the ProgressBar prefab on the Slider built-in component, and added an image for the border and made it so I could update the fill color all from the root ProgressBar gameObject. Now I don’t have to navigate read down the hierarchy to change the fill color or the border sprite, instead the main ProgressBar prefab has exposed methods to do it.

The last prefab I created was the ButtonProgressBar. Eventually the player will unlock the autobuy feature for each encounter so I combined the button used to complete an encounter with a progress bar representing when an encounter will automatically complete. After everything I learned from the ProgressBar I quickly churned this out and even found some bugs in ProgressBar that I didn’t know I had.

Keep On Questing

Well, I have to admit writing this blog has taken much longer than I expected. I discovered a bug with my mouse where one of the buttons still executed the Back command even though I disabled it, so I lost about 30 minutes of work, and then I ran into minor technical glitches with WordPress and this theme. I got up to quit writing several times and came back every time. Learning game dev requires discipline.

My quest for the upcoming week is to finish the main Quest area. I want to have two test quests that I can select. Once selected I want to complete encounters on that quest and then switch to a different quest to complete different encounters there, and then back to the original quest. I want to validate that the quest runs correctly in the background and foreground.

Life’s an adventure – go questing!

Git Commit History

5514560 2019-08-24 Created ButtonProgressBar Prefab
d896bc5 2019-08-24 Fixed ProgressBar
50461b8 2019-08-23 Copied over ProgressBar code
bb8b674 2019-08-23 Started dev on progress bar
a355825 2019-08-23 Stopped Unity’s warning about unused private fields
b465b04 2019-08-22 Continued wiring up the DisplayQuest
d88e2eb 2019-08-22 Removed method incorrectly entered
1ad7772 2019-08-22 Worked on displaying active quests
103f2ae 2019-08-20 Continued wiring up the test quests
00cb0ec 2019-08-19 Wiring up working quests