Zero real progress all week. Wow that went horribly wrong...
Alright, I was planning on forgoing this post entirely, at least until I could get anything approaching real progress this week, but I think this provides great insight as to why games take so long to finish, so I'm going to go ahead and tell you exactly what went so wrong.
First of all, turns out the code I was using to do normal map handling isn't exactly very versatile. I tried for hours out of every day to think of a way to apply it to the background without making the game's file size somewhere around 3-5GBs or severely harming the game's performance.
If it's not already obvious to you, performance is a really big deal to a video game. It doesn't matter how good your game is, if it's running at under 35-36 frames per second, players aren't going to be having much fun. A game can get down to 35 frames a second as long as ultra precision isn't a requirement, but any lower and it starts to become unplayable. Players will still complain if it drops below 40-ish, but the game won't suffer too badly just as long as the frame rate drops don't hurt players' ability to play.
File size isn't a super big deal, but I don't want a game that's going to be several gigabytes without several gigabytes worth of content.
So I went to the Yoyo Games forums to ask for help. There, they pointed me to a superior set of shaders that will be able to do what I'm looking to do without effecting the file size any, and hopefully without sacrificing a lot of performance. The only downside is, it's not for free. The shaders are super powerful and apparently very fast, which I'll need. But the guy who made them naturally wants his months of man-hours compensated. But I can't afford it right now. Well, I suppose I could, but that would be cutting it really close.
Alright, so I can't do shaders for a while. No big deal, I'll just work on enemy pathfinding. Enemies behaved bizarrely while trying to chase the player, due to their "attack range". They wouldn't stop walking or update direction until the player was outside their attack radius. This would make them follow in awkward, seemingly mindless ways. They could also plow straight through walls and obstacles to reach them, or return to their original position. I didn't want them to just run into walls and get caught if there was no straight path for them. I wanted them to actually be able to plot a path back. Should be easy, right?
Nope. Turns out A* algorithms aren't as simple as they sound. A* (pronounced A-Star) are a complex set of algorithms that calculate shortest possible path to a designated point while avoiding specific, designated objects. Unfortunately, it does this via grid. And that's the problem. Think of it like chess. It would move like the Queen piece. It can move in any direction, straight and diagonal, but it can't move like a Knight (the horse). If you put a Queen and a Knight on the same space and moved the Knight, the Queen would have to zigzag her way back to the Knight. She can't just move like the Knight does, or cut across spaces to reach him. And using A*, that's exactly what enemies would do. Zigzag after me if I were, say, a Knight's move away or more, on the grid. This is very noticeable.
Now, of course I could just shrink the grid down to 1x1px but the smaller the grid spaces, the more time the computer would need to calculate the route. And without being able to calculate diagonal movement, it would take even longer. (Contrary to popular misconception, there is no such thing as half-pixels, and you can't really cut diagonally across pixels, either.)
Funfact: It is quite possible to move things a fraction of a pixel in a video game, but it will squeeze and stretch parts of the sprite as it goes, because a sprite itself can't move less than 1 pixel, even though the object drawing it can... technically... sort of. It can be best explained by having a single blue pixel. If you try to move that pixel half a pixel to the left, it will most likely be stretched to fill both pixels, because technically it exists in both pixel spaces, but since half a pixel can't be rendered, it has to compensate by elongating the single pixel into two pixels. To represent being in both spaces at once.
I didn't get absolutely nothing done, though. I did take the time to set up player-wall collisions. (I've been developing for months without the engine paying much heed to walls aside from the fact that if the player went behind one, the enemy couldn't see him any more.) Now that a friend of mine has the day off, I can work with him to find a solution to the A* algorithm. (He's a programmer)
Unfortunately, this means I don't have screenshots to show, this time. But in order to keep this roadblock from killing off this project completely, I've been working to improve my techniques in 2D art. It's going quite well!
I may kill off a lot of projects when they start to bore me, but each and every time I do, the experience I gain from them transfers over into the next one, so when I eventually do manage to finish a game (I'm hoping this one will be it) you can rest assured it won't be anything amateur.