Candles: Sin AI (Part 2): NavMesh'n Around

Previously, I shared how Sin sensed the player. Now I want to cover how Sin gets around. It’s fairly straight forward: I use a NavMesh and NavMeshAgent – which is all built into Unity (so my work is done). What’s not so simple is behavior. To imply behavior, I need Sin to patrol, respond to sounds, chase the player, and investigate last known locations.

To simplify things, I’ve given Sin only one target–aptly named “Sin Target”.

Whenever I want Sin to go somewhere, I simply move his target to that location.

So–if the Sin can see the player, Sin Target’s position becomes equal to the player’s position. Now Sin appears to chase the player, when really, he’s just chasing the same target toward which he’s always moving.

But it’s also handy when dealing with Sin’s Patrols:

In every room there is an empty object named after the room it’s placed in. I’ve put these all in a list, kept on Sin. They’re separated by floor.

When Sin reaches a destination–the Sin Patrol script randomly chooses a new destination from the list. But, it is based on what floor the player is on. This keeps Sin relatively close.

I’ve considered creating routes for Sin–but we’ll see if it’s needed.

Bonus topic: Sin Opens Doors

There are lots of doors that the player can open and close. We can’t have Sin just passing through like a ghost, even though…he is…But then, why not just have him walk through walls?

Anyway, I created a simple script to allow Sin to open doors when he tries to pass through them.

One of the little details I didn’t think of at first, I have to tell the doors that Sin is nearby–otherwise the player can shut the door on Sin’s face. And then Sin would appear to walk through it. So the line “openThisDoor.sinHere = true;” helps with that.

Next–I’ll share Sin’s Brain.

Candles Update: Sin A.I. Part 1: Sin Sense

It's been 10 months since a Candles Update...but I have still been working. There's actually a fair amount to catch up on. Also, I've been doing updates on Tumblr.

(...not just because I work there...)

https://zachmakesgames.tumblr.com

So my plan for future posts is to be more focused and not just cramming every update into a single post.

The core gameplay of Candles is a ghost/demon/monster hunting the player. I did not seek or follow any stealth-gameplay guides created by others, but I peeked at a few to solve problems I faced. For the most part–I wanted to design the AI to meet my needs, and not fall in line with what someone else thought was necessary.

I cannot overstate how aggravating this process for Sin’s AI has been. I can say that it went through many iterations, weeks of stalling, and in the end–I learned many new things.

Step 1 (I decided) was giving Sin (my bad guy) senses. Enter my script “SinSense”.

This script is mostly made of booleans. It doesn’t do very much, but several scripts either make changes or track the changes to this script.

Outside of booleans, I only track whether the player is moving, if they’re sprinting, and are they close to Sin. Thus defining whether Sin can hear the player.

This script represents Sin’s FOV. I stole the FOV bit and added a ray cast. Basically it detects whether the player should be within a cone of view from Sin. If the player is within said cone, then it fires a ray cast to see if Sin can actually see the player. It then makes changes to the SinSense bools accordingly.

SinHearPlayer is a script that does a little more than SinSense. If the player is heard (while not having been heard recently) it attracts Sin’s attention: that is, it stops Sin from moving. Other scripts actually rotate Sin toward the sound.

That covers the “Sensing” part of Sin. Still missing, taste, smell, and and touch, I guess. But Sin’s not really a dinosaur, so I’m not sure those others are as important.

New Project: Candles

I'm starting a new project.

...three months ago...

I had been working on BrainMart for several months. Developing the features of that project has taught me a hundred new things about Unity, and I'm really excited about the doors that knowledge opens. But for now, I must say goodbye to BrainMart.

I cared a lot about the project. I think it was an interesting idea that represented a big part of my life in retail. But it didn't have much, if any, narrative potential. And while I like interesting ideas, making story interactive is my goal--and that's not possible when there's no story.

Enter: CANDLES (working title)

A game with story (and candles).

Candles, A short history:

Candles was conceived around the same time as BrainMart. And so, shared some basic design philosophy. I wanted to create a horror game based around a simple, original mechanic. The player would explore a haunted house (very original) while being hunted by a demon/ghost/killer (astoundingly original).

BUT, it's supposed to be about the candles. The player can find and carry candles. They can obviously be used as a light source, but their true power is impeding the hunter-demon's path. By throwing a lit candle on the ground, the player creates an obstacle of light the hunter-demon cannot pass. And while that helps create a safe space, the candles would eventually burn out--making resource management an aspect of the game as well.

I was quite set on the design and mechanics, I just needed a story. And while I came up with a narrative to slap on top of the project, I found it bland and unsurprising. I wanted the story to be weird, and perplexing. And running circles in my head wasn't getting me to where I wanted to go.

Help was needed.

That's when I invited an old friend, Kirk Gunton, to join me on the project. He's a filmmaker that works primarily in North Carolina. We graduated from the film program at WCU together. We shared screenwriting, and other classes. And I was the Assistant Director on his Capstone Project, Red Springs.

Needless to say, we have a history of collaboration, and I think it allowed us to "hit the ground running." Within our first few conversations, I became exponentially more excited about the project and its potential. So much so, I decided to put BrainMart to rest and start prototyping Candles.

Prototype Development:

1. FPS Controls:

I copied over my controls from the project FPS (my shooter-shopping game). Unity has a first-person controller, fully decked out--but I liked the simplicity of the hand-typed script, as I feel it lets me add in features only when I need them.

Speaking of--I added a run toggle. By pressing shift, the player changes their speed. I plan to create a limit--so the player may only spring for short distances before needing to "catch their breath."

2. Level Design:

I created a testing layout. It's a two-story house with heavy influence from Victorian houses. Mostly because they have a great aesthetic and are very "twisty-turny" inside, allowing for a maze layout and lots of nooks and crannies.

Most rooms and areas have more than one entrance/exit, which should allow the player a route of escape. And because I like to look at more than grey walls while I develop, I dropped in some basic textures to give a little life to the prototype environments.

3. Doors:

My first challenge. Creating an opening and closing door. I've always struggled with rotation in Unity, so was scared to attempt this. And while Animator is probably the "smart" way to handle this--I wanted to challenge myself and grow as a scripter by doing it all in C#. To my surprise, I had quick success.

I used a coroutine to open and close the door--but I also wanted to interrupt the action. That took a little more work, and I was finally able to get everything working. I'm planning to revisit the script, allowing the door to "pause" if it touches the player.

4. Ray Cast and Dots:

I used a ray cast to determine the player was near an object and looking at it. I think it stretches a meter and a half. Immediately, I found it very difficult to know whether I was in-range and on target. So I created a simple UI script that shows a white dot, and when the player is in range of an object, the dot grows in size. Subtle and helpful.

5. Pick Ups:

Now that my ray cast was functioning, time to pick things up. Originally, I had planned on making a 6-slot candle inventory. While in the process of figuring out how to get an object to child itself to the player and also go to a predetermined "hold" position that made the object visible on screen--I felt it might be interesting to limit the player to any two objects. One in the left hand and one in the right.

This may completely change the path of development, but I like the simplicity of the inventory system. You don't have to open a window or worry about onscreen UI, just--you have what's in your hands. I used Q to control the left hand and E to control the right. Not only do you pick up objects with these keys, but you drop them with these keys also. Simple.

 

6. Shrines and Keys:

Back when the project was very simple, the idea was that you would look for "keys": objects of great importance, like an old picture or family heirloom; and have to take them to their corresponding "Shrines"--like a fireplace mantel or dresser. This may change--but I've created some basic shrines and keys none the less. They're functional--as much as they can be without having specific identity and purpose.

To be continued...

My next step is to create the monster/ghost/hunter. Creating a NavMesh agent that tracks the player is nothing. But I want to create stealth mechanics and hunter AI. I really have no idea what I'm doing, so it's going to be fun to put all this together. Once that's in, I feel we'll have a game and can start exploring story implementation!