[My Dev Journals main page]

Page 1 2 3 4 5 6 7 8 9

 

April 17, 2016

Truthfully, I actually created this page and started writing this log last night. But I was quite tired and when I realized I was typing a bit with my eyes closed I said “to heck with it”. So, tonight I am resuming this. Not sure how far I will get but we shall see.

Bringing The Enemies To Life

I really want to get the enemies engaging the player at this point.

It’s only fun to wander around and target them for just so long. Need to have the enemies “dancing” with the player.

By “dancing” I mean engaging (interacting with) the player in an interesting way. Posing a threat and yet not just obliterating the player instantly. And at the same time not being complete push-overs. And possibly making the player think “what the heck is it doing now?”

Achieving this can be a real challenge sometimes but it is a fun thing to work on. Or at least I think so.

So, now it is time to focus on some design again.

 

Enemy Behavior Design

So… I don’t know how most other people do this sort of thing these days. Mainly because there are a lot of different people doing things in many different ways.

Some folks just drop an enemy in with little thought and have it roaming back and forth or maybe rushing straight at the player and that is all there is to it. And this kind of thing can work.

At the other extreme some folks will spend their time reviewing the latest research papers trying to find a formal well-documented approach (perhaps based on academic research). There is certainly value in exploring such things if only for the entertainment purposes.

I’m somewhere in the middle between these two. I’ve read some stuff over the years and I have done many experiments on my own.

Basically, I see it like the best research is playing games and the best way to design the behavior is to simply do a little daydreaming. Like “wouldn’t it be cool if the enemy did so-and-so?” Basically going back to that whole playing the game in your mind thing.

 

A Starting Point For Enemy Behavior Design

Thinking about it a bit I have come up with a few different things that I should test for enemies that have engaged the player in combat:

  • The Sideway Shuffle  –  Enemies move quickly sideways, stopping periodically to shoot at the player.
  • The Forward Trudge  –  Enemies move forward in a sort of slow march, move… stop… move… stop… move… stop this simple behavior could work well for “tanks” trudging forward and occasionally shooting at the player
  • The Forward Backward Sideway Shuffle Combo  –  Enemies move forward then do a sideway shuffle, move backward and then repeat
  • Tied Down – Enemies that just stand around firing without moving
  • The Wimp – Very weak enemies that only seem threatening due to the number of them present. These things scatter fleeing from the player.

Those are off the top of my head for the base enemy engagement behavior.  Of course, the enemy behavior may be modified depending on current health and aggression rating.

 

You may remember that back in the initial conceptual game design phase I came up with four enemies and here I have identified 5 enemy behaviors.

There are a few ways to deal with this discrepancy:

  • Come up with a fifth enemy type
  • Apply two different base behaviors to a single enemy type
  • Remove one of the enemy behaviors

Always looking for the simplest way I will first review the behaviors above and see if one stands out as a good candidate for the axe.

The only one that jumps out at me as being a good candidate for the axe is the third The Forward Backward Sideway Shuffle Combo. The reason this looks like a good one for the axe is because it is the most complex enemy engagement base behavior of the five. And it’s still just a pattern. More important to me is to give the enemies enough AI to react to the player and interact with them. This can be done in the modification part of the enemy interaction.

 

Enemy Engagement Base Behaviors

So, my new list looks like this:

  • The Sideway Shuffle  –  Enemies move quickly sideways, stopping periodically to shoot at the player.
  • The Forward Trudge  –  Enemies move forward in a sort of slow march, move… stop… move… stop… move… stop this simple behavior could work well for “tanks” trudging forward and occasionally shooting at the player
  • Tied Down – Enemies that just stand around firing without moving
  • The Wimp – Very weak enemies that only seem threatening due to the number of them present. These things scatter fleeing from the player.

These should provide enough variety in the base behaviors to keep the game interesting.

If I try mapping these to the four enemy types defined earlier it might look like this:

  • Experiment #1 The Forward Trudge
  • Experiment #2 The Sideway Shuffle
  • Experiment #3 Tied Down
  • Experiment #4 The Wimp

Except, in this case I wanted Experiment #4 to be a sort of “brain” that calls on the other enemies for help and it doesn’t make sense for these to be in packs of many enemies. So… the story changes a bit… this was to be the master brain controlling the enemies but it ended up producing these tiny things that can only communicate with each other (as in with their own kind) and when they say “help!” the others get that message and take off trying to escape the danger asap. A quick and easy solution.

 

Finally, It Is Time To Bring One Enemy Type Alive

Having revised the enemy types and defined their engagement base behaviors the objectives are more concrete. Now, I can focus on bringing one of these enemies to life.

Which to tackle first?

I generally like to tackle the more complex pieces “up front” with the idea being I can later quickly knock out the simpler stuff.

With this in mind, Experiment #2 (Sideway Shuffle) and Experiment #4 (The Wimp) are the best candidates.

Because #4 has the added requirement of alerting each other I will start with that one.

 

The Wimp

I’ll begin by focusing on the movement aspect of the behavior and not worry about the communication aspect.

So basically how I see this working is when “spooked” these enemies will scatter. Meaning each of them will choose a direction away from the player to move in.

There are various methods you can use to plan things like this. Sometimes I just prototype it out in code. I do that often. However, I also like to plan things with mind maps, sketching out on paper, graph paper, making doodles and so forth. For this kind of thing, I find it easiest to work it out as an animation. This has the benefit of being a visual model of what I would like to implement.

So, I just created 10 quick images and turned them into an animated gif:

What you are seeing is 10 Wimps sort of grouped together. Then the player enters. Then the Wimps react. Although it may not be noticeable in the animation this is actually playing out a simple formula I came up with while moving the enemies. In this case the further they are horizontally from the player the more they move in a horizontal direction. The closer they are horizontally to the player the more they move in an vertical direction. When they reach a boundary, they change direction. Of course, this is a top down representation and obviously doesn’t represent movement in the X and Y planes but instead the X and Z planes. 😉

This is just one simple formula to do the scatter movement. Another would be to reverse it. The closer the enemies are to the player horizontally the more they move horizontally. The further away they are from the player horizontally the more they move vertically. This may be the better way.

I could test it easy enough by simply making another gif animation. Although, at this point it would be simpler to just code it up. The point of the exercise above with the animated gif is just to find a solid starting point. One method that will work even if it is not the best approach to produce the desired behavior. Then I can refine from that point.

Anyway, I haven’t seen anyone online discuss making things such as animated gifs to plan out algorithms. I am sure other people must do it at least from time to time. As you can see it is a really great way to get the kind of movement you want. Just play around with the movement and think of the algorithm that will give you that result. And remember keep it simple. This kind of stuff so many folks seem to come up with complex math to do the simplest of things. And it is just not necessary or at least I have never found it to be.

 

April 18, 2016

I almost took tonight off completely from doing anything on this project. Workday was super busy and I was sleepy. Makes for a very long day. But I decided to spend a little time just because even little bits of time add up. 🙂

The first thing I did was spend a bit of time cleaning the project and organizing the enemy related stuff. This is something I do periodically on a project. And it was time.

Then I play-tested the game a bit and adjusted the player’s movement speed and the bobbing motion. I think the player motion is where it should be now.

I then added a new enumeration for EnemyType and updated the EnemyObject to have an eType property. This is something I should have done in the beginning but since I only messed around with one enemy I never did. Now it is done.

Next, I modeled the Wimpy enemy. Sticking to my quick and easy approach this is another ultra low poly model using only face coloring.

Then I placed a group of 10 into the level just to see how they looked:

And there they are. Little robotic critters to scurry around. Actually the main purpose of these things is provide a large amount of cannon fodder for the player to blow up.

Now, I am at a good point to focus on programming tomorrow to start bringing these enemies to life.

 

April 22, 2016

As you probably noticed, I took the last three nights off from game dev. This workweek (day job) was… insane. That’s just how it goes when you’re doing this stuff part-time and it’s fine because I have no deadline for this project. I did dabble a bit here & there adding character controllers to the Wimpy enemy and playing around with the radius and height properties to be sure they represented the enemy as well as making it targetable by the player.

Also added a couple #regions to the EnemyManager to “wrap up” some of the code sections. And then reading a post on the Unity forums showing a pixelated 3D FX reminded me that originally that is how I wanted this game to look. So I bought Retro Pixel Pro from the Unity Asset store. Tested it out and I like it. So… yeah basically did very little but at the same time… something. I am ready to rock n’ roll again tonight. 🙂

Implementing “The Wimp” (Enemy)

My goal for this dev session is to implement the enemy detecting the player’s presence and react as designed earlier.

The first thing I decided to do was test out the Wimpies just to see how they’d interact with each other at this point. One of the challenges I have with working with Unity is not really knowing what to expect. Sometimes it does things for me without me having to tell it to and other times it does not. There seems to be no rhyme or reason to these choices although I am sure there must be… I just don’t know what it is.

And that is one of the reasons I test after adding some Unity specific thing such as a Character Controller to a GO.

I simply used the same Wander code I had written previously for the Sentry, tested and this is the result I got:

Excellent. The little critters are roaming around exploring their environment. When about to collide with one of the others they fly up in the air and over them.

Wait a second. I never added a flying behavior. Hmm….

So, here is a good example of what I was talking about just a bit ago. Adding a Character Controller resulted in flying behavior when there was none programmed. Of course, I am sure they are not actually flying. lol

What is more likely is there is some setting regarding them navigating over obstacles and terrain and I need to adjust those. So… let me take a look, change some things (if I find any) and test again.

Aha! Sure enough I found two parameters: Slope Limit and Step Offset. These sounded like what I needed. I rarely waste time checking out the docs for every little thing like this. Instead I take a look and if I find something that looks logical I give it a try. I set Slope Limit to 180 degrees (the max allowed) and Step Offset to 0. Tested again…

Hey look at that! Now those are the crawling critters I had in mind. One nice thing is the initial “flying” behavior actually looked pretty interesting to me. It’s what I have in mind for that flying Gunbot thingy I modeled. However, I want to be in control of it not just have them doing that completely unknown to me. That sounds like a recipe for disaster.

Alright! Now I have a solid starting point to begin work on their “spooked” behavior.

I’ll start on that tomorrow. 🙂

 

Page 1 2 3 4 5 6 7 8 9