Re: Representing 3d Staircases? (Python)
A binary search before every write is indeed the solution. You lose out on the write performance in exchange for the read performance. That said, it is actually bounded. You have the following cases:
1. The tile isn't set, so you just insert the new entry.
2. The tile lands on an entry that's 1 tile high, so you just replace it.
3. Or the tile lands inside an entry that's "too big", so you split the entry before and after the tile, to make 3 new entries.
But in all cases there's a finite amount of work to do, not an infinite loop.
Have you Googled on these topics? You should be able to find most of this info without me.
If your immediate thought is "but moving objects will be slow" the answer is objects shouldn't ever live in the tilemap even in a 2D game, let alone a 3D one, and should be separate entities with a position.
If you decide to proceed further with this, it's possibly worth looking at py.test and learning to write test cases. I would go one step further and get something called Hypothesis to help out here, but it's probably nowhere near newbie friendly to someone who probably hasn't done a bunch of test suites yet (but then I've never tried to teach hypothesis to someone, and only learned about it a few months ago myself).
But, here's the thing. I have tried to ignore the elephant in the room but you're having enough trouble that I'm just going to bring it up anyway. While I think it might be barely this side of possible to make a 3D audiogame, the algorithms to build a workable UI around it make this look like nothing by comparison. The algorithms to do efficient collision detection are roughly of this complexity or worse. Likewise for pathfinding. Likewise for a bunch of other things. No one even knows how to make level editors for this kind of thing either. My best idea for it is an entire custom domain specific language to describe maps as semantic pieces that you stitch together. People have tried this before and either they halfway sorta succeed (CAE for instance) and their game is playable by almost no one but the author, or they discover that all of the problems you're going to face with respect to converting a 3D environment to audio haven't been solved and are even arguably unsolvable.
I would suggest stepping back and doing something 2D. I would have said something along these lines sooner, except that I've watched you learn incredibly quickly and I have ideas on how this could be done myself. But fair warning. If you keep going you're going to keep hitting your head against walls indefinitely--algorithmic walls, we don't know how to expose this to blind people walls, we don't know how to even let me build the levels walls.
I would rather say this, get called pessimistic again, and see you succeed at a not-quite-as-ambitious project, than not say something and see you quit in frustration in 3 months.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
