Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Post-Mortem

I got a new laptop a few days ago, but between catching up on my actual work and  the family dog getting very ill (he's recovering now!), I haven't had the time or inclination to get back to my game or get stuck into everyone's submissions. Things are settling down now, so I want to write a quick post-mortem of my failed submission to get myself back into it!

Puzzle Wizard was an attempt at a new type of Puzzle RPG battle system using Tetris blocks instead of match-3 gameplay. I tried to assemble the prototype in GameMaker Studio, because I'm most familiar with that engine from tutorials (in comparison to Unity, which might be better for developing a full-scale game out of this but which I'm far less comfortable in). I had to put the project on hold because of technical difficulties, but I got enough done to have a sense of what I'm proud of and what could be better. I want to use the post-mortem here to talk about a couple of the challenges I faced during development.


Programming / coding

This game was programmed in GameMaker using a combination of its drag-and-drop events and code written in GameMaker Language (GML). GML doesn't seem like a hard language to pick up, relatively - it looks a lot like Javascript, and the help files for GameMaker are really good - but I'm not a natural coder and I had to figure a few things out as I went along.

In that respect, I'm really happy with the programming work I did. I've had this idea for years and put it off because I didn't think I could program it, but the progress I made in the last couple of weeks is a huge confidence boost. I'm particularly proud of my ability to solve problems using what little I know about programming. For example, the target shapes that the player must match to attack the enemy are stored as 64-character strings in each enemy type, and built character-by-character as they are required. There are probably more efficient ways to program this, but building it this way allows me to write the shapes for different enemies directly in a text editor without extra programming, and I'm quite pleased with myself for this.

However, being a novice at programming comes with two major pitfalls. One of these is debugging, which I am not good at. I spent a whole afternoon searching the wrong function for a mistake which stopped it working (the REAL mistake was that another function immediately over-rode that one in the same frame, causing no visible results and no error messages). I'm sure every programmer has frustrating moments like this, but it's something I need to get used to. The other problem is code organisation. My project is a mess of scripts and functions jammed in wherever they're most likely to work. I'm commenting and rearranging as best as I can, but I think an actual good game developer would take one look at my code and scream and scream and scream.

I think my biggest takeaway here is that programming is a skill which I'm still learning. I know a lot of basic programming theory from all the different tutorials I've taken, but those are tutorials at the end of the day. I can learn how to play Fur Elise perfectly on the piano, but that's not the same as learning to play the piano. Similarly, I haven't actually learned how to code yet, but I'm getting there. I still need to learn strategies for debugging and code organisation, but I will get better at this. I hope.


Working as an individual

In this game jam, I worked solo. This is because I want to pick up on a lot of different skills as a game developer, and taking on a few different roles proved to be quite fun. I enjoyed being able to work on art or music as a break from programming. I guess the problem here is that my art isn't really very good, though many of you seemed to like it (and thank you for saying so!) - I worry that the full project may get to a stage where I would be better off hiring an artist for characters and backgrounds especially, but I'll cross that bridge if I come to it.

I also enjoy having complete creative control over my idea, at least for now. That sounds like kind of a jerk thing to say, and I want to stress that I'm not opposed to working in a team (there are some really good submissions in this jam by teams!) - it's just that if anyone is going to ruin my game, I'd prefer it to be me.

I think the big problem with working as an individual is that even a small scale game can feel overwhelming if you're doing everything yourself. I definitely didn't expect to get as far as I did in this jam. I really liked having this jam as an unofficial support network, and I found your compliments really motivating. Thank you all so much.


What next?

I plan to keep trying to develop Puzzle Wizard. I want to finish developing the prototype as outlined in the original post (minus the elements idea, which I now think won't read well with the differently-textured blocks) , and maybe take the extra time to spruce it up a bit before publishing.


Battle system

My big idea for the puzzle system is still to have enemies attack with miniature logic puzzles, which would be randomly generated. This is a huge challenge to me right now - it's going to mean coding a variety of logic puzzles, coding a generator for each of these which will always return a solvable puzzle, and being able to generate these on demand in the middle of the battle system. This idea could also be bad from a design perspective, as when you have a variety of puzzles to do, there's always going to be a few types you hate, and having to fight, say, 20 bats with 20 Kakuro puzzles will be torture for some. I hope I figure it out as I go along. Before that, I want to be sure I can actually code the thing first.


Dungeons

As for the game outside of the battle system, I have two big ideas to choose between for my dungeons/field screens.  The idea I'm favouring is to make dungeons in the style of the Professor Layton games: a little web of single-screen environments with hotspots you click on to find puzzles and monsters you click on to battle (there'd be no random encounters). Puzzles would be larger-scale logic puzzles and pictoral puzzles (like spot-the-differences and mazes); simpler puzzles would bar progress through the dungeons, and more complex puzzles would lead to items and bonuses (so that the player doesn't have to, e.g., spend two hours on one Killer Sudoku just to get a step closer to the endgame).This is easy to code, I think, and makes the puzzles the focus of the game. But since there wouldn't be much gameplay in the dungeons themselves, the art and writing might need to be very good to compensate.

On the other hand, I could make top-down dungeons in the style of Earthbound or any other SNES RPG. If I do it this way, I think I would actually crib from the Deadly Rooms of Death series  of puzzle dungeon crawlers. What I love about DROD is how it brings all sorts of elements of dungeon crawling into its puzzles - you usually have to manipulate the monster movement to solve puzzles, e.g. baiting a monster towards you so that it blocks the path of another monster trying to escape. I'd love to do something like that, but this is another level of complexity on top of what's already quite a big coding project, and I also think switching between keyboard-controlled dungeons and mouse-controlled battles would be a pain.


Story

I haven't discussed story at all in this devlog, because I haven't worked it out to a degree that I'm happy with yet. The basic concept (at the time of writing) is that the player character will take part in a series of wizard duels with a ranking system, cribbed from No More Heroes - dungeons and the puzzles within them are designed by the bosses of those dungeons, the wizards themselves. This offers great opportunities for characterisation and humour, by placing something of each wizard's personality and history in their puzzles and their possessions. (This aspect is wholly inspired by Undertale, in which boss characters inform their sections of the game to fantastic effect, e.g. building a friendship with Papyrus before facing him, or learning about the anxieties and fears of monsters before facing their champion Undyne). I'd like the wizards to be inspired by high-fantasy archetypes, like Gandalf-type wizards, necromancers, etc., but I'll happily throw this out for a really good boss idea. 


Executive summary

Gamedev is fun, coding is hard, thank you for supporting me, I hope I do the gamedev well!

your sentiment of "I can learn how to play Fur Elise perfectly on the piano, but that's not the same as learning to play the piano." Is entirely how I feel about programming and it's something I haven't ever been able to put that into words. It's interesting to read through how you want to expand the game because both paths entirely interest me.

I can totally understand your stress and satisfactions of being a solo developer and it really makes me want to try and make my own game all on it's own.

Anyways this was a really interesting read, thanks for writing it! I'm totally excited to see how it ends up!