Hello, my name's Alex! I'm here to make a game and have a good time!
This is actually my second game jam, because I participated in the Winter 2018 My First Game Jam. But I didn't complete it because my computer broke. I'm hoping to use this jam to relearn my way around GameMaker Studio and to learn a few new tricks along the way.
I'm going to do this by making a puzzle game!
I want to make an old-fashioned puzzle adventure game, like DROD or Chip's Challenge or Adventures of Lolo. Games like this appeal to me because they're full of ideas and full of personality. I think the top-down character control of these games will be easy enough to program from past experience, and easy to build on and extend.
I'm calling my game Arcane for now. This will be an occult-themed turn-based puzzle adventure with a block-moving gimmick. The player controls a character with the keyboard, Chip's Challenge-style, but can rearrange certain blocks in the room with the mouse, to clear or block paths, weigh down switches, etc. I'd like each level to be an assemblage of individual puzzle rooms as in DROD, so that levels can be easily rearranged and puzzles can be swapped in or out, and so that the player can tackle puzzle in a non-linear order.
(People who were around for My First Game Jam Winter 2018 might remember me doing something similar last year. I made most of the battle system for a puzzle RPG I wanted to make, which also involved shuffling blocks around. I still want to make that, but I think the programming I've done needs to be redone from the ground up, since it's very patchwork, borderline unreadable, and impossible to extend without breaking everything else. This game is being coded from scratch using a different way of handling blocks - perhaps I'll learn something from this which I can bring into the puzzle RPG!)
Goals (in rough order of what I want to do)
This is the minimum I want to accomplish to make a functioning puzzle game:
- Get a character moving around a room and colliding with objects and walls
- Get a system of picking up and placing blocks and objects with the mouse working
- Get the character-moving and the block-moving working together (e.g. make sure that the player can't place blocks on their character)
- Add an objective for the player (I haven't decided what yet - collect things? Reach a goal tile?)
- Add a simple enemy type, whose AI is integrated into the turn-based system (probably nothing more complex than "is the player in Direction X? If so, move in Direction X")
- Add one or two other basic puzzle elements (e.g. floor tiles which blocks can't be placed on)
- Build some basic puzzles
- Make a nice HUD / menu
Once the basic game is functioning, if I have time, I can work on some bonus features:
- Make the player able to move from room to room
- Add some extra puzzle elements as I think of them
- Add some simple NPCs (nothing more than walls with dialogue, really)
- Make pretty tilesets and scenery objects
- Make some good tunes to listen to while the player solves puzzles
- (advanced) Get checkpoints working so that the player can save progress in a room and doesn't have to start over if they make a mistake
- (really advanced) Figure out how to save games! If this idea is good and I want to make a full game out of it, I want to know how to work with save data
First big decision is how big to make the game screen. I want to have a main window where the puzzle lives, and a sidebar to display game information and menu options. This suggests that a widescreen ratio would be best, so I'm working with a resolution of 640x360 (to be blown up to 1280x720 when you play, so that you're not squinting at the screen).
Normally you'd work with 32x32 sized tiles in Game Maker and other applications. Here, I'm working with 20x20 tiles. This allows me to fit more puzzle space onto the screen - my puzzle window is now 24x16 tiles, leaving space for a border and a sidebar. The small tile size lends itself to simple chunky pixel art, which is probably good for making the levels as readable as possible. You can't divide a 20x20 tile as neatly as 32x32, but because everything in this game is going to snap to a grid, that shouldn't be an issue.
With this decided, I made a little player character to control.
I want an occult theme for my game, so I made the PC a black cat for now. The sprite is 20x30, with a 20x20 hitbox, so that the top of the PC's head overlaps the tile above without colliding with it. I've done this because I think it looks neat.
Next step was to make the PC move. I've forgotten how to code in Game Maker, so the programming here is not so good, but here's where I ended up:
The game adds or removes 20 pixels to the PC's coordinates depending on what you press, so that she stays snapped to the grid. You can use WASD or the arrow keys here. (Something I need to think about is how to set up different control schemes or let users define their own controls, since I know that WASD doesn't work for every keyboard!)
Walls next. Wall obejcts are just big purple rectangles in the room editor .The game canels your control input if your move puts the PC on a wall. I tried using tilesets here, a skill which I've never tried in Game Maker without a tutorial; I made some simple wall sprites which I painted over the top of the actual walls.The game looked like this when I was done:
This looks surprisingly pretty, imo! The advantage of tilesets seems to be that you can add extra sprites and make your levels look fancy while keeping the number of objects to check for collisions with low. My main concern is that if I use a lot of tilesets at this early stage, it'll be more work rearranging levels when I need to test something. I ended up removing the tiles for now, to be put back when I've built the engine up more and can start thinking about puzzle design - you'll see the base purple walls in the next GIF.
The PC is functioning. Time for blocks.
In my last game jam project, I did a puzzle RPG battle system about moving tetrominoes to match a larger shape as closely as possible. Each tetromino was generated from individual blocks whose coordinates were stitched together into an array representing the entire tetromino. This allowed randomisation of tetrominoes, reduced the number of sprites and objects I had to code, and was good for the shape-matching system I created, but the code was dreadful to write and read. I commented it as well as I could, and I still don't know how it works now.
This game will require hand-crafted puzzles rather than randomisation. So this time around I'm going to make block shapes individually. This will mean a lot more sprite work, but the game engine isn't complex, so the code should be far neater. In fact, I can set up a basic block as a parent object, and all other blocks as children no matter what their shape is. It also allows me to expand the types of puzzle possible in this engine - for example, locks could be sprited as jigsaw pieces to make a picture.
I've started with a basic 1-tile block, which will carry the code that all other blocks inherit:
Most of the sprites in Arcane are flat saturated colours so far, so I think this greyscale gradient is an interesting contrast. Hopefully it'll be easy to spot in a busy puzzle room.
I coded a state machine for the block that tells it whether it's being picked up for stationary, and a state machine for the PC that tells her whether she can move or not. Clicking on a block picks it up, and disables the PC until the block is placed again. Thinking about it now, this probably should be one game-wide state machine rather than individual state machines talking to each other. But I worry if if I try to do everything in one state machine, I won't be able to disambiguate between blocks (that is, if I try to pick one block up, all of them end up moving).
Right now, all that happens is that a moving block sticks to the mouse until you click again to place it. The result looks like this:
It's clearly unfinished - the blocks don't snap to the grid and don't collide with anything. But it's a start!
There's another problem with this, actually. Clicking on a block seems unresponsive - it feels like it takes a quarter of a second to register (whereas moving the PC with the keyboard feels much quicker). Perhaps this is because the block is using precise collision checking, which checks the sprite exactly rather than using a hitbox. (This is an investment in later collision detection with more complex block shapes, where using a simple hitbox won't do the job right.) Or perhaps it's because the code for picking up blocks is a twelve-car pile-up of if conditions.
I think I might be the coding equivalent of those people in infomercials who throw bowls of popcorn all over the floor and turn to the camera like "there's GOT to be a better way!!!" Anyway, I'm worried about how slow it feels to pick up blocks, but once they've been picked up they move around responsively. And it's only a turn-based game, so it's not like any lag spikes are going to trip players up. But if it gets significantly slow, I'm going to have to rethink the engine a bit.
Anyway, that's where I'm at, 8 hours into the game jam! So far so good!