Devlog #3 | Reworking the Dungeon System

In this iteration, I decided to completely rewrite the dungeon system from scratch, once again using JavaScript as a development base. This allowed me to test ideas quickly before attempting to port the system to GameMaker. However, when I tried to implement it in GameMaker, I realized that it would be a massive resource drain and quite challenging to achieve due to GameMaker’s limitations and coding style.

What does the system do now?

The current system works as follos:

1. Generates a terrain, where you can define its size and the number of rooms you want.
2. Places the rroms accross the terrain.

• Marks true for walls (impassable zones) and false for the floor (walkable zones).

1. Places the player in the center of one of the rooms by setting the starting position (startPos).

Visual Example: Room and Wall Generation

Progress: Connecting the rooms

Once the rooms and terrain are generated, the system:

• Detects wall centers to find potential pathways.
• Creates paths to connect the rooms, ensuring all are accessible and no room is left isolated.

New Approach: Using an External Server

Given the inefficiency of directly porting this system to GameMaker, I decided to take a different approach:

• The system now sends an HTTP request to a JavaScript server running on bun.sh.
• This server generates the dungeon data, including terrain, pathways, the player’s starting position, and more.
• Gamemaker only iterates over the response, placing blocks (objects) in their respective positions. This offloads all the heavy processing to the server, while GameMaker focuses purely on rendering and gameplay.

What’s Next?

In the next iteration, I plan to:

• Implement the logic for placing keys and enemy spawners using the same approach as the player’s stating position.
• Optimize communication between GameMaker and the server to minimize loading times.
• Ensure dungeon generation and loading remain seamless during gameplay.