v1 feature/bug fix discussion

majikayogames commented 3 months ago

Hey everyone, I'm working on SimpleDungeons again. Going to be fixing bugs and adding features. This thread is for new feature discussion/bug fixing.

The goal for the v1 update is to fix all known bugs and add new essential features.

Bugs:

I am using .duplicate() on rooms currently. This should be changed to using .instantiate() and have the user supply an array of DungeonRooms probably. .duplicate() has some issues and won't properly duplicate unique resources like collision shapes or other resources, causing weird bugs that are not obvious. DONE
Weird bug - Failed to instantiate scene state of "res://addons/SimpleDungeons/SampleDungeonKitWithModels.tscn", node count is 0. Make sure the PackedScene resource is valid. - if you set a glb as the packedscene, or maybe some other invalid node resource. Try to generate. Then put a dungeon kit back on, it won’t generate and refuses to even after save. Clearing var and saving fixes the hardstuck. Also seems like deleting .godot does too. Might be a bug in godot DONE. Think I fixed this just by adding a bunch of error checks.
If the stair rooms are oddly shaped, it could fail with an unclear error message. I think I have to rework how the graph is created and verified for placing stairs. The idea is correct I think, but I missed a lot of edge cases if it's not just a simple 2 floor stair room. DONE

For new features, I am going to add some essential ones, but otherwise trying to keep it as simple as possible yet flexible. There are too many various use cases to optimize for so I think I should leave it up to the user and make it easily moddable:

One idea, many people asked for more control of how to place the rooms. Instead of introducing a complex weight painting scheme of room selection probability for different areas or floors, I think it would be good to just introduce a property like .random_room_select_func which could be set to a callback like pick_random_room(floor_num, available_rooms) -> DungeonRoom`. This should allow a large amount of customization.
Also want to in general, like above, to allow for hooking into various phases of the dungeon's generation, and make it easy to modify the generation/post generation phase. Otherwise it will be a game of cat and mouse of adding small incremental features for everyone who wants them. More hooks & options for customization is better. Current ideas:
- .random_room_select_func which could be set to a callback like pick_random_room(floor_num, available_rooms) -> DungeonRoom`
- Pre and post generate hooks on the DungeonGenerator
- Pre and post room placement hooks on the DungeonGenerator
- Pre and post room placement hooks on the DungeonRoom. Maybe we could pass in some info to the DungeonRoom itself too if you wanted to customize it there or do some custom placement within it. Not sure if this fits more in DungeonGenerator random_room_select_func or similar, or DungeonRoom code.
- Expose the grid area more easily and intuitively/document it so you could use this in any of the hooks, to see what voxels on the grid are empty or check what is there
~~Add support for rotating rooms~~ DONE
Better dungeon editor/debug view. I don't like the AABB editing especially. AABBs are required so I think they should be set directly as a property on DungeonRoom. I'm thinking about it, I think there should be some "Voxel Scale" Vector3 property on both DungeonRooms and DungeonGenerators. Then, you set the AABB size in voxels. This way it is forced to be consistent everywhere. If you set it differently or non uniformly, the rooms would end up all being scaled and it would print a warning perhaps. You would then define the AABB in voxel coordinates, i.e. 2x1x1 etc. Then could have some clear in editor view of the AABB and where doors are. DONE
Doors - Can we keep everything as a tool script and also have them set as a property on the room, like an Array of Door objects or similar which you can set by clicking the voxel grid perhaps? Or just keep the current strategy of placing a Node3D for doors? Decided to use same format but with a better visual & some text to guide the user. DONE
~~More AStar algorithm options, currently it has a tendency to draw diagonal rooms because using dijkstras, I think Euclidian distance fixes this IIRC but we should have multiple settings for this.~~ DONE
Allow optionally viewing the generation in progress, good for visualization, looks cool and also is good for debugging. Ned to add this optionally without ruining performance if not doing this. Right now I have the rooms being placed and instantiated repeatedly. Probably should ideally do this virtually, and not actually place the DungeonRooms till the end (if not viewing visualization). Have to untangle what is happening here and think of the best way to do this. DONE
~~Add support to pre-placed rooms. You could pre-place a room and mark it as immovable for an entrance for instance which connected outside the DungeonGenerator.~~ DONE

If you have any other ideas for features, or know of any other bugs that need to be fixed, or have any other thoughts, we can use this thread for discussion.

majikayogames commented 3 months ago

Commited update still todo -some more example dungeon kits/rooms. want to add some interesting ones, and also prove out more some of the features, such as the custom room function, weird stair configurations, and use these as test cases.

-final pass for bugs i dont catch, was getting random errors with threading. godot doesn't like threaded typed arrays looks like and other things. maybe try to just simplify in general, and remove typed arrays whenever possible - also just throwing in some mutexes looks to have fixed stuff. looks like maybe over sensitive thread guards? so maybe just add a bunch of mutexes just in case for any threading code. and just see what bugs others catch. hopefully no more crashes. -documentation