Weekly Devlog #3b - Week 10


Josh's Scripting updates

The previous week (9) was a fairly quiet week due to work in other units, but I managed to fix a couple of the previous bugs and add to the test the scene with some moving objects, a navmesh, and a script to spawn enemies. In week 10 though I had a lot of time to make significant progress in multiple areas:

Player Movement

Firstly, I spent time fixing the remaining bugs in player movement such as loss of momentum in the air and getting stuck on ramps, steep stairs and on high speed collisions with walls. The result was player movement that I was finally satisfied with, with good controllability with both keyboard/mouse and/or gamepad, and a good sense of momentum. An added bonus being that due to the way the logic mimicked quake 2, several movement “tricks” from quake 2 are also now present in our game, such as chained strafe jumps for extra momentum, double jumps for extra height, and circle jumps for extra distance.

Double-jumps allow the player to jump to higher platforms

Chaining strafe-jumps allows the player to reach high speeds.

We’ll have to consider whether these techniques are appropriate to use as part of the basic level design, as they may be a bit difficult for some player and would require some explanation. They may be more appropriate for some secrets/bonuses.

Here we see the player strafe jumping up a ramp and building momentum

The box double-jump gives the player a decent height boost

Also, as discussed with the team previously, we’ve decided to use energy instead of health for the robot, as it makes more sense in the context, and we will trial making the player/robot move progressively slower as he takes damage and loses energy.

Melee Enemy – The Scrapper

Next I worked on enemy behaviour, starting with our first level melee enemy, the Scrapper. For navigation I used unity’s built in navigation module, assigning a navmesh agent component to the enemy as in our tutorials, and then planned out how to handle detecting and attacking the player.

The method I decided to use was to create an enemy script to find the player using a 3-step process, firstly the enemy monitors the distance to the player. If the player moves within a certain range (sight range variable) the 2nd check is initiated, checking the angle at which the player is in relation to the enemies forward direction. If the player is within a set number of degrees (sight cone variable) then the 3rd step is initiated, which is to cast a ray directly at the player to check that there are no objects obscuring the player from the enemies view. If all 3 steps are passed then the player will be “seen” and chased, for a certain period of time before the enemy must check again whether it can still see the player. Additionally, within a very close range (the "detect behind" variable), the enemy will detect the player even without it being inside the sight cone, similar to them hearing the player.

The enemy then chases the player with some prediction of future position, and within a defined range (attack range variable) the enemy will attempt a melee attack with a raycast. It is also possible for the player to avoid the attack striking if it can move past the enemy fast enough that the enemies turning speed isn't sufficient to keep the player in front of it (inside attack cone variable).

After attempting an attack the enemy will temporarily back up and be unable to attack again for a brief moment.

With some trial and error, tweaking things such as attack angles and turning speed I managed to get AI behavior that will effectively chase the player but also gives the player some chance of dodging attacks with maneuvering. Enemy speed is also a key factor in how challenging the scrapper will be to the player, and therefore i included a speed boost to enemies according to the difficulty level chosen.

The implementation of a sight cone allows stealth type gameplay elements to be introduced in the level design.

I then created an enemy health script to handle damage and tracking of health for enemies, and also added player health and damage to the existing player state and player update scripts.

 

Support Scripts

At this point it was necessary to think about how to handle the background elements of the game such as settings, difficulty levels, progress tracking, saving/loading etc. I added a Game Settings script to handle tracking of level progress and upgrades/batteries obtained at each difficulty level and store some important constants. And a Level State script which tracks progress and stats in the current level.

 

Robot Upgrades

The process of collecting and equipping upgrades was probably the most important gameplay element in our plan for the game, so next I worked on an upgrade selector script, which would allow the player to equip and toggle various upgrades.

As we wanted the use of upgrades - including swapping of components – to be a heavily used mechanism in the game, I decided that instant hot-swapping with buttons for each of 4 component slots would be the best way to start. Currently the available slots are left-hand, right-hand, body and legs, but these may be changed in future depending on which upgrades are finalized.

The only upgrades completed initially were the gun (right-arm), which allows the player to shoot, and the spring/hinge legs upgrade (currently lacks a model to swap) to allow the player to jump.

Instant hot-swapping of the right arm using the controller face button (right), allows shooting.

Shooting and Bullets

Shooting was next on the agenda, and was easier to implement in 3rd person than expected. Work began by creating a bullet model that represents a tube of energy (weapon is a blaster), adding a script to enable several functions:  - Orienting according to direction of movement;   - Detecting collisions and exploding/dealing damage;  - A bouncy physic material to allow it to ricochet once off a wall if it doesn’t hit an entity.  - A larger sphere trigger collider to alert enemies to the presence of the player if a shot is fired in their vicinity.  - A knockback effect, which helps the player avoid being overwhelmed by fast-charging melee enemies.

A small placeholder crosshair was then added in the center of the screen, and a shooting script was added to the player which simply does a raycast straight along the players line of sight through the crosshair to find the target point. A bullet prefab is then instantiated just beyond the tip of the players gun and accelerated towards the target.

 

With a bit of fine-tuning and bug-fixing the result seems predictable, consistent and satisfying.

Energy Orbs, Sounds and GUI

Finally, to round out a good week of progress I added some extras such as collectable energy orb drops from killed enemies, sounds and a very basic GUI to show player health and selected upgrades.

Dead enemies instantiate a prefab of a glowing energy orb, which is scripted to float through the air towards the player, but can be picked up accidentally by other enemies, and add to their health instead. Scrappers drop a green orb with 5 health, and stronger enemies will drop different colored orbs with more health. Finally, a free sound effects asset pack was and added and I chose sound effects for various actions such as shooting, bullet ricochet and explosions, player being hit, enemies being hit, enemies talking when attacking, player jumping etc. Here is some gameplay showing most of the features added at this point:

Scrapper sees player, and a missed shot startles 2 more scrappers in the background into attacking

Several new elements are in action here. A scrapper (placeholder model) sees the player and attacks. The player has the gun upgrade eqipped, but a missed shot startles 2 more scrappers in the shadows into attacking, one of which lands 2 hits on the player as he pauses and collects some energy orbs.

Get Junked

Leave a comment

Log in with itch.io to leave a comment.