Dev Log #5: Changing the Approach

It’s been a while since I last did a Dev Log for this game I’m building. And for good reason. Besides life in general, I got stuck in the development with the path I was taking with no real way to stay on track. As I want to be the game developer that makes real games that people play, it is time to change my approach. 

A Change in Approaching the Development

So, what does this change look like? My first step is to stop taking an exploratory approach to game development. The exploratory method of development may feel great for learning, and everyday feels like something is getting done. Yet it drove me into a rut, and I could not escape it. I did not feel like I was meeting my goals nor had any direction. 

My plan is to now take a weekly iterative approach instead. I start the week looking at my project plan and planning out the tasks that need to get done. All the tasks get laid out on a Gantt Chart. I work the plan as best as I can, and by the end of the week, review what I accomplished and plan for the next week, updating and revising the plan as required. 

I’m confident this plan will work as I have already tried it out on a project I recently completed. Recently I submitted a project to EPIC Games Spellar Performance Challenge. This challenge was about Video Effects and the Niagara System in Unreal Engine for creating Video Effects. You can check out my submission here on my blog and here on the Unreal Forums. This project took me three weeks to complete, and I was able to complete it ahead of the deadline. 

Current Work Done

Before I can even think about project plans and Gantt Charts, I need a solid base of requirements to build from, something I lacked before. The first step I took was to mind map everything I want to add to my game. 

Mind Map of the 3D Danmaku Game. Most of it is hidden right now to focus on the Gameplay features. Future Dev Logs will go into the more detailed areas.

From this mind map, I can identify the requirements for the game. These requirements can be broken down into two groups: Functional Requirements that represent the core features of the game and Nonfunctional Requirements that represent the nice-to-haves that flesh out the game. 

Functional Requirements

  1. Player can move around and shoot
  2. NPCs can move around and shoot
  3. Bullets move in 3d patterns
  4. Player can Start New Game, Load Game, and Save Game
  5. Player has 3 different attack patterns 

Nonfunctional Requirements 

  1. Bullets have different 3D spawning patterns
  2. Different color bullets have different effects
  3. All bullets have trails
  4. Each Player Character has a unique special attack
  5. Popcorn enemies with basic movement and attack patterns and decisions 
  6. Boss enemies with complex movement, attack patterns, and decisions. 
  7. Acts as a base to building a game
  8. Various Traps that the player can fall into

Side Note: Popcorn Enemies are enemies that will have a single Hit Point for their Health. They are meant to be easy to take out in a single shot.

Now I have a starting point to project plan. I’ll start by focusing on the Functional Requirements to build my game. I now create the following Gantt Chart. 

Here is the current Gantt Chart I’m working from. It only details the first bit of functional requirements I’m working on.

Now I have a starting point, to get the player moving. 

I make the following Class Diagram for a BaseCharacter Class. The BaseCharacter Class will act as the building blocks for the Player Character, Popcorn Enemies, and Bosses later on. 

Class Diagram for a BaseCharacter Class

With this Class Diagram, I now get to work on the implementation. I’m going to start by building the BaseCharacter Class using Unreal Engine Blueprints. I am doing this mainly because I can copy the 3rd Person Template from Unreal. The next problem is how do I want the Bullets to spawn. For this, I would like to use the Niagara System in Unreal. It already has a lot of the features I want for spawning Bullets. But first, I need the player able to register a collision with a bullet spawned using a Niagara System.  

I throw a Niagara System together quickly and finagle with it till the Player can register the collision, displaying the name of the component (the bullet) being hit. 

Here the player is successfully colliding with a “bullet.”

Next Steps

I can already tell that my original Gantt Chart needs updating. Some tasks I’ll be able to get done quicker than others (such as those for the player, popcorn enemies, and boss enemies). I’ll need to update the Gantt Chart before I continue to do more work. I also need to update the Gantt Chart to reflect a goal for myself, to have the Core Features working by next Dev Log, that I’ll post next Friday. We’ll see how that goes. 

On a final note, I’m going to start doing weekly Dev Log updates. These will be my reflections on the past week of work I do for my game. 

That’s all for now. Look forward to my next Dev Log! Find out next time if I’m able to build a simple game within a week. 

1 Comment

Comments are closed