Caverns Test


was8bit 2022-03-04 09:37 (Edited)

... testing... this is just a test...

V02 updates lots of things, ghost movement still buggy

(Many thanks to mcpepic for the code for cavern design :)

Caverns 2.nx | Open in app
2022-03-06 06:11
Caverns.nx | Open in app
2022-03-04 09:37

was8bit 2022-03-04 09:42 (Edited)

Ive taken the code from the Space Flight Tests, and adapted it for my mountain caves in Cloudy Mountain game..

In this test, there are 2 sprites, player and ghost... both advance 8 pixels at a time, which allows for EZ checks for what is in a cell before and/or after this movement

Contact between player and ghost is done with SPRITE HIT, contact with walls or pickups are done with CELL.C

The tricky part was the math, which is different for player and ghost... now the math is all worked out, and i can this code and adapt it for my other game :)

McPepic 2022-03-04 15:29

Cool! Can’t wait to see this in the game. Just a couple of observations/suggestions.

* With how much walking there is, it would be nice to be able to hold the arrow down instead of simply pressing it every time you want to move (you can still move the player in increments)

* If you want more interesting cave generation, something I messed with before was a form of cellular automata. You simply loop through the tiles in the map and count how many neighboring cells each one has. Then you can use the neighbor count of each cell to create a new map where clusters of cells become more defined, making it look much more like cave walls

* I don’t know if it’s intentional, but I noticed that you’re moving the player before checking the cell and then moving it back. An alternative to this would be setting the target position, checking for collision there, and then moving it back to the player if there is collision. Then you could move the player position to the target position.

Just some suggestions. You don’t have to incorporate them if you don’t want to. Good work on the project!

was8bit 2022-03-04 17:01

Feedback is always appreciated, thanks so much !! :D

... part of my programming issues are that I am often half asleep when i code, how i get stuff to work is a minor miracle ;)

The TAP was a testing technique to restrict what to investigate if things go wrong (for example, I am not 100% happy with my ghost movement)... it will be smoothed out in the next update when I get my ghost movement satisfactory...l

On my Cloudy Mountain game, I have small caves that fit the screen... at the beginning of play, you have no candle power, so the only square that is lit is when you walk into the square... but my original code did only move if the space was clear... but then the wall you bumped into wasn't showing so I, as a player, wasn't sure if I bumped into a wall, or just didn't hit my arrow keys correctly... my easiest quick fix was to temporarily allow the move, and then I added code to reverse the move it was a wall..

It does make sense to allow the wall to be seen without the bounce back... it is on my "to do" list.. but I want to explore one more cave system, to see what I can learn from it (assuming I can get my big idea idea to work)

My small caves fit the screen... THIS one tests a cave system that fits the whole graphics memory (0-31) ...my next text will attempt a much bigger cave system... probably using MCELL

Thanks so much for tips on cave generation :) in my small caves I just start with all walls/rocks and then remove... but it does have issues... I will try your tips for this cave test ... hopefully with the next update :D


Log in to reply.