Alright, last month I had the beginnings of the procedurally generated maze, and this month I’ve done a whole bunch more! So much in fact that I’m going to limit myself to 3 key things in this update: the maze mesh, recolored enemy sprites, and productivity process.
First, the maze mesh. Long story short, the game generates that now! I worked out how to create a mesh in code and then wrote code to move around inside it; here’s a quick video I captured of moving around the maze:
Looks pretty cool, just like I’m going for! Here are a couple screenshots from the editor showing different generated mazes:
(the dungeon’s textures are by lowpoly & 3dfancy)
So the base maze data was generated using this simple algorithm. Then I loop through the 2D array creating quads for the floors, ceiling, and walls (by the way, creating transformation matrices was easier than expected and super useful here). I also split it into two sub-meshes so that I can apply different textures to the floor/ceiling and walls.
The movement code is pretty interesting too. To make sure the player is always on grid spaces, facing in one of the cardinal directions, I don’t simply have them moving around freely and colliding with the mesh. Instead, I tween rotations and movements, and use the underlying maze data to determine when they’ve reached a wall and can’t move forward. Incidentally, I programmed both keyboard controls for testing within Unity’s editor, and a “joystick” that you operate by dragging on the screen. The keyboard input obviously won’t work once deployed to mobile devices, but both inputs work simultaneously in the editor.
The second thing I want to cover in this update is how I’m handling enemy sprites. Remember, a major design consideration for this project is that I’m exclusively using free or royalty-free art assets. For example, the combat system is such that I don’t need animated characters, just still images of fantasy monsters.
I’ve been finding lots of great enemy images in Unity’s Asset Store, but even then an RPG has tons of enemies. I plan to stretch out the assets with recolors, rather than needing to buy new art for every single enemy. Towards that end, I found an HSV shader in the middle of this thread on the Unity forum. I plopped an enemy sprite into the scene, put that shader on the sprite, and then played with the hue and saturation values. Here are some screenshots from the editor:
(the goblin is by Sergey Zagorulko)
Wow, that worked way better than I expected! Obviously adjusting the hue like this works better on some sprites than others, so I’m also planning to do custom recolors in GIMP. Still, I’ve already added a field for “hsv” into the enemy’s JSON data. Now I need to inventory all the art assets I already have, taking into account recolors, to determine how many enemies I can currently make, and thus how much more art I still need to obtain.
So switching gears a bit from talking about my game to talking about my process, I have adjusted my work setup in a very positive way! I take a train in to work, and it is a very looooong ride. Previously, my commute was just dead time where I was just messing around on my phone, and I could only work regularly on weekends.
However, it occurred to me that if I got a Macbook Air I could carry it with me always and thus work on the train. Previously I had no interest in that computer because it has pretty puny specs. However it has the significant advantage of being teeny tiny; I could’ve carried around my previous laptop, but it was heavy enough that I never did. Now I work on personal projects like this game for 1-1.5 hours every day! At this point I do more work on weekdays than on weekends.
Also, a special shoutout to git for being a great way to commit while offline on the train, and then push up a bunch of commits when I get home. I mean, checkout this sweet commit history just from the last couple days!
multiple commits every day yassssss