The Shelving
I have shelved Halloween Game. There we go. Shock over. I suppose I have to explain why.
I've previously talked about Halloween Game originating from a 3DS homebrew project I attempted to make years ago. Homebrew games typically aren't huge in scope, since they are primarily done by hobbyists since anyone that is able to work on a game for a living would attempt to go for a commerical release.
The problem I was having was Halloween Game is a homebrew scope game attempting to go commercial, and my attempts to fix the holes that cropped up as a result of that weren't working.
The core idea is you play through dungeons, defeating monsters and unlocking costumes. I think that idea works, but I wanted to flesh it out more. Why was the player going through dungeons? What was the purpose to collecting costumes?
An introduction to the game gave the player the task of going through dungeons and ridding them of monsters, and in exchange they'd get something that they had lost. Then I made the costumes have stats instead of being purely cosmetic, and then decided that boss fights would not actually be fights and effectively be minigames.
But none of that solved the problem I was still having in that it would still be really repetitive working through the dungeons and fighting the monsters. Mixing it up with puzzles would probably aleviate some of that, but that meant coming up with puzzles and I was struggling to think of them.
After working out I needed about 350 rooms, I thought the best course of action would be to just design the layout of each dungeon and mark which rooms should have puzzles and I'd come back to them later. That way I could still work on generating all the other rooms.
Although at this point, I'd had a niggling feeling in my mind for weeks. I was not as confident in this game as I was with the football game. Part of that was down to the discovery that the idea wasn't as fleshed out as I thought it was, and part of that was not really believing in it enough.
Recently my first D&D campaign has come to an end, and in the run up to it ending, I was coming up with a character to play as during the second campaign our group is going to start soon. Whereas my first character's backstory was pretty much "Their race is x, so they grew up in y. Their class is x, so they do z," my second character is more fleshed out to the point I was thinking "I could write a book about this." And then I thought "I could make a game about this."
With that spark, I immediately had a concept for a game that was way more fleshed out than Halloween Game ever could be. I'm not going to make a game about the backstory for my second character, but it will be set in a similar world.
Halloween Game isn't completely dead. Even if it sits on the shelf forever, it's got some incredibly useful code that I can reuse in future projects. I scaffolded this new project using the dialogue and input systems, moved over the graphical scaling, and the integration with Steam so I can hit the ground running with over 100 files of code that I know already work.
And I had a peek at some of that code in the Ludum Dare.
What I didn't have was code that had grid-based movement. I started writing that before doing the game jam, but that weekend took so much out of me that I struggled to put the final pieces in. And when I did, I discovered it didn't work anyway.
I spent the next week rewriting grids. First because it was creating "phantom" squares that would draw on screen, and the player could move to, but weren't actually part of the grid system. Then because the grid was the wrong way round. And then again because grids are more complicated than I thought they would be.
They do have the advantage of doubling up as a collision system that can be used for AI pathfinding. With the code for the AI written, and a bunch of unit tests passing, I tested it out in the game. The AI managed to get to the final spot and not go through any of the objects in the room. It just decided to go to every other square on the grid first - even walking past the final spot several times.
Between still having not recovered properly from the Ludum Dare, and being frustrated with having to rewrite grids and now potentially ripping up the AI, I had a crisis.
One of the struggles of Halloween Game was not having a level editor, so why was I running down the same path again? Sure, I intended to make one, and it would get to pay off twice - first in that I'd get to make the game, and second when it would be available to players to make their own levels.
But why was I deliberately making this harder? I hadn't looked at the internet when writing my grid code, or when doing pathfinding. But if I had, I'd likely have got it all working without rewriting anything. Why was I sticking with MonoGame when Unity has so many more useful tools? I kept telling myself it was so I had more control, but control over what? I was just reinventing every wheel, and having to redo them after making them square.
The new game also had a big problem in the animation department. Whereas I could draw out the grids and pathfinding on paper and then translate them into code that didn't work properly, I couldn't even figure out how to create an animation system that let me cut corners for a game with potentially hundreds of characters without having to animate each of them separately. How could I create a rig for a 2D character without splitting the sprites into parts? How could I mathmatically bend pixels and not have the result look terrible?
I'd come across animation packages for Unity that did things along the same lines, but none of them did exactly what I wanted. And then I questioned why I wanted it to be 2D anyway. My mind previously decided things have to be 2D in MonoGame, even though 3D can be done, because it's "easy" to do. And as I was considering the move to Unity, why not make the move to 3D?
A fellow game dev was showing his new setup to do cinematic cameras, and he asked if I was going to do something similar in my game, to which I replied that it was probably overkill for a 2D game. But it did make me think it would be nice for players to pan around with the control stick, and my current plan for the camera would prevent me from showing things in the sky since it was all top-down isometric. If things were in 3D, I could have more control over that without having to do variants of sprites depending on the camera's rotation and position.
Plus I'd gone through the pain of figuring out how to model in Blender earlier in the year back when football game was still a thing, so why not lean into that?
So, after two weeks of initial development in MonoGame, I switched to making Adventure Game in Unity. It is an RPG where the player picks one of several classes and goes off on an adventure (the working title is The Adventurers, and the project namespace is Adventure, although I don't like either so it definitely won't be those).
