Room-based Generation #1

New Issue

layla · 2019-12-05T09:58:54+01:00

yeslayla commented

2019-12-05 09:58:54 +01:00

(Migrated from github.com)

Instead of randomly placing pathways between rooms, use premade mapping to create ways to access rooms.

For example:

x -- x
     |-- x
     x

Each x would be a room object and - and | would be corridor objects

Using this method, levels will appear better thought out, less "random," and more immersive.

Instead of randomly placing pathways between rooms, use premade mapping to create ways to access rooms. _For example:_ ``` x -- x |-- x x ``` Each `x` would be a room object and `-` and `|` would be corridor objects Using this method, levels will appear better thought out, less "random," and more immersive.

layla commented

2023-12-10 00:23:24 +01:00

Good resource for implementation of this:
https://gdquest.mavenseed.com/lessons/introduction-adf74ee1a27a04e6

Good resource for implementation of this: https://gdquest.mavenseed.com/lessons/introduction-adf74ee1a27a04e6

layla added reference feature/godot4

2023-12-10 00:23:40 +01:00

layla added this to the Rework project 2023-12-22 17:15:55 +01:00

layla commented

2024-01-16 21:41:58 +01:00

Huge progress in cd80ab3357

Essentially, buggy implemention of the generator is there but time will need to be spent creating individual rooms for testing and then debugging any . (Since this code has technically not been .)

I think my biggeset concern bug wise is here in standard_generator.gd:

# Instantiate the room
var room_instance: StandardRoom = room.instance()
room_instance.position = room_edge_pos + (room_instance.size / 2)
room_instance.queue_free.call_deferred()

		scripts/v2/worldgen/standard_generator.gd
		Line 125 in cd80ab3357
	
						room_instance.position = room_edge_pos + (room_instance.size / 2)

I'm worried that setting the room_instance position by the room size will be incorrect. It could process where its the origin point is in the center of the room instead of the top left. (the origin point should be cell 0,0)

Huge progress in https://gitea.layla.gg/layla/glitch-in-the-system/commit/cd80ab3357c1e9ec40c5630f3b434c47b367754b Essentially, buggy implemention of the generator is there but time will need to be spent creating individual rooms for testing and then debugging any . (Since this code has technically not been .) --- I think my biggeset concern bug wise is here in `standard_generator.gd`: ```gd # Instantiate the room var room_instance: StandardRoom = room.instance() room_instance.position = room_edge_pos + (room_instance.size / 2) room_instance.queue_free.call_deferred() ``` https://gitea.layla.gg/layla/glitch-in-the-system/src/commit/cd80ab3357c1e9ec40c5630f3b434c47b367754b/scripts/v2/worldgen/standard_generator.gd#L125 I'm worried that setting the room_instance position by the room size will be incorrect. It could process where its the origin point is in the center of the room instead of the top left. (the origin point should be cell 0,0)

layla commented

2024-01-17 00:07:04 +01:00

So thinking about the problem while laying down and it's actually a lot more complex.

It would be different by direction.

Top: exit_pos + Vector2i(0, new_room.size.y)
Left: exit_pos - Vector2i(new_room.size.x,0)
Right: exit_pos + Vector2i(new_room.size.x,0)
Bottom: exit_pos - Vector2i(0, new_room.size.y)

(this might be able to be simplified by multiplying a vector by the exit direction vector)

May need to add an offset by 1.

Also will need add error checking to go through every tile in the given rect to make sure that there isn't overlap. I don't think the existing checks are sufficient.

So thinking about the problem while laying down and it's actually a lot more complex. It would be different by direction. Top: `exit_pos + Vector2i(0, new_room.size.y)` Left: `exit_pos - Vector2i(new_room.size.x,0)` Right: `exit_pos + Vector2i(new_room.size.x,0)` Bottom: `exit_pos - Vector2i(0, new_room.size.y)` (this might be able to be simplified by multiplying a vector by the exit direction vector) May need to add an offset by 1. Also will need add error checking to go through every tile in the given rect to make sure that there isn't overlap. I don't think the existing checks are sufficient.

layla commented

2024-01-21 00:46:31 +01:00

So now the level generation itself has been implemented.

What's left:

Spawn & Character Generation
- Essentially just placing a single object that will be replaced with a player object
Enemy Spawn Locations
- Multiple markers in every room that have a chance to spawn an enemy entity
Upgrade Chip Spawns
- Multiple markers in every room that have a small chance to spawn an upgrade chip
Exit Generation
- I'd like this to be done by having multiple exit markers in every room. The marker furthest from the spawn marker will be replaced with an exit. The rest will be deleted.
~~Additional rooms for variation~~ Out of scope for this ticket

So now the level generation itself has been implemented. What's left: - [x] Spawn & Character Generation - Essentially just placing a single object that will be replaced with a player object - [x] Enemy Spawn Locations - Multiple markers in every room that have a chance to spawn an enemy entity - [x] Upgrade Chip Spawns - Multiple markers in every room that have a small chance to spawn an upgrade chip - [x] Exit Generation - I'd like this to be done by having multiple exit markers in every room. The marker furthest from the spawn marker will be replaced with an exit. The rest will be deleted. - [ ] ~~Additional rooms for variation~~ Out of scope for this ticket

layla closed this issue

2024-01-21 16:05:33 +01:00

Sign in to join this conversation.