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:

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

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!

ah,

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

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.

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:

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!

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

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.)

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:

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:

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!

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.