[My Dev Journals main page]

Page 1 2 3 4 5 6 7 8 9

 

April 30, 2016

Adding Some Obstacles To Accomplishing The Primary Goal

The Repair Parts have been added. Such a simple thing really. The player needs to explore and find the repair materials. Would be quite boring if that is all there is to it. Although entire games have been built around such a simple goal. They rely on puzzles to create an obstacle.

My next goal for this project is to add some obstacles. Obviously, the enemies will be the major part of that.

Currently, the Wimpies don’t actually do anything besides get in the player’s way and distract them temporarily from focusing on the goal of finding and collecting the repair materials.

That’s actually not a bad thing. A distraction can be a good obstacle. How effective it is will vary from person to person. Some would get caught up in chasing the Wimpies around and others would keep a laser focus on finding the parts and for the most part ignore the Wimpies once they realized they pose no direct threat to them.

I think the Wimpy can have a greater impact. I also like non-player characters to have some purpose. Some activities, goals and so forth of their own.

In this case… I wonder how much it would add to the experience if the Wimpies love collecting things. Perhaps they also find the repair parts, collect them and carry them to a different spot and drop them. In this way, the repair parts could literally be anywhere the Wimpies can go. The parts could be on the floor or they could be in motion being packed around by a Wimpy.

I think this is worth trying out. It would elevate the Wimpies from Distractions to Annoyances. And in a game like this that is a very good thing.

Time for a new task list:

  1. Add new Wimpy states for Gathering a Repair Material and Carrying a Repair Material to the enumeration
  2. Update the EnemyManager adding the GatheringRepairMaterial state handler
  3. Update the EnemyManager adding the CarryingRepairMaterial state handler
  4. Update the EnemyManager Wandering state to handle the Wimpy finding a Repair Part and changing state to Gathering
  5. Create a link in some fashion between the collectibles and the Enemies so they can carry the Repair Parts
  6. May need to create a new CollectibleState BeingCarried or something along those lines

That’s basically all that is needed to implement this new behavior for the Wimpies.

When I next return to work on this I will get started on the above.

 

May 1, 2016

Well… I started dabbling on this a bit today looking at existing code and thinking of how I want to tie in the new behavior. Won’t really get to any of it seriously though. On the bright side I finished a good chunk of the lawn mowing. And I have the pizza & wings on the way. Some folks coming over shortly to watch the WWE Payback PPV.

I did complete the first task on my list. A tiny wee bit of progress. 🙂

Tomorrow is another day and I will focus on making these Wimpies annoying.

 

Note: Starting now… I am changing to a Weekly Dev Log.

There are two big reasons for this.

First, I doubt anyone really cares to see page after page of micro updates from my individual work sessions.
Second, it would save me a lot of time to make weekly updates here instead of doing screenshots and videos nearly every time I am working.

With weekly updates, I’ll have a chance to make more progress which should make it more interesting for folks checking out my logs. And I will be able to consolidate all of the screenshots and such and just show “what I have right now”.

For this project a week is a short period of time. It’s not like this is one my “do it as fast as I possibly can” projects. I have done those many times such as my Halloween and Christmas games last year where for 2 weeks and 5 weeks I knocked out as much as I could as fast as I could. This project is just a slow & steady (relaxed) pace.

From this point forward, I’ll be posting updates each weekend. Most likely on Saturday night.


 

May 07, 2016

Made some good progress this week. I’m satisfied with the behavior of the Wimpies now.

First, I implemented the update for the Wimpies to gather the Repair Items when they spot them. They carry them around for a bit then drop them. In this way, it makes the Repair Items moving targets and you never really know where they might end up.

Also, I wanted to build onto the Wimpies spotting the player and running away while warning the other wimpies in the immediate area. So I made another update when the player shoots a Wimpy. The other Wimpies in the area scatter.

It’s just simple stuff really but is the kind of thing I have always found annoying in games. Give the enemies a bit more AI and have them interact with the player a bit more. It makes the game experience a little more interesting

This is what I have now:

Just a little update here on how the new architecture and programming approach is working out. It’s actually been a huge benefit. For the first time since I started working with Unity I am able to focus on bringing a game to life instead of figuring out how to get around some limitation or other issue in the “normal” Unity development approach.

So… what’s next for this project?

Great question. Hmm… let me think.

Well, I do think it is time for the player to encounter some danger.

So, I am thinking it’s time to add some combat. I think I will work on the Sentries engaging the player in combat.

Here’s the new task list:

  1. Add support for the Sentries to move from wandering mode to engaging the player in battle
  2. I think for these I will go with the Forward Trudge which means they will simply move forward a bit, stop, fire, move forward a bit, stop fire
  3. Of course, they will likely have some kind of secondary behavior they rely on from time to time
  4. And possible a reactive behavior such as reacting to receiving damage or reacting to their health dropping below a certain level

That’s pretty much it. Should be pretty straightforward and fun to bring these to life.

 

May 17th — Just A Quick Update Here

No… I’m not dead and I haven’t canceled this project. lol

I made a tiny bit of progress preparing to start on that list above when I knew it was time for a break from this project. I had been feeling the need to switch my focus to something else for a while and it was time to do so.

For whatever reason I find that I am much more productive if I have multiple projects going on at one time. Not like a dozen or even a half-dozen but 2 to 3 different projects. Also, I like having a project or two that is a small (even tiny) scope. This FPS is small scope compared to AAA for sure. And even compared to many Indie FPS games. But for me as a single dev who doesn’t want projects to drag on for many months or years it is a pretty big scope. My new side project is a much smaller scope probably about 1/5 to 1/4 of the scope of this one.

I’ve always enjoyed shmups so it is not surprising that is where I turned my attention. Just a simple little 2D shmup game with a unique twist or two. Yeah although it is a 2D game I decided to do it in Unity and use this new development approach I am using for my 3D FPS game. This is definitely the way I should have approached my Unity Dev long ago. Just makes everything so much simpler.

I’ll probably continue on this shmup the rest of this week and then next Sunday return to work on the FPS game.

Hmm… maybe I should make a progress log for the shmup. Might be interesting to someone. I might just do that.

 

May 28, 2016

Added Doors

So this past week I returned to this project and did a bit of work. I thought about getting the Sentries combat in and didn’t have much motivation to do that. So I thought about what else I could work on. And I figured hey why not add some functioning doors.

Sounded like a good idea. So I knocked out a very simple 3D model for the door (mainly just so I could give it two colors). Then I updated my enums code file to have DoorState and DoorType enumerations, created the DoorObject container class and the DoorManager class. In the scene editor I then added two doors. Updated the WorldQueryManager to build a list of the doors and updated the WorldScanningManager to detect doors.

I have support in for both unlocked doors that only require pressing the action key to open and locked doors that require a key.

Very simple stuff and didn’t take much time at all. Other than the time thinking about everything. When it comes to building a virtual world in a game even simple things like doors need a bit of thought. For example, I’ve seen many people make door systems where you can simply open the door and walk through the open doorway.

Consider the case like these doors where the doors open, remain open for a small amount of time and then automatically close. Straightforward and no difference other than managing the delay and auto-closing, right? Wrong. Whenever other objects (such as players and enemies) are involved you need to account for these things in one way or the other.

What happens if the player opens the door, walks forward just enough to stand in the open doorway and then pauses there?

In this case, when the door is open and about to switch to closing it first does a check to see if the player or an enemy is standing in the doorway. If so, the door remains in open state and does not transition to closing. Again, sure it is simple stuff but it is this kind of thing that makes even simplistic behaviors require a bit more thought and work than one may at first expect.

I know I am not making a lot of progress here lately but that is to be expected. Normally from spring through fall I just don’t do a lot of work on game projects.

I tend to get burnt-out working on the same game for an extended period of time and that happens very often this time of year. So I need to continually change it up and do things that will let me see some progress and be done with it.

Still a bit of progress is much better than no progress. I’m not sure if I will spend the next week working on this project or my shmup. I’ll probably stick with this one. Hmm… ya know… I might just start bouncing back and forth between the two projects from day to day. That might be the best way for me to do things.

As long as I am making progress I am happy. It is a slow journey this game development.

 

Page 1 2 3 4 5 6 7 8 9