3D Platformer GameDev Series – Weekly Blog #19: Halfway Point

Hello everyone! Unfortunately, for this week, I was not able to make any progress in the 3D Platformer Course, and thus, have nothing to share today on it. 😦 However, rest assured – after recently passing the halfway point in the course, I should and will continue to aim to complete it by the end of the year.

So instead, for today’s blog, I thought I’d share with some of you my thoughts on… Virtual Reality (VR). Yes, kind of random, but still quite relevant to my blog and I’ll further explain later. You see, I’ve been skeptical about VR technology for some time, albeit quite intrigued about it in recent years.

In the past few weeks, my curiosity eventually led me to purchase and pick up a VR headset today, the Oculus Quest. I must say, the technology is indeed rather revolutionary with its capabilities and it is by no means considered “new” technology anymore; there is now a fair amount of VR content out there for the consumer who is able to afford it.

Growing up, I’ve always to some extent felt immersed in any and whatever game I was playing (the SNES is still my favourite console to this day, but I digress…). After all, gameplay was and is still what matters the most to me. Still, with modern games of today, I cannot help but notice more and more the unimaginably realistic (3D) graphics and physics. In turn, these are factors that also begin to matter more and more to me naturally – and I can especially understand and appreciate this from the perspective of VR gaming now.

I guess what I am trying to get to is, as VR technology continues to advance, could it one day overtake what may then be considered as “traditional” (for lack of a better word) console and handheld devices to become the “new norm” for video games? As a game designer/developer with any insight to the future, this is perhaps something worth pondering over…..

3D Platformer GameDev Series – Weekly Blog #18: Adding Enemies (Part 2)

Hello everyone. So, WordPress has released an update recently and it’s absolutely driving me nuts. Basically, I’m forced to use their “block” editor now without the means to revert to the “classic” editor. And to put it bluntly, the block editor absolutely sucks – I can’t do certain things as easily as I used to and have given up trying after spending far too much time in it. Anyway, I will continue to stick with WordPress for now (at least until I’m finished the 3D Platformer course), but there’s a good chance I might look to a different way of sharing my work down the road… Vlogging perhaps? πŸ™‚Β 

Alright, so continuing where I left off last week, I will update the skeleton enemy AI today by adding additional AI states for it. No doubt, today’s post will be a little heavier on the coding side. Of course, if the coding is too much to digest, feel free to just skip to the end to see the result in the game.

Last week, in the “EnemyController” script for the enemy skeleton, the enumerated (enum) type variable was introduced (which we named “currentState”). This was used to store multiple values or states for the enemy AI. For example, the “isPatrolling” and “isIdle” states were set up such that, in their respective states, the skeleton would either be moving along a fixed path or be stopped at a patrol point along that path. Today, two additional states will be added: “isChasing” (to allow the skeleton to chase after the player when the player is close to the enemy) and “isAttacking” (to allow the skeleton to attack the enemy as long as the player is within attacking range):

And to see the skeleton’s AI behaviour in the game now, let’s take a look when the game is run:

Alright, that’s it for today’s blog – a short one, I know (to be honest, the WordPress update kind of killed my enthusiasm). Next week, I will finish updating the skeleton’s AI since, at the moment, it does not return to its chasing or patrolling states when in the attacking state. I will also make the skeleton’s attack do damage and allow the player to hurt and kill it as well. Stay tuned!

– TaklonΒ 

 

3D Platformer GameDev Series – Weekly Blog #17: Adding Enemies (Part 1)

Good evening, everyone! After taking a break last week, I’m back this week to continue blogging my progress in the 3D Platformer course. Admittedly, I haven’t made much further progress as work has been (again or as usual now?) quite hectic. Nevertheless, today, I will be showing how to add an enemy skeleton to the game and setting up animation and basic AI movement for it.

Once an enemy skeleton model is added to the mock level/scene, the “NavMesh Building Components” for Unity are downloaded and imported into the Unity project (note that these components are separate files that are not built into Unity but are downloaded on github and imported into Unity):

SettingUpEnemyAI

Essentially, the NavMesh components allow us to easily implement AI behaviours for an enemy object. Before working on the enemy object, however, the ground is first selected and a NavMesh is generated or baked (the light-blue shaded area represents the NavMesh or area that is “walkable”):

NavMeshBake

Next, a NavMeshAgent component is added to the skeleton object, which allows it navigate the game scene/environment using the NavMesh that was generated. The NavMeshAgent also grants a whole suite of parameters to control everything from movement or steering (i.e.- speed, acceleration, etc..) to obstacle avoidance and path finding. For now, the default parameters for the NavMeshAgent will suffice. And with that, four patrol points for the skeleton are added to the scene (which serve as destination points for the skeleton to walk to one-by-one):

SettingUpPatrolPoints (game scene)

In order to setup the enemy movement (as we did with creating a “PlayerController” script for the player character at the start of this blog series), an “EnemyController” script is created for the skeleton:

EnemyControllerScript (patrolpoints)

In the script above, the patrolPoints array is of a type “Transform” which stores the position of each element in the array, or in this case, the positions/coordinates for each of the four patrol points added to the scene. Thus, the script above produces the following result when the game is run:

EnemyPatrolPoints

Now, with the enemy animations, these are set up a bit differently than the player animations. The enemy animation will be largely “state-based” to allow for implementation of state-based AI through scripting. In other words, the coding in the script will be able to dictate what state the enemy is in: attack, idle, or running:

EnemyAnimator(state based AI)

As you can see above for the enemy controller animator, the idle and running states are set up the same way as the player controller animator; that is, exit time is enabled and fixed duration is disabled. However, for the attack transition (from any state to attack) and attack to idle transition, exit time is disabled here while a fixed duration is assigned. This is because the attack state will eventually be dictated by the script (which I will learn and cover in the next blog). Hence, the ‘Attack’ parameter added is of a type ‘Trigger‘ instead (opposed to the float and bool parameters which were utilized before).

After setting up the skeleton animator, the enemy controller script is updated:

EnemyController script (AI states)_1
EnemyController script (AI states)_2

Essentially, what is happening in the script above is that the enemy skeleton is constantly switching back and forth between its ‘isIdle’ and ‘isPatrolling’ AI states. In the ‘isIdle’ state, the ‘Idle’ state is active (and the idle animation is played). In the ‘isPatrolling’ state, the ‘Running’ state is active (and the running animation is played):

SkeletonAnimationPatrolPoints

Alrighty, it’s getting super late now and I’m glad I was able to get this blog posted in time! Next week, I will set up the skeleton’s attack animation and improve its AI – for example, chasing and attacking the player when the player is nearby. Thanks for reading and stay tuned for the next blog post!

– Taklon