& now for something completely different: a top-down maze level that blatantly rips off Pac-Man, but without the fancy voice clips o’ someone swearing whenever they die.
Like Pac-Man, there are 4 antagonists that chase you, in this case eyeballs, ’cause ’twas a convenient graphic I had lying round. They can sort o’ be distinguished by their shade—a limitation due to my insistence on 6-color monochrome palettes; however, this isn’t that useful, anyway, due to a twist I added: every 15 seconds, the eyeballs switch roles. So, to use Pac-Man terminology, imagine after 15 seconds Blinky starts acting like Pinky, Pinky starts acting like Inky, & so on. They don’t change their current position or appearance, just their behavior. They continue cycling down the types every 15 seconds, returning to their original type after 1 minute.
The eyeball chasers do act like the Pac-Man ghosts, with 3 out o’ 4 o’ them having AI based on ghost behavior. They target a certain tile & test each possible tile they can move to next to see which is closer to that target tile in terms o’ the distance based on a straight line. The top-left eye follows the player, like Blinky; the top-right aims for the tile 4 blocks in front o’ your player, sort o’1 like Pinky; & the bottom-right eye aims for the player, ’less it’s 8 blocks nearby, in which case it aims for the bottom left corner, like Clyde. The bottom-left eye is the only exception: rather than the immensely obtuse method2 Inky uses, it just aims for a random tile every tile it moves. Though part o’ me kind o’ liked the o’ercomplicated nature o’ Inky’s pattern, it requires knowing Blinky’s pattern;
& in my game, it’s actually, I’ve just thought o’ a simple way I could do it, ne’er mind.
Truth told, I feel like I’ve ripped off Pac-Man too much. I wanted to add mo’ eyeballs with my own made-up patterns, since it seems like a fun exercise to try, but I felt that’d make the game too hard. Maybe I’ll change the Clyde equivalent, since its pattern is kind o’ dumb, anyway. 1 idea I had was a sort o’ smarter version o’ Blinky. As Birch notes, due Blinky’s distance check for tiles is simply a straight line that ignores solid blocks, there’s a chance it’ll take a less efficient route if the player is to 1 side o’ it but the quickest route is in the other direction. A smarter algorithm would involve using recursive tile searches throughout the whole maze to see which path that ends with the player takes the fewest tiles.
Other than the eyes shifting types & speeding up after 15 seconds, & the Blinky equivalent speeding up after a minute, these eyes’ AI is actually simpler than the original Pac-Man’s, with no “scatter” behavior, &, ’course, no power-pellet or fleeing behavior. This isn’t truly s’posed to be an exact copy o’ Pac-Man, &, if anything, could use a bit mo’ originality.
I suck @ Pac-Man, & as the video shows, I wasn’t able to beat it, e’en with 4 hearts in the corners o’ the maze. You’ll have to take me by my word that collecting all 669 gems beats the level. I’m thinking o’ having this be a bonus level, since it has a high reward o’ 66,900₧, which is mo’ than 3 times the max collectible in any other level. I thought ’bout making the maze smaller, which may ease the difficulty, but I kind o’ like the huge maze. Maybe I should just make ’nother maze level that’s smaller.
Also, I converted project from Code::Blocks to plain Make, since Code::Blocks has this tendency to crash randomly & I prefer the less cluttered interface o’ using text document programs & folders, rather than having the thin bar on the left all the time & having to scour it for the files I want.
The 1 downside—though, now that I think ’bout it, it’s pretty neat, actually—is that Make causes bizarre glitches sometimes when changing header files quite a lot & making without clearing out all the objects. I was lucky ’nough to get a video:
This isn’t a dire problem, since it can be solved simply by running “make clean” before it happens. It just wastes extra time, since I have to recompile the whole program afterward.