Small update for the roguelike project, well sorta. Im changing all the controls to a mouse based design and ditching the conventional keyboard shortcuts. Inventory and equipment management is far simpler now.. even though the nostalgia is gone :/ Movement is slightly clunky feeling though. I'm suspecting a possible bug in the alignment of the mouse to grid conversion.
I'm working on some visual ques to improve the use of the mouse. Simply highlighting the grid square the mouse resides on. I need to improve the logic and have it color coded. Something like a blue highlight being default and if the mouse is hovering over something attack-able, it'll red. If the mouse is over another interact-able such as an item or door it'll highlight green.
a slightly less noticeable highlight will light up each tile leading to the hovered over tile. Unfortunately I haven't implemented path finding yet. I've been kinda dreading this actually. I'll be going with a typical A* algorithm, it's what I've always used in the passed and am most familiar with with. I fear without implementing the path finder directly into my grid class, it might be too slow to be immediately calculated every time the mouse moves to a new square.
My grid class was designed as a random access interface and very brute force about it. You might say it'll be fine because obviously my LOS/FOW algorithm uses Breshenham's line algorithm to cast 360 rays around the player to determine the FOW each movement and the player can move rather fast. That's not entirely accurate, under those circumstances there is actually almost a 1 second stall between movements. I actually only cast an 8th of those rays, and use a anti aliasing style hack to keep the sight clean. This can really be notice in big rooms where the edge of view has a large edge. It's not a perfect circle and is very blocky.
My goal has been to keep things as modular / encapsulated and clean as I can through out the project to avoid nasty spaghetti code that might force a re write again. I want the pathfinder to use the grid class rather than be apart of it. I've got a few ideas on how to improve the logic behind accessing the grid and or implementing an iterator. Which might actually be a better considering the pathfinder and the line algorithm both access one tile randomly and then traverse from the one tile.
SIDE PROJECT
I'm gonna start a small side project to test and work out some of these changes in a less cluttered environment. I want to finally create some basic GUI elements as well, nothing bigger than basic buttons. I've already got several classes I've hacked together for the Roguelike project. I want to clean them up and improve their functionality.
The projects gonna be a basic old school rpg of sorts. The game will take place on a world map that has a series of way points. Each waypoint is an area that the player can enter, either a battle or a town. Basically the world map represent the campaign timeline. Each area / waypoint must be cleared before the player can progress to the next waypoint.
The player will be a 4-5 character team. The player can build the team out of a pool of characters. All of which can be recruited at the towns and will have unique abilities or stat progressions. Only one of each character can ever be owned by the player. The player can further equip the characters with items bought from the towns.
Battles will be automated with an old school rpg look. Think the old Final Fantasy series, with each team lined up on each side. Each character ; player or ai, will have a battle timer that determines when they can attack or use an ability. So things will be real time.
Nothing major, and probably won't even come close to being finished, just need something to test ideas with. This is just how I tend to learn ;)
Till then happy coding.
