[My Dev Journals main page]

Page 1 2 3 4 5 6 7 8 9

 

April 14, 2016

Development Officially Starts

Alright, I am back from taking a couple days break from this project. Remember when I said I only do this stuff in a very part-time manner? Yeah that is true. Generally, I spend anywhere from 45 to 90 minutes per evening when I am working on game dev. And sometimes, such as the last two nights, I just do nothing much at all. Maybe a little dabbling here and there trying out something (often a different project entirely) but its more common that I am just hanging out, playing games, watching a movie or whatever. I take a real relaxed approach to this stuff. 🙂

Just came in from mowing the lawn and thought I’d get an early start on the project. It’s actually only 5:19 PM as I write this. Had a great (although busy!) workday. Got outside and got some fresh air mowing a good chunk of the lawn. Now I have until my girlfriend shows up so we can get some dinner to focus on game dev.

 

It’s A Good Time To Be Shooting

I’m thinking tonight I will play around with the weapon systems.

Not sure exactly how I will do it yet. I think it will take an iteration or three because this game uses only the keyboard to control the character. That’s arrows or WASD for movement and turning. No mouse control. The older games didn’t use the mouse and I am thinking I can accomplish the same thing here despite not having the pinpoint turning accuracy afforded by actually using a mouse. 😉

First, I’ll need to update my Enums code file. Hmm… actually I don’t think I mentioned creating this file. I made this back when I first tested the enemies. It is just a single file that will have all of the various enumerations dumped into it for states, types and so forth.

So, I added the enums for the player projectiles

Of course, I’ll need a new container class for the projectiles:

Then I created the ProjectileManager that is responsible for Initializing and Updating all of the projectiles.

As you can see, I followed the same patterns I used when creating the player & enemy object containers. In truth it was just a copy, paste & edit job from the Enemy container. And the same pattern with the manager.

Patterns are a key to dev speed. Basically, once I figure out something that is working I use the existing code as a sort of template going forward. I follow the same pattern for each thing. In this case, every entity type will have a container object and a manager. This makes the program easier to follow and it increases dev speed because I can simply copy, paste & edit from existing code I have already written and tested.

And now to test this out with an electric projectile (which should be obvious because the cube is yellow! The cold projectile would be blue):

Ignore the dithered distortion, it is the result of compressing the gif (although I actually think the effect that resulted is pretty cool, gives it a grainy look which reminds me of retro games or at least the old grainy digitized video that used to appear in games):

Hey look, we have weapon firing complete with raycasting detecting hits on the walls and enemies. And it is now 6:07 PM. It actually takes much more time to take these screenshots and videos (and convert to gif movies) and upload to my website and then write this dev log. Especially when, like in this case (4 times!), I have to record multiple videos to get exactly what I want to show you. But hey I am happy. Progress has been made. 🙂

So at this point, of about 50 minutes, I will now take a little break and likely be back later. Thinking my gal will be along anytime now. Sure hope so because I am hungry!

 

Getting The Feel Right

So yeah it is later on now. Had a good meal. Hunger has left the building so figured I’d do a little more on this project.

One thing you may (or may not) have noticed in the animation above is the challenge in targeting an enemy.

So, it’s time for an interesting design decision.

Some difficulty in targeting an enemy is fine because as the player gets used to the controls they will be better able to work with them.

Another consideration is the pace of the action. For a slower more strategy-oriented experience some challenge in targeting enemies can be a very good thing. However, for a faster paced more action-oriented experience difficulty in targeting enemies would be downright frustrating.

The older games using keyboard controls got around this through a combination of two or more of the following:

  • They displayed a rather large hand (holding a weapon) and the barrel of the gun served as a crosshair
  • Instead of using visible projectiles they actually only registered hits on enemies and objects. The benefit of this approach is that instead of checking for collisions between a tiny bullet and a distant enemy they instead checked for collisions by basically shooting out a very wide beam (or a series of narrower beams) across the entire width of the hand/gun forward into the screen. So actually anything in front of the hand/gun was hit. Pretty clever, right?
  • If they did launch visible projectiles, the projectiles were quite large. Usually as wide as the enemies themselves.
  • The enemies generally advanced relatively slowly while moving left and right as they approached. Now this could make it harder to target however I believe in many cases they did this simply to make the action seem more lively while actually helping you to be able to target the enemies.
  • Of course, the closer the enemies are to the player the larger they appear on screen making them easier to target.
  • Often the enemies could be caught off guard, or they had a very short “stop” point before they engaged the player, or they stopped periodically while advancing. All of these provided opportunities for the player to target the enemies.

I can add a crosshair to aid in aiming.

I think the projectiles are already large enough. However, I can play around with that if necessary.

I can definitely focus on the enemy behavior to make them a little easier to target at times

Let’s see how much difference adding a simple Crosshair makes (grainy “movie”… compression… you know the drill):

This is definitely an improvement. You may not be able to tell based on the clip but it definitely “felt” better. An added benefit of using this approach is I could check for collisions with the entire crosshair area.


April 15, 2016

Improving Feedback By Adding A “Targeted” Indicator

You’ve probably figured out by now that interaction is very important to me. And a big part of interaction is good feedback.

I had a super busy workday so didn’t feel like doing any work on this project until just a little while ago. Have to get up early in the morning because I hired a local fella to replace the entire faucet and shower head set . This means no late night coding even though it is Friday. 🙁  However, my plan is while he is in there banging and clanging I will be out here in the living room getting some game dev done. 🙂

Anyway, tonight I wanted to do one more thing to make it easier for the player to target the enemies. One thing I thought that might be helpful is to make the crosshair glow to indicate an enemy has been targeted.

So, I updated my Configuration code file to allow setting up 5 colors for the cursor. The first color is the default gray color when no enemy is within the crosshair and the other four colors are increasing brightness on the red component while decreasing the brightness on the green and blue components.

My Configuration file now looks like this

Then I updated the PlayerManager to implement a simple sphere cast in front of the player and if an enemy is found the color glow effect is activated otherwise the crosshair is set to the default color.

A quick test of it in action:

This definitely helps a lot to solidify the connection between the player and the game. Strengthening the link between the keyboard controls and the feedback the game is providing. Also, as you probably already realized, if I decide to make it so the player does not shoot visible projectiles and instead any enemy that is even partly inside that crosshair will be hit when the player fires I basically have everything in place to implement that. 🙂

That’s it for tonight. Tomorrow I will definitely spend more time on game dev!


April 16, 2016

Improving Feedback By Adding A “Locked-On” Indicator

Back at it again. Before I start the next page of this log I wanted to do one more thing to improve the targeting of enemies.

I thought as a finishing touch I’d make the crosshair smaller while the glowing targeted indicator is active.

This was another very easy enhancement. I already had the “Targeted” indicator enhancement detecting when the crosshair was on an enemy and performing the color cycle if so otherwise setting color to gray. So the only thing I needed to do was change the scale of the Crosshair transform in the same sections of code.

Now let’s take a look at everything.

I started with this:

And now have this:

You’ll probably notice I also adjusted the size of the enemies somewhere during this process.

Anyway, I think this is fine. Sure it can be polished up later on maybe make the Crosshair resizing do a smooth zoom instead of instant. Actually, I am not even sure why I went ahead and did the glow effect already. I could have simply used 2 colors for now. Red for targeted. Gray for normal. Then done the glow in the polishing stage (that I haven’t made it to in a long long time). I guess it was just because it was so simple to implement. Still I will try to keep this in mind going forward. Just get the basics in now. Polish it up later.

Now I can get on to the next piece.

 

Page 1 2 3 4 5 6 7 8 9