I'm learning how to make art! In an effort to aid my singular artist with this massive task, my co-programmer @trotopype and I are learning Aseprite. It's really fun. I think we'll make a lot of cool art.
I'm having issues. To be expected as a noob.
https://www.reddit.com/r/gamedesign/s/4iR3NB2yop
this thread will influence my puzzle design decisions. i think no loner push and pull. only push.
i’m also working on clouds
My drawings were not displaying correctly - it was color mode in Aseprite. I still don't exactly know what it does, but it causes the images to look correct so I'll never forget it.
I'm kind of tired this morning so as a way to get back into development let me talk about recent updates to the game.
Player Movement Rework
The player walks around via the D-Pad. This used to consist of fairly simple moveWithCollisions(x,y) calls. This resulted in continuous motion. As we developed the puzzles and began to implement the rules in code, we quickly discovered that enforcing discrete tile-based rules on a continuous game state would be far too complicated and may not even feel good to the player. Imagine trying to line up with a mirror and being a few pixels off, that would get annoying. We needed something other than just reacting to collisions after the 'move' has been enacted.
Tile-based Movement
Solution: tile-based movements. The player should only move up, down, left, or right and never diagonal. The player must always end up centered on a tile. This is natural in sokoban games, but given that we're making more of an adventure game, this was not obvious to us at first.
The screen has an invisible grid of 20px by 20px squares, which we call tiles. Think: chess board (discrete) vs a marbles circle (continuous). The game is composed of 'rooms' with a static camera, as shown in posts above. Each room that contains a puzzle has a very strict set of rules we need to follow as designers to make our puzzle-logic enforceable.
A short list of rules for example:
- Everything must line up on tiles. And by this, I mean the border of then collision rectangle should be at least 1 pixel in from the tile boarder.
- The player or statues (push blocks) must never be allowed into an occupied tile.
- The player must be able to push a statue if the destination for the statue is unoccupied
These kinds of interactions are difficult if not impossible to implement purely using collisions. Partially because, by the time a collision occurs, we've got a problem. The simplest observation that illustrates this is the fundamental action: player pushes statue one tile.
Why It's Better
Janky Version
- player presses right D-pad button
- player begins movement
- player collides with statue, and freezes partway between tiles
- some functions run to try to now push the statue, then restart the player, then fix tile logic issues
New Version
- player presses right D-pad button
- game checks the state of the tile which the player is essentially requesting to go to
- if tile is clear, player goes to that tile
- if tile is a statue, we then do the same process for the statue, checking requested tiles before moving both the player and the statue in tandem
It became clear to me that this was superior because invalid moves simply do not begin. I don't have to chase the player around cleaning up tile-based issues.
Custom Level Editor
We needed an editor. I had a process that I'd developed years ago for generating JSON from Google Sheets, and that is how we've been building out levels. There are approximately 80 rooms so far and maybe 30 of them have puzzles. That's about as much as I can take of inputting every single entity into a spreadsheet to place them in the world. I have briefly looked into solutions such as LDTk and the like, but nothing took.
For personal reasons and for the purpose of allowing for level design contributions from others, we have begun hand-rolling our own level editor. A few things mattered to me about how we make it:
- It should be able to run entirely on the Playdate with no simulator functions needed
- It should allow for not just placing and removing entities, but editing their internal parameters too
- You should be able to drop the player in at any time on any tile to walk around and test the level
- Being able to set up doors such that you can connect this room to the existing game world is critical
- "Exporting" a room should be easy
There are more requirements but this is the flavor of thing I'm trying to make.
By making a level editor that runs on-device, we facilitate some cool things. I'd like to send the game out to testers and have them eventually contribute level ideas if they so choose. I don't know if/when/how we'll get access to the internet via the SDK, but we could have people create and post puzzles for others to download and try. The vanilla experience will be very thorough and is important to me that it happens unfettered, so maybe after game completion we unlock the editor for players or something.
Demo
I've talked enough. Here's a bit of the editor in action.
1 Like