Game Dev Engine #11. Maze Generation.

[@unclvinny]

Fun! I like the music in this one, too.

[@JDoucette]

Me too! Notice the name of the song? "Juno In The Space Maze" :) But I didn't choose it on name alone -- I was looking for a neat retro tune that was about the same length as the video. If you can believe it, I made the video first, and then found a song to fit -- not the other way around.

[@Xonatron]

This is very cool.

[@JDoucette]

It is just the basic back tracking algorithm. I had just viewed A-Maze-Ing (the TI-99/4A game), and watched the title screen in slow motion, and it appears to draw one "snake" at a time, with ever increasing pitch, but it seems to stop after a certain length, or if it hits a wall -- but it doesn't continue to find other paths, it ends the snake. This is actually better than the back-tracking, which tends to produce long, single paths, and are quite easy to navigate. But it has the problem of not trivially knowing what is left to fill. I was going to implement this, but settled on the quick and easy algorithm first.

[@JDoucette]

Another algorithm I want to try is one that I invented: a pure random maze not dependent on existent generations. Merge any two random adjacent cells. Take care to understand independent graphs, and ensure to merge them only once, for a perfect maze (only one solution from any two points). Keeping track of the independent and then merging graphs is conceptually easy, but is more work for larger mazes. This could be fun solve.

[@JDoucette]

Another idea, applicable to all maze styles, is to remove any immediate dead ends, to either prevent them from adding noise (maybe this ends up being aesthetically poor though, since maybe filtering through the noise is part of the fun?) or you could covert their cells to merge into a large empty room, for dungeon design in a game, or overview world design for towns in a forest maze.

[@jumbledfox2098]

i've written a few comments on your videos now, i'm excited to see your responses to them haha, but GOD your work is just so inspiring!! the amazing aesthetic, the whole thing, it's just brilliant. it's really making me want to make something similar, so thank you

[@JDoucette]

You probably noticed the aesthetic improving each video -- a simple backdrop to the text to make it stand out, and the shadows on the windows are oh so easy, and recommended by viewers, and it was on my list, but it's just a matter of getting to it. When I make an improvement, it stays for all time; so it's nice to always be improving a little thing here and there, as you get on with the main work.

[@JDoucette]

As mentioned in another video comment, I just wanted to align text and images for presentation, so I made some rectangle struct, and then spaced them out next to each other -- and I thought these should just be windows. Then the stuff inside the window can align itself to its window, and windows can align themselves. It's about ownership. But once you have a window and it can draw itself, then its X,Y coordinate can change. Each window has its own render target (texture) so even the components that draw to the window just believe it's the entire universe. The window manager will draw them, and ask them to update, but each window just does its own thing.

[@JDoucette]

So yeah -- no immediate mode UI. Just a list/array of Windows, and the manager is in the main update/draw loop in the game system. Each frame, components are asked to update, then draw. The window manager is the only thing the game system touches (in this context). It hands off calls for update/draw to each window that was created. Each window has its own render target, so when each window calls its own things (see the example games I've made) to update/draw, like simple Sprites, it does so to the render target already set by the window manager. Thus these little games just are basic sprite movement/draw code, and they have no idea they exist in a window (other than its size info is made visible).

[@JDoucette]

This is also why it was trivial to have windows own other windows. In my case, I did this just like Win32 did, to allow for status bars, title bars, etc. -- since I didn't want each window to have to maintain its own view style, and font. Therefore, you can generate a window that has 2 windows inside of it: the title and the canvas. The games live in the canvas window.

[@jumbledfox2098]

@@JDoucette aaah, that's very wise and nicely done! i'm excited to make another UI system now haha