Thursday, 4 May 2017

Outside the Box Project Beta Work - Future Development

With more time to develop, we would like to translate our game to the Mobile market (conceptualised in Figure 1.).
All of our games mechanics have been designed for a PC, however everything the player can do in the game is centralised in the mouse; you want to collect the coins? Then you swipe over them with the mouse, you want to buy a defence or upgrade it? Click on the defence and select what you'd like to do.

Mechanically our gameplay wouldn't change if these mouse operations were swapped for a finger -tapping to purchase a defence, or swiping a finger to collect the coins etc.

Figure 1.
With out first level we can move forward using our first level as a template for future iteration, with it we'd make a tutorial level. We would progress the limited narrative by adding more types of enemies from Chess' The Monsters' mythos such as The Sneak or The Spy, each with their own characteristics in-game.

We'd also like to implement a boss level, were the Player would face minion Monsters and The Monarch, their queen. Other game types we could include are things like the Outpost variation I made of our game after our first presentation milestone back in December, the one we based our current level on.

That could then evolve into other game types, on where the Player has to keep control of the board, enemies would be able to take over Defences and those overtaken defences would change in appearance and start to attack the Player.

We would also like to implement a damage system for the Player's Defences, so The Monsters can fight back against the Player's Defences for more interesting dynamics in gameplay and strategy.

There is potential here to grow into something wonderful as a small, charming mobile game.

Outside the Box Project Beta Work - Game Banner


I had planned to design a poster/banner that both appear in the Main Menu and could be used as a big advertisement banner if we were to present our game at conventions.

Sadly I ran out of time to complete such a banner, but I did begin production of it, and I liked where it was going, it's just a shame I couldn't see it through to completion for our hand-in deadline.


Outside the Box Project Beta Work - Volume Option Coding


I wasn't able to get this working for our final hand-in of this project. However the principle I tried to apply in code was to provide a float value to the AudioListener component, which would then be influenced by where the slider is on it's bar/value.



Then in Unity's Editor, I simply had to give the UI Slider a reference to the OnGui void in the SceneCameraManager and set the starting value of the Slider to it's highest of 1 (lowest being 0).



I added an additional button to the pause menu named "Options" and that would switch off all the buttons visible above and turn on the Slider and a Button that would return the Player to the previous Pause Menu screen.







Outside the Box Project Beta Work - Damaged Enemy Appearances In-Game

One major thing we want to add for definite given more time to work on this project are damaged versions of The Monsters that will appear contextual to the numerical value of their Health bars. For example at MaxHealth (3) The Hunter will look fine, then at 2 HP (Health Points) The Hunter shall appear dirty (as seen in Figure 0.5), and at 1 HP The Hunter will nearly be toppling over from exhaustion.

Figure 0.5
I modelled The first damaged Hunter and tried to implement him before hand-in, however it didn't quite work out in time.

Figure 1.
I had to create a new Prefab for this to work, like how the Tower, Cannon and Magic Defence appear when they are upgraded the same principle applied here. The visualisations of The Hunter would be contained within an Empty GameObject and their SetActive Boolean would be made true or false based on The Hunter's current Health value, like how the Defences are upgrade, and with each defence having their own scripts governing their behaviour, as soon as they're turned on in scene, they run as they should. The Hunter, meanwhile, simply needs to look more beaten up, so the visualisations don't have scripts governing behaviour as their behaviour doesn't change just because they got hit by a Defence. All of this can be seen in Figure 1.


Figure 2.
So in the if statement as seen in Figure 2. I just checked the value of currentEnemyHealth in the referenced Manager Script and turned off and on the appropriate referenced visualisations.

Because I created a Enemy Damage Manager Script, it saved me from having to separate the health values for The Grunt and The Hunter and I could just reference the Enemy Health Manager on the gameObject the Damage Manager was attached to, which was now the empty GameObject that contained The Hunter visualisations, as I had also moved all the scripts from the one Hunter model to this Hunter Container so that all changes would happen to all versions of The Hunter.

Such as when The Hunter's health reached 0 the container and all the visualisations would be destroyed, rather than the one version.

However the problems I faced were time related. By moving The Hunter models into a container I had to spend time to reposition the models so that they would appear correct when spawned and follow the waypoints correctly. I would have also needed to model the other damaged Hunter and the damaged versions of The Grunt, and texture them, then implement them in game, and I just didn't have the time to sort this out.

So, I know I can do it, I've shown that here, but I didn't have time to complete it and fully implement this, hence why the damaged appearances won't be seen in our hand-in game build.

Outside the Box Project Beta Work - Project Update, Milestone 03, Game Pitch Feedback

The feedback we received from our mock game pitch came across as optimistic, surprised and constructive. It felt as though our tutors and guest didn't expect the quality of the work we produced for this presentation and our game (despite complete self-doubt on our part) and were pleasantly surprised and pleased at what we had to show for our work.

In fact the only feedback we received to make improvements for Project Beta's hand-in (as of writing this) was this list:

- Scale the Environment to make it a little Bigger to increase enemy paths
- Scale the Defences to be Bigger 
- Reduce Size of some UI Elements 
- Make Player Health more Obvious 
- Reduce the Force of the Coin Eruption 

There wasn't criticism for design choices, gameplay, mechanics etc. just simple tweaks to our game to help improve Player experience, which we gladly took on board. 

Original Feedback Update Attempt 

I originally attempted to follow the advice of our tutor's and guest by increasing the scale of the environment to provide the player more space to breath and to make the game environment appear larger. However this caused scaling issues that, when rectified, simply made the game board look like it had done prior to any change. It also caused havoc with the count down timer and the range of the Defences. All of which was just a bit too much for me to handle fixing with only just over a week until hand-in

Milestone Pitch Version

Post Milestone Feedback Update (Path Increased and UI Shrunk)

Instead, I tried playing a trick with the scenery to make it appear as though the paths are bigger and the Player has more time to react at the start, however all I did was move the tree line back, moved the enemy spawn points back with the tree line and moved the Player Base back a little. This gave created a larger path without the struggle of all those game and balance fixes from y original attempt.

The only changes I need to make was to make sure the waypoints the enemies followed still reached the Player Base to harm the Player and that the timer was still in time with the game. To my surprise I actually had to reduce the time limit from 2 1/2 minutes to just 2 minutes to keep the game tense, but not impossible with the time limit.

I also repositioned the Build Spots so that they were more relevant to the path's the enemies would take to reach the Base. As the enemies follow the dirt path on the Ground's texture.

With this repositioning I've also given The Grunt's a couple more waypoints for them to follow to make their path more in line with the more straight dirt path on the Ground's texture. 

Milestone Pitch Version

Post Milestone Feedback Update (Defence Sizes)

If you visualise that the standard sizes of a 3D model are 1, 1, 1 on X, Y and Z then these are the changes I've made to the scaling of the Defences in-game post feedback


Increased size of Towers by 30% (1.3)
Increased size of Magic by 60% (1.6)
Increased size of BubbleWrap by 10% (1.1)
Increased size of Candle by 50% (1.5)
Increased size of Cannons by 30% (1.3)

Milestone Pitch Version

Post Milestone Feedback Update (Upgrade UI Size)

Milestone Pitch Version

Post Milestone Feedback Update (Lack of Money Feedback Shrunk)
Following those 3D model changes I then scaled some the UI on screen down a bit, as per feedback, this reduced the amount of the screen each UI piece covered during gameplay and the game was better for it, as Player's would get frustrated by the fact that UI was blocking their mouse from interacting with the Defences and coins that needed the Player's urgent attention to survive and play.


Outside the Box Project Beta Work - Enemy Wave Counter

As there was no Round or indication of the Waves of enemies spawning I decided to code a counter for how many enemies would be spawning and for a parallel number to be reduced as the enemies are killed to showcase the Player's progress. 

Figure 1.

Figure 2.
To do this I simply gained access to the list that informed the game of the number of enemies that would be spawning each wave (for example 5 Grunt's in wave 1 and 15 in wave 2). This list is within the Spawn Enemy script. Then I had to convert that numerical value from an int/float to a String (int's and float's being numbers and String's are words/letters).

Figure 3.

Figure 4.
The GruntChecker and the HunterChecker were scripts placed on the prefabs of The Grunt and Hunter respectively. All they had to manage was reference the numerical value in the EnemyCountScript that would be reduced when a contextual enemy was killed (as there is a counter for both The Grunt's in scene and The Hunter's in scene) and then using OnDestroy (when the gameObject this script is attached to is destroyed) reduced that value by 1, short hand is --

Figure 5.
Figure 5. is how the counter looks in scene.

Outside the Box Project Beta Work - Game Build Thumbnail

To make our game a little more professional, like with the opening team credits, I decided to create a thumbnail/game icon for our game that would appear on the dashboard to represent the Application/EXE. Figure 1. is that icon.
Figure 1.

I like the design, it's meant to be the one toy our child in-game owns that inspired the entire design and their imagination to create this little pocket world, draped over the side of the box it's contained in after a session of playing with the toy when the kid has put it away.

The icon itself is only 256x256 in pixels, this is because most icons are of this size, as my icon scales well with other game icons I have on my own dashboard. As well as the fact that Unity has set sizes it will accept when trying to implement a game icon in the Editor (as seen in Figure 3.)

Figure 2.

Figure 3.