Improving the enemy Path Finding rout

Note: Recently I have been quite bust with my application to my masters degree. The University has kept asking for my transcripts and they did not get them apparently. Their e-mail system may not allow attachments or something. However after a long process, they finally have them, also I have been offered a place on the course, however I have contacted the course leader because I need to defer my place until next year. Crafting the e-mail took a while and now I am awaiting a reply. This is why my works has been more varies than I wish for it to be and this blog is delayed.

Changes from last iteration:

Enemy patrol around each planet:

With this level I decided to have only four planets (that may change) and a re-fuelling ship in the middle. Around each planet is one enemy ship, following it's own set of nodes, I have implemented path finding code. Each enemy has path finding code attached to it and each planet has 6 nodes around it like a ring. This means the enemy ship is traveling in rings around each planet. So when the enemy ship finished it's patrol and runs out of nodes in selected array, I have made it reset the array so it goes around again. However I tried to instantiate another enemy when the player destroys the old one. However, the bulletin array system will not allow me to add objects though code to the array, therefore only one ship goes around each planet. I also did this because I don't want to over complicate the game too quickly. Therefore if player's for more difficulty or more enemies, I will increase the number or their health values.

the image below shows the patrol path the enemy object takes. The circle is the planet, the six black dots are the array of nodes, and the red ship follows each node in order. When it completed the circuit, it resets, and starts following the start node again and the others back in order. The arrows show the direction the ship moves in and visits each node. By the way, the individual nodes do NOT move, but the enemy patrol ship (red drawing) does move.

In game spacial grid:

Another thing, players were unsure weather they could move in 2D or 3D. With this in mind I implemented a translucent grid at the bottom to give the player a better idea of where they were in the game world and how far they are away from other objects in the game.

Just to make things clear, the player can more in any direction they want, the movement is not grid based, it's purely so they player can roughly gauge how far they are away from each game object.

Replacing the bullet with the laser:

I decide to replace the bullet with the laser. This is because in most space games and sci-fi films, lasers are used and it fits the theme more. Another addition because I can activate and de-active the laser on comment I do not need to worry about destroying the laser if it misses the enemy. When I implemented the bullet, it seemed out of place but also if it missed the enemy, it would keep moving for ever and need to destroy itself. With this in mind there are few objects on screen, therefore fewer items for the player to keep track of.

Enemy interaction:

When testing the game myself I initially changed the code so the enemy is following the path nodes by default. The enemy has a large 'isTrigger' collider and when the player enters it's the enemy follows the player. This is to improve the threat and obstacle of the game. When I originally implemented the enemy AI (or technically VI) I tried doing this through ray casting. This worked and it was fine, but I discovered when the enemy is near the player, it eventually starts pushing the player backwards.

I thought this may frustrate the player because then they can only shoot the enemy and this could force the player into the sight of another enemy. With this in mind I modified the script, so when the ship is very close to the player, it stops moving towards them, when when it's out of the range, it starts moving again.

When I implemented this, the ray casting did not fully work. When the enemy was close to the player it kept moving. I worked out I had programmed the ray cast in correctly. However because I had already spent a low of time on this method using different variations of ray casting I decided to try a different approach.

Collider Method:

I created two isTrigger" colliders, and when the player enters the outer collider, the enemy ship follows the player and moves towards them. When the player moved into the inner collider, the ship stops moving. When the player exits the inner collider though, the ship starts moving towards the player again. I thought from a design point of view, this would help give the player some slight breathing space and the enemy will not keep pushing the player backwards.

Whilst testing player's like this feature since it adds enough of a threat to be entertaining but also enough breathing space to shoot the ships.

Player controls:

Since I changed the player controls a few months ago from WASD (keyboard) to mouse clicks and movement, this has improve many players experience with the game. I have had to tweak the parameters of the controls, but it non the less works more smoothly with the game. A number of players wanted this feature and I wish I had included it sooner. It just makes the controls much easier to work with and the ship easier to control. Also if wanted to port this to the Android App store (a few months after handing in the dissertation), the SDK (soft-ware development kit) would automatically convert the commands in the scripts to phone and tablet controls (like taps and swipes), so there's plenty of scope.

Another, thing is it makes it easier for the player, and if I progressed the economy, by added a shop, where the player could purchase upgrades, I could just use mouse click for everything. With one control system, it would make the player's experience a lot nicer and smoother in general.

Player Reactions:

Player test one:

• After many play tests I discovered a number of things wrong with my level. One player did not like the control scheme for the mouse (they wanted the scroll wheel as the moving button, and the left click for firing).
• The second but that was noticed was how the player could easily click out side of the screen and wonder why the game was not responding. I.e. the player would click out side of the screen accidentally making the game loose focus. Then the player would wonder why it wasn't responding. I need to fix this so, I need to tell the player to click on the ship at the begging of each level. This is annoying because the player will not know why the game is not responding other wise.
• The sounds were horrible (apart from the ship thruster sounds) and they did not stop when the player had completed the action it was associated with. I thought I had fixed this bug, but I am glad this hole was pointed out.
• On the good side, the player liked the patrolling AI around each planet but they thought they needed a little more refinement though.
• Another point, the laser needs reprogramming, it works more like a bullet than laser. When the player clicks down, the damage is only caused on the TriggerEnter, rather than trigger stay, so the damage is implemented only once.
• Enemy death explosion takes too long.

Player test two:

• The audio was buggy, when an action is occurring the audio for it plays, but when the action for mining planets and the fuelling is finished the audio does not stop. Also it's not fast enough and the audio file sounds horrible.
• The laser does not work like a laser (like the comment above). The laser goes though objects. It should stop when it hits an object.
• The explosion lasts for too long, it should only last for a few seconds.
• Inconsistency between levels. The player is a lot bigger in the actual game level and faster compared to the tutorial level.

Next iteration:

• In the next version of the game I will fix the laser fire system, so when the payer is holding down the fire button, the damage will happen on "OnTriggerStay".

• I would also like to implement the art for the enemy ships, so the player has something more interesting to look at in the game world and help immerse the player into the game. Because if the player just sees a grey box, the will not look threatening unlike a large pointy, intimidating ship coming towards the player.

• One of the next things I would like to do it increate the size of each planet, because many players have asked why the planets are the same size as the ship. With this in mind I would also like to re-design the level itself but it's pointless considering I should readjust the size of the planets first.