Testing out a total of 3MEG bitmap sprites with PeeJay's Random Maze Generator.
Nice :)
Cool. If you're interested (which I doubt!) the maze generation function is using a modified randomised Prim's algorithm - and I think I may have found a bug in the code :( I'll post a bugfix once I have had a bit of a play .....
Excellent stuff, now add some stats, treasure and baddies! :D
thx kindly dudes
:) Oh yeah, although I'd like to create more detail in the tile mapping, zoom scaling, sprite management and path finding (pj?).
bigsofty, the baddies are there, almost, although the wall collision is a bit clumsy. That is why I tested two characters for bitmap loading and I'm hoping to add many more, depending on available run-time memory. I need to test LOADANIM, to increase level loading as currently it takes awhile to load individual bitmaps.
Treasure, pickup, quests, doors, etc will depend on game-play, which I hope to make interesting and not just a maze game. Perhaps some level may be hand created, like with Mappy. I need to find out the technical limits mentioned above before I start on this. I've even opted out of isometric for now.
peejay, is the path thickness modifiable? For example, 3 tiles wide yet 1 tile for the wall. Entry and exit points would help. I'm not sure what the bug results, but I'd be happy to update the code in future.
The bug fix is out - it meant that there was the possibility of having a block of 3x3 gap near the maze edges - this was due to me compacting everything into one function (and making a hash of it!), but has now been fixed.
Entry and exit points can be anywhere around the edges of the maze with the variable value being an odd number (eg
- [7] or
- [21] or [13][0] - you get the idea!). When I get some time, I will look at adding A* path finding (which is what I used in my Maziacs game)
As for variable thicknesses for walls and paths, this is not practical. Given your example of 3 tiles for the path and one for the wall, if a column has 5 path cells and 5 wall cells, that would make (5.3+5 cells = 20 cells) - but if the next row had 6 path calls and 4 wall cells, that would mean (6.3+4 cells = 22 cells), thus meaning the whole maze shape would become totally distorted and unmanageable
For pathfinding, use FINDPATH command. However, PJ's maze has 1 and 0 inverted. Thus, you must prepare the maze data once before.
OMG - there's a built in FINDPATH function!!!!!! LOL. I really need to read the whole help file. ;)