Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles

Devlog: Puzzle Wizard - prototype for a puzzle RPG

A topic by rabbit created Jan 05, 2018 Views: 514 Replies: 26
Viewing posts 1 to 18
(+1)

Hi! Thanks for checking out my devlog!

For my first game jam, I want to make a prototype of a puzzle RPG that I've wanted to see for a long time. A lot of puzzle RPGs seem to mix match-3 gameplay with RPG elements - this is fine, but I want to try out a different battle system using blocks and tetrominoes instead, because I think there are some clever opportunities for quick-fire puzzle gameplay here that haven't been tapped. However, although I've taken a bunch of game dev tutorials, I've never been at home with coding, and have to take it slowly. So I'm probably not going to manage a full game here - sorry! But I hope to have some kind of prototype that you can play with ready to show off by the end of this jam.

Concept:
Puzzle Wizard is a puzzle RPG with a turn-based battle system in which the player solve puzzles quickly to cast and deflect magical attacks. This prototype focuses on how the player attacks. Each enemy or boss has a shape built out of squares, which the player must match as closely as possible using a random set of tetrominoes. (You see this kind of shape-fitting puzzle done a lot in mobile puzzle games.) The more accurately the player matches the shape, the more damage they deal that turn to the opponent - an exact match is a critical hit, but this might not always be possible depending on what tetrominoes the player gets. A time limit for each turn adds pressure. Each individual block of the tetrominoes might also have its own special elemental properties, so that if the player manages to get a few of the same element in a cluster or row, extra damage or status effects are dealt to the opponent.

The above is what I'd like to get finished in this jam. The big picture is that enemies and bosses would attack with miniature puzzles that the player would have to solve quickly to avoid damage, like tiny Sudokus or something, and dungeons would probably be screens with bigger puzzles buried in them, like Professor Layton... but I'll cross those bridges if I ever come to them.

Platform:
Puzzle Wizard is being developed in GameMaker Studio v 1.4. This is the system I'm most comfortable in, but I haven't published any games in it before outside of tutorials, and although I know some basic programming theory, I'm far from fluent in GameMaker Language, so I'm learning as I go along. For now, I'm developing the game for Windows systems, though I *think* I can change to HTML5 or something else without causing any problems? We'll see.

Goals:
The main goal is to get better at coding, so that even if this game doesn't work out, I'll be more comfortable with future projects.

In terms of the game itself, I want to program the simple attacking system I outline above. I'm working towards the following checkpoints:

  1. Generate tetrominoes that can be moved and rotated by the player, but which snap to a grid when placed.
  2. Define shapes which the player must attempt to match with the tetrominoes.
  3. Compare the placed tetrominoes with the larger shapes and return data based on this comparison (from which attack strength could be calculated).
  4. Add elemental properties to blocks (visually represented by different shapes and colours drawn over each block).
  5. Expand step 3 so that it registers elemental clusters as well.

That seems doable in 2 weeks, though I don't know how I'm going to do it yet. Once I've done this or as close as I can get, I'll either try to build a turn-based RPG structure around the prototype or just polish it off into a standalone game, depending on how much time I have left.


Sorry that this post is a bit long, but thanks for readings! Let me know if you're curious about anything.

Update 01:
Here's what I've done so far. This took me a couple of hours to figure out:

puzzle wizard 01

Simple tetromino randomiser
Each tetromino is an object which places a couple of blocks, chooses an integer from 0-6 to represent which of the seven types of tetromino it will be, and uses a switch statement to place the other two blocks. Each tetromino stores its component blocks in an array; I'm hoping this will help me move and rotate each set of blocks as one unit when I try to code that. Each block also has a variable for what tetromino it belongs to which the tetromino fills with itself - that's just in case the array doesn't work for everything. (The refresh button just restarts the room.)

I already feel like I could be coding this in a much smarter way, but that's just part of learning how to program!

Submitted(+1)

Sounds quite interesting! I was also recently thinking how all these puzzle-RPGs are the same match-3 formula and hoping for something different. Look forward to playing it!

Kind of reminds me of this Sim City / Tetris hybrid. Not sure if this is the exact one I'm thinking but "City Rain" is one example. Might give you some ideas if you haven't already played it: http://www.ovologames.com/cityrain/index.php

Oh neat, I've never heard of City Rain! And now that you mention it, I think there was another city building game I played a while ago where you had to place clusters of buildings, but I can't remember what it was called and all I can find on Google are children's toys.

Thank you for the kind comment :)

(+1)

Update 02: Making movable blocks

Just spent an hour trying to code how the tetrominoes move. The idea is that you click on a tetromino to pick it up and put it down. I have a simple state machine for each tetromino that, when it's in the "move" state, updates the position of its component blocks to its new relative position to the mouse.

Anyway, just finished my first pass at the code. Let's see how I did!

puzzle wizard 02

first attempt at movable blocks

ah,

(+1)

Puzzle battles! It reminds me really distantly of Skyward Sword's dungeon key system- you had to rotate a 3d piece to the right position to open the boss areas. This sounds like a pumped up version of that, so cool :D

Submitted(+1)

The idea of attacks being puzzles is really interesting! Don't worry if your game is just a prototype; my turn-based RPG from Winter 2017 had very little content, and I was doing that in GM, too. As long as you post something by the end, you've completed the jam, and you can always go back and add more content afterwards.

(+1)

Thanks for the nice comments :)

Update 03
So I haven't had that much time to work on the game jam this weekend, but I realised what I was doing wrong. I forgot that GameMaker distinguishes between objects and specific instances of those objects. My tetrominoes are supposed to be arrays of four blocks each, but instead they were arrays of the concept of "block" four times. So instead of moving a tetromino, the above gif collapses all the blocks into the first instance of "block" it can find and moves that around.

I managed to fix it, and now it works better:

puzzle wizard 03

moving tetrominoes (not broken edition)

Still a lot of things I haven't coded yet - you can stack the blocks on top of each other, you can pick a block up in the same step that you put one down, blocks still need to snap to a grid - but I'm happy so far. Luckily, GameMaker just put out a tutorial for only clicking on the topmost instance in a stack of objects, which I hope will help!

Submitted

Once blocks snap to a grid, I can already see myself obsessively playing this just lining everything up into perfect squares. 

Update 04

Good day today!

puzzle wizard 4a

grid snapping implemented
  • Tetrominoes have different colours now, so that they're a bit more readable as you place them together. I'm going to add different designs to the blocks as well to make this game more colourblind-friendly, but I'm sticking with the triangle/arrowhead design for now because they'll help me keep track of how well my code is working when I have to rotate the blocks.
  • I've made the background dark so that the blocks show up better, and I made the checkerboard design a bit nicer too.
  • The tetrominoes now snap to the grid. I'm proud of myself for getting this to work on my first try. The code needs extending before the jam is over, though - you can see it's not quite complete at the end of the GIF above where I place the red I-block in the corner so that it snaps outside of the game window. I need to check that block placements don't go outside the play area or overlap with other bricks.
  • That mouse click tutorial I mentioned before taught me how to use "begin step" events. Now the mouse can only click on one block per step (which shouldn't be a problem since the game should run at 60fps, despite the GIF framerate), and I'm going to extend this to other objects so that the player can't, say, put a tetromino over an important button and then accidentally click the button while trying to pick it up again.
  • The tetromino the player is carrying is brought in front of every other object, and sent back to its original depth when the player puts it down. For some reason its sprite gets sent to the back when it's placed on top of another block (I think it's to do with how GameMaker draws overlapping sprites at the same depth), but if blocks can't overlap in the final prototype that shouldn't be a problem.
  • That white grid is the beginning of the target shape which the player needs to match. It doesn't do anything yet, I was just testing how the sprites look. (I think I'll make the white more transparent, to show the checkerboard grid background a bit better.)
  • This is a small thing, but I've implemented a global variable for how big the grid is, because if I don't, at some point down the road I'm going to have to change the grid size from 32 pixels to 16 or something, and it's going to be awful going through all the code updating it.
  • I've begun making a few extra assets for the game. I've made a few sounds in SFXR, and I doodled a couple of enemy sprites which I might display in a corner of the play area.
  • Finally, since the code is becoming spaghetti, I've organised the project in GameMaker and started commenting the code as thoroughly as I can, especially where one script relies on code in a different object.

puzzle wizard 04b

enemy 1 of 2: a scary bat!!

So the next few coding goals are to figure out shape rotation, to make the grid snapping code more intelligent, and to start generating target shapes, maybe implemented as different enemy types.

The gameplay is starting to take shape, so I'll also need to figure out how it's going to be laid out: where the tray of tetrominoes will be, where the target will be, and where I can put HUD information. In terms of game design, I was considering making this prototype into a score-attack puzzle game for the purposes of this jam, but that depends on what state the code is in a few days from now.

Just as one small gameplay note, as I play with the shapes in testing, one surprising thing is how annoying I-block tetrominoes are! They're your friends in Tetris, but here, working with small target shapes, they're very inflexible, and you have to plan around them. It'll be better once you can rotate them, but not much better. I wonder if I should tweak the randomisation so that I-blocks appear slightly less often than the others? That's something to think about once I have a game to test.


puzzle wizard 04c

enemy 2 of 2: a spooky ghost!!
Deleted post
(+1)

2 spooky 4 scary

As far as randomization goes, Tetris The Grand Master has a system that strikes a nice balance between unpredictability and usefulness, so you might find its algorithm useful.

Oh, thanks, this is interesting reading! I had a look around other Tetris systems on that wiki, and I also like the bag system here - that might be useful way down the line if I ever get this off the ground as a full puzzle RPG and want to put in status effects that give the player less of a piece.

Update 05

I wrote a very simple rotation system today, which doesn't actually rotate anything - all the block sprites remain at the same angle, but the component blocks of the tetromino are rearranged around whichever block you click. I've done it this way because a) if the block sprites are going to have shapes on them  so that colourblind people can read them better, they ought to look consistent no matter how the tetromino is rotated; b) I'm using the top-left corner of each sprite to align it to the grid, which is more intuitive to me than using the center, and rotating the sprite might mess with this; and c) doing it properly with vectors sounds like hard work.

Unfortunately, this simple system didn't work at first, so most of my effort today has gone into troubleshooting about seven lines of code for two hours. It always turns out to be some silly mistake I forgot when I have trouble with coding. As it turns out, my rotation code works perfectly (as far as I know), but it was being overruled instantly by the code which keeps blocks together while the mouse is carrying them around.

So here's what Puzzle Wizard looks like now:


As you can see, I'm thinking about how the game is going to be laid out now. I'm not happy with this yet, but I like the target shape being right in the centre. (I think each enemy type will have its own unique shape, though I probably won't get to make many enemy types before time is up.) Please excuse the placeholder boxes, they look much uglier than I expected.

(I've also made the target shape slightly larger than the grid - I think that little white border around a full target shape looks really good.)

Host

ohhhh this is a really neat premise! great work on scoping this game and really hashing out your mechanics so far :Oc !! it's honestly so cool to read about your progress in this devlog over the past few days. the visual direction you've taken is also very easy to read--kudos to that!

Thank you! I'm glad to see you say that - one of the big reasons I'm trying to do frequent devlogs is to prove to myself that you can make a big project bit by bit even when you have no idea where to start. I'm very happy with how it's shaped up over the last week :)

(+1)

Update 06

I took the day off yesterday to avoid burning out, after struggling so much with programming the day before. Today, I decided it was time to take on one of the jobs I've been dreading: coding the actual turn-based battle system.

I have no idea how this is supposed to be done, so the first thing I did was sketch out a highly professional state machine draft on the nearest envelope.



And here's what I've managed to do so far:



The battle screen is fed whatever enemy type the player has encountered (just the bat for now) and harvests variables from it and the player's statistics. The player gets a menu, and goes to the state for whatever action they choose - just the attack option for now. I haven't built anything for processing player attacks yet, so that's as far as they can get. I won't go into all the details because the code is kind of a mess. Half of the states I've "implemented" don't actually do anything, because everything they need to do can be done directly in events run by the battle controller and menu buttons.

I quite like the idea of making the menu bar the attack timer - it just looks neat to me.

Also, it's not GIF compression or anything, the font really does look that bad. I'll have to tweak that.


Here's what the enemy variables look like for the bat:


I'm trying something a bit risky for building the target shapes for each enemy. I'm storing the shape as a 64-character string, which will be converted into an 8x8 grid by going through the string character-by-character. 0s are empty space, 1s will be one of the component squares of the shape. The advantages here are that it forms an easy visual way of building target shapes in code, and that I can implement extra types of target space square - for example, an X could be a square that must be avoided. The disadvantage is that I have absolutely no idea if this will work or not. Here's hoping!

Also, the bat's stats are just made up for now. I'll tweak those with playtesting, I expect.


One more big thing: I made a battle theme for the game! I'm very happy with how this sounds. This uses the free GenesiSF soundfont by The Eighth Bit.


Finally, I don't think he'll make it into the prototype, but here's a dragonman enemy I made:


Host

LOVING this big boy. i love the bat sprite a lot... i know it's overdone to say this but this sprite + the screen reminds me of earthbound. it's so cute and campy!

also huh i'm curious to see if your string as a target setup will work also--that is kind of interesting as a setup.

Thanks! I'm not shooting for the Earthbound style, but I think it's inevitable that it ends up in that sort of pixel art wheelhouse, which is fine by me. I'm obviously not an artist but doodling monsters in GameMaker is very soothing.

Update 07

Quick devlog tonight - it's beginning to come together!


The string setup works! I now have a simple way to make target shapes for each enemy. That lets me make fun shapes like this Pac-Man ghost shape for the ghost enemy. I think it's probably easily extendable? I hope it is!

Getting the game to count how much of the shape is filled was the hard part, and the code that does it is a total mess of if conditions which has to read object names rather than what type of object it is. It works, though!

Also I tried drawing a little window for the enemy to appear in, but the more I look at it, the less I like it. It doesn't gel with the rest of the game. Oh well.

Update 08

I took the day off yesterday, so I wanted to hit a big milestone for this update to make up for it. Today, I got damage calculations working.


The calculation takes a base attack stat and multiplies it by a number based on how much of the shape you filled and a number based on how much time you had left in that round. I forget exactly what I did because I kept fiddling with the maths until it felt okay, but you need to fill in most of the shape to do any worthwhile damage. If you fill in every shape but one, you get a x2 multiplier, and if you get an exact match, your damage output is boosted like crazy:


Other changes since last time:

  • There's a Defend button now. It doesn't do anything except skip the player's attack for now, but when I implement enemy attacks, it'll be useful. Mostly, the Defend button is there to help me build a command menu structure which can disappear and reappear.
  • The tetrominoes for this turn show up in the battle menu now. The idea is that if the player can remember what the enemy's target shape is (there's the game jam theme!!!), they can decide whether it's worth attacking or whether they'd be better off defending. It's not going to be balanced in this prototype - I'm pretty sure it'll always be better to attack than to defend - but it helps me pin down the gameplay loop of the battle system.
  • Enemies support multiple possible target shapes. You don't see it in the above GIF, but Dragonman has an alternate shape that's the mirror image of that one.
  • Blocks have different textures as well as colours. I don't know if they're the most colourblind-friendly or readable, though, and I'm not happy with some of them. They'll do.
  • That big red bar is the player's health bar, which might do something later.
  • Enemies are now front and centre, in proper Earthbound-like style. I'm very happy with how that placement looks, and the big black square behind the target shape makes the battle screen still readable. Plus, putting the sprite there supports extra-large sprites for bosses.
  • I found the option in GameMaker that makes large sprites look terrible and turned it off. Everything's a lot crisper now.

We're now in the last few days of the game jam, so it's time for me to think about finishing this off. There's a few odd glitches and imperfections I want to fix as well, though. Below, I've written a list of what I'd like to get done by Friday, in order of priority. This is just me thinking out loud, but I thought it might be nice to show the state of the project here:

HIGH PRIORITY (need these done before I submit):

  • Finish off the core battle loop: allow enemies to attack, implement player damage and time-up scenarios, allow victory and game over states
  • Put enemies in the title screen so that the player can choose what to fight (at least two to demonstrate the battle system)
  • Make a how-to-play / about / credits screen

MIDDLE PRIORITY (highly desirable):

  • Implement the music and sounds I made
  • Intelligent snapping: keep tetrominoes within the playing area, and stop them from overlapping
  • Better rotation and placing: the blocks lag just slightly behind the mouse so that when the player clicks to rotate or place, they might not click on the block, which could be frustrating when the player is against the clock

LOW PRIORITY (not really necessary but they'd be nice to do):

  • Some way for the enemies to show damage (a health bar would be easiest, but damage sprites like in Mystic Quest would be much more fun (also I forgot how wild it is that the tutorial monster of that game can score a critical hit and murder you))
  • More sounds
  • Better backgrounds
  • Particle effects for Maximum GameFeel
  • Maybe remember to remove the Refresh button before I publish


Sorry for all the text - thanks for keeping an eye on my devlog! Here's one more GIF of a secret bonus enemy I made a few days ago just to push the battle system:


(1 edit)

Oh man the concept of using tetrominoes to attack is genius -- the quick wit required to hit for a lot of damage seems super fun and I'm excited to see where this mechanic goes! I can see a lot of game elements being added, like blockout squares where you cant have a tetromino touching, things like that-- of course not before the jam since that's super soon: looking forward to playing it though!

also crocodile boy is my mascot

Thanks! I'm sorry I might not get a playable prototype going now because my computer just broke, but I'm glad you like the look of it! I'd love to extend the battle system with blockout squares like you suggest, or squares that can move.


(I have some vague idea that the Boy is going to be a boss battle when I start adding a story to the game...)

Aw man! Yeah funnily enough, my computer also succumbed to the updates yesterday too and i spent about three hours trying to figure out how to fix this weird color glitch that only affected one monitor ...??? who knows.. But I want you to know that I'm following your page right now because if your character design is any indication of your story sense then I so totally wanna see a version of this with story! (I realize now its a dragonboy not a crocodile boy -- my bad haha still love 'im tho) It's been super cool to see your process through this all too. I can definitely see a game in the thematic vein of earthbound or like beglitched which gets me so pumped regardless of what the story will actually become cause I can just tell it'll be good what with the characters you've made so far

aah thank you! Can't wait to get back to it!

(+1)

So there's been a small technical hitch: my computer seems to be broken. It looks like the mandatory Windows 10 updates finally claimed my laptop. I'm doing my best to fix it, but I don't think I'll be able to work on the game any more before the jam is up. Really sorry!

Still, at least I was forced to stop, rather than giving up myself. What I really wanted out of this jam was to get more comfortable with writing code and problem-solving. I think I managed that in  the last ten days. I'm very proud of what I've made so far and I regret that I may not get a chance to show it off properly (depending on how fast I can fix my laptop or buy a new one).

I backed up my work yesterday, so I haven't lost any progress. I'll keep working on Puzzle Wizard when I can. Thank you all for being such a supportive community! Hope I can get back to this before the jam closes!

Submitted(+1)

Ah man, sorry to hear about that. Luckily I still use Windows 7 😅 the game looks basically playable already, but hope you get the chance to polish it off soon! Regardless of whether you finish it during the game jam or after, I'll definitely be playing. 

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!