Non-Named (More debugging)

[Filler]

Added the player's money on the HUD. The variable was already made from the game's start, but there was no visual way to see the amount in-game.

The number provided is a placeholder.

[Filler]

Battle scene now has the amount of character spaces in the HUD to reflect how many characters are in your party.

[Filler]

While I've mostly been working on gameplay stuff. I did do some concept art. Though, they constantly change with how much I revise the game's concepts and story.

For example, the original map concept has already been rendered null due to massive changes in how I wanted the map to work. (not to mention it's crudely made)



I need to learn how to re-arrange concepts better.

[Filler]

Sometimes while doing stuff not related to game design, I have concepts and thoughts of ideas that would work in game design.

Anyways, I thought of a simple system for overworld enemies based off the simple sets of flags and variables in their behavior. This would allow me to set each enemy to have various different aspects that make their movement. The first five are really simple number-based variables:

• Movement speed (in units)
  
• Reaction time to move after seeing the player (in seconds)
  
• Movement speed after seeing the player (in units)
  
• Distance (in units) to notice the player 
  
• Enemy level
  

These five are pretty simple, but I might as well explain them:

• Movement speed is the amount of units a frame they move when doing their own stuff.
  

• The second is simply how many seconds it takes for them to move after the little "alert" sign appears above their head. 0.2 seconds would roughly be a common reaction time. While slower enemies might have a reaction time of 0.5 seconds. (Half a second)
  

• The third is how fast will they move in units once they've been set to be alert to the player.
  

• The fourth is a bit more complicated to explain. But each enemy has a simple formula that determines the distance away from the player's X and Y position they are. As technically, they always see the player, but they won't react until they're close to their radius of reaction. This gives off the illusion that they don't see the player, and is determined by a variable amount of units.
  

• Enemy level is simply their level. If the player's level is above the enemy's they might become scared, or run away, different variables will change how they react to this.
  

These next variables however, are a tad less obvious, and relate to enemy level:

• Hides when scared (furthest, closest) (Position, actor)
  

• Runs when scared
  

• Doesn't react when alerted. (scared, chase)
  

I'm going to explain these three, as they can be a bit complicated:

• The first one is something actually pretty complicated. And relates to a list of "hiding position" that are just a list of X and Y positions stored on the map. Once the enemy reacts to the player, and is scared, the enemy will run off their reaction range, and it's behavior will sort up the list of hiding positions to either high-to-low, or low-to-high, and then choose the top result. Making them either run far away, or pretty close. The same thing could be applied to enemy actors to sorta use them as shields.
  

• Runs when scared simply means they'll move away from the player when in range then chase them.
  

• The second is just that they won't react to wanting to rush the player, or being scared. Meaning you can create enemies that are confident, and will fight an overleveled player, or they'll only fight if the player actually decides to attack them.
  

The next is movement patterns when not reacted, and I don't think I need to explain this:

• Moves up/down
  
• Moves left/right
  
• Moves randomly
  
• Patrols route (based off a list of positions to follow)
  
• Doesn't move
  

And this is how they space their movements:

• On/off for a set amount of seconds (variable)
  
• On/off for a random amount of seconds (from 0 to maximum number of seconds variable)
  
• Never stops, always moves
  

As you can tell, this is a pretty advanced list of functions that can make enemy AI seem different with each one. Of course, the actions they do once reacted are predictable so the player can predict and plan their movements once they've learnt how the enemy acts.

[Filler]

Example of enemies hiding when scared.

[Filler]

Going to try some sort of Pathfinding to see if i can get the enemies can hide in more than just the nearest raidus.

[Filler]

On second thought, I might start writing up some ideas for game story again, as I had a really weird dream that might work as a concept. I'll get back to updating this thread once the ideas are in place.

[Filler]

Map thing, not going to show much maps due to the fact not everything is final. Sorry if my rushed chicken scratch has some bad handwriting.

Also, maps are going to be small, and loaded in zones, as it's easier to load, and is less stressful to people with potato computers. (Arrows represent loading zones)

[Filler]

VERY early map design applied from the chunk of concept below.



The graphics on the areas still need some major ironing out in order to not look pukey.

[Filler]

Updated shopping plaza area concept art.

[Filler]

Testing out faked lighting effects. It's just an overlay placed over the map that is transparent, giving an illusion of lighting.

Also, I'm going to give a sneak-peak of the map made from the concept art I drew a bit ago. Since I spend way more time than I should making maps, and it'll take a bit for the final version

Here's a full map picture.

[Filler]

Some more polish is needed, but so far, it's looking good.

[Filler]

Final time I'll be polishing up this map for awhile, as it's time to work on other maps than just letting one become over-bloated with content.



Anyways, I've planned out how the dev cycle will work:

-Basic engine and writing is in place

-After that, maps, and sprites will be added upon

-Finally, content begins form a proper state (Beta)

-After that playtesting becomes a thing. I test what features seem to work well, or seem to not work.

-Crashes or broken content is tested here, and should be removed. This is when bugtesting becomes a major thing.

-After that, content either gets cut, or new content is added. At this point, mechanics and such will not be altered unless it's for major reasons.

-At this point, the game should be able to be played from start to finish without any real issues. Possible teaser demos/videos come out at this point.

-Audio design (music, sounds) are added here, so that they match the theme and design of the general game.


-At this point, proof-reading is being made. Assets and code should not be altered unless it's major.

-Final playtesting begins, making sure the game is as bug free as possible.

-Game is released.

[Filler]

So this happened after trying to load the game after a computer crash. Happily, I backed the game up daily before the crash happened, so I was lucky.



The program pretty much generates an error when it loaded during that time, refusing to load the game. This is a lesson on why you should back up all the time.

[Filler]

Just testing memory usage from multiple instances of the game. I know my coding skills are quite bad, but that's some nasty memory usage from a 2D game.

Anyways, start writing up the game script, since I have some basic ideas of the locations mapped up. I may or may not make a blog for game coverage instead of this thread, as that'll reach out for a larger audience.