Today I sat down with Dr.James and started to work on the Controller classes for Twilleir. These are integral as these will hold the data that needs to be available across all aspects of the game, these include; Player Information, Storeroom info, an array of Dungeon items, an array of monster attributes and an array of Helping Hand attributes.
To start, we wrote all of this information down on paper and Dr. James helped me to design the PlayerInfo.cs, this was really helpful as it got me thinking about the structure of the class and what variables would be necessary, without launching straight into the code. I then designed the Storeroom.cs without his guidance and after I was sure that it was correct I decided to get these two classes into Unity.
Some of the controller classes need more design work before I can actually plan and implement them. For example we need more information about the attributes we’re going to give the Helping Hand, what ingredients make each potion and what the attributes for each of the Dungeon Items are going to be.
But for today I should be able to crack through the Enemy behaviour, the Storeroom behaviour and the Player information, I’m quite looking forward to being the primary developer on this project as it’ll be the first time I’ve been given such a large task. I’m going to continue with James’ advice in mind; start and plan the classes on Paper, and draw up a diagram to show how each system interacts with each other.
I’m planning on creating overview videos much like Aaron did that explain my code rather than writing it all out. This saves a lot of time and allows me to make clearer explanations, however, until this is in place I’ll be commenting my code and explaining them underneath as per usual.
I started with the Storeroom. This will serve as our ‘Inventory’ and as such will share many of the same behaviours as a standard Inventory System. The code defines and initialises an empty ‘list’ that we will add to and remove from; this will serve as our inventory system. I have defined two constructor classes that can be called from other scripts (addItem() and removeItem()) that will handle the contents of the storeRoom. Finally the checkCapacity() function checks how many items are in the Inventory, if it is less than the capacity of the Inventory, items can be added. Once I’d finished this class, I moved onto the PlayerInfo.cs that James had helped me design.
So PlayerInfo.cs will hold the information about the Players current level, current XP, the XP required to advance to the nextLevel, and the Player’s attributes that increase their ability in the various systems in the game. This controller class isn’t finished yet as it will have to hold information about Perks and further information about attribute scaling, but for now, it has all the necessary information. The appXP() constructor class will be referenced in the minigame scripts to add EXP once the Player has completed the activity and received a score. The levelUpCheck() method does what it says on the box, it is called to check if the Player has accrued enough XP to increase in level. We’re going to populate the nextLevel array with a range of XP values that are required to level up, this will be a lot more efficient than running a function to calculate random values. It will also allow us to edit the values far more easily, this means that we will be able to fine tune the XP requirements so level progression is fair, not too quick nor too slow.
After I’d completed the two above controller classes I sat with James and we talked about which one I could tackle next. We decided on the generateDungeonMonster.cs as it was the only other class that won’t need some further design work to plan. This class will hold all the ‘blueprint’ information to procedurally generate our monsters for the Dungeoneering, this includes Health, Names and Battle attributes. The results of this can be seen below and I’m quite proud of being able to complete the task with minimal help from James, I’m really trying to write cleaner code and observe better coding practices as this will be invaluable behaviour in the future.
Since Dungeoneering has become a lot more streamlined, the development process is not going to be nearly as intensive. It will also be far quicker to play test as our testers won’t have to run around a dungeon, we can put them straight into encounters and see that the Proc.Gen is working effectively. After this discussion I sat down and started to code this monster generator script.
It wasn’t actually as difficult as I imagined. In the Start() method I initialise all of the information I’m going to need to provide to the Monsters. I follow this up by populating the Scalar List with the percentages that will influence the Monsters Stats based on the Players level. I continue by adding the four types to an array so they can be randomly selected for each monster, this behaviour is handled by the randomiseType() method. I finish off by writing the constructor classes that will adjust the Monsters Health, Heal Power and Defense based on the Players level and the relevant scale.
In terms of scaling the monsters, we will need to play test this as we may find that players are too strong against monsters in the early game. In which case we will bump the scaling up at the start and begin to have it level out, and vice versa if the enemies are too difficult.
Tomorrow is our Research Trip to Lyndhurst, so I will follow that up with some photos. On Thursday we will be heading up to London to visit the Design Museum, we’re planning on finishing the day by visiting another location in London to collect some further research material so this will be documented as well!