Week 9 - Heads up!

I made a little progress this week. Still suffering from the setbacks of last week, I was at a bit of a loss as to what to do. I spoke to my lecturers and came to the conclusion that the best thing to do was to work on something small and unconnected to the parts of the blueprint that seemed to be causing the issue.

Working on these smaller components made me feel a little better. I have started backing up more often than I had before out of fear of losing any progress. Eventually, I started to feel like I was building some momentum again.

Created a very basic health system

• Regenerating mana

• Mana cost for spells

Started work on the heads up display.

• Health bar

• Mana bar

THE SOURCE OF ALL MY PAIN

Feeling more confident about my progress, I decided to have another look at the area that had been causing the issues last week. I knew I would have to come back to this area at some point as it was at the centre of my spell casting mechanisms.

after some tentative testing, I finally managed to divine the source of the problem. I had been trying to implement a system that would make it easier for me to edit the variables of each spell. This involved making a Data Structure when each variable was itself a Data Structure, the same data structure that I use for storing Spell data. I used a technique like this in my project last semester when spawning enemies.

The problem was occurring when I tried to get that data into the game.

When the player changes their current spell, The system checks an array of the Spell Data Structures, taking the appropriate data. I was trying to get the game to fill in this array using the data from my new mega data structure.

I was doing this on the Event Begin Play, and it seems to have been what was wrecking my game.

In hindsight, I am frustrated that all of this lost time and confusion was over a feature that was really only being implemented to save me some time as a developer. This time could have been spent implementing features that the player would actually get to enjoy.

If I had to put a positive spin on this, I'd say that this definitely sharpened my troubleshooting skills and really taught me the importance of regular backups.

Communication is Key

After getting to the root of the problem, I continued on with the little odd jobs that needed done, gaining more confidence. One of the systems that I implemented was the interaction system which will act as the basis for a wide range of different mechanics.

This system was required if I wanted the player to be able to interact with the world around them.

Hopefully it will be robust enough to handle it

Of all the areas where this advancement helps me the most is in the field of onboarding the player. Most of the tutorial segment of the game will be handled either through some sort of dialogue whether with an NPC or reading a journal.

Guidance From Above

During one of my practical sessions this week, I spoke with one of my lecturers. We talked about the onboarding process. I had thought of how to get information across through interactable items. I hadn't considered the flow of the prototype. how to introduce mechanics one by one and give the player a chance to test each ability out.

This rough draw out shows the gameplay narrative that I will be attempting to build.

1. Start in Fire World

2. Master basic Movement

3. Learn about Spells

4. See a reason to come back with more spells (Unreachable Treasure)

5. Tutorial Combat

This was the first Level that I would be building, The Isle of Fire. Next;

1. Arrive in HubWorld

2. Spellbook Tutorial

3. The portal to Isle Fire wont reopen, go to Isle of Air

4. Get new ability

5. Return to Hub World, Equip new Spell, and go to the Isle of Fire

This section contained the other two levels that I would need to make. I had only intended to build 2 levels. I will now make the Levels much smaller in scope than they had originally been.

I am very grateful for the assistance in formulating this structure for my prototype. Going forward, this is the goal.