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.
2 Likes
Feels
I was so down and tired yesterday that I felt apocalyptic about this game and the unwieldy task set out for @trotopype and I.
Today I feel a lot better. I know this isn't a diary, but like, isn't it?
Menu Updates
I have been working on placing doors in the level editor. It's kind of working, and entailed writing a lot more Menu class code to make menus with tons of options appear correctly and scroll. I have avoided using the SDK's grid class. I used it in the previous implementation of this game, and I remember it working rather well actually. But, so far at least, what I'm trying to accomplish is much simpler than what the grid class can do. So I'm just hand-rolling what I can where I can.
In this video you can see the menu scrolling i'm talking about. I intend to add in a "holding down" the navigation button causes auto-scroll. Currently tho, in addition to the up and down buttons, you can use the crank which can be quite fast at scrolling through long lists. I think the longest list in the game that will be scrolled with be the rooms in the editor, which most players will never see anyway.
Door Placement (In-Editor)
You can also see a Door being placed. I have collision rectangles highlighted because some doors are invisible. This should be familiar to most gamers. Sometimes you walk into a path or something on the edge of a map and get transported to the next area.
I place a door and then using a context menu (pressing B in the editor opens a context menu based on the tile the cursor is currently selecting) I select the destination. Then in the destination room I am selecting the 'destination tile' for the player to appear on when they use this door and go to that room. That does not work yet, I'm like halfway through coding that.
PS - our composer sent me this little diddy (in the video) this morning and it's got me very excited for continuing work on the music in the game.
1 Like
Tiled Walls vs Simple Collisions
Old way: Player moves and collides with walls to stop. Can be left between tiles. Relies on SDK collisions.
New way: Player requests to move to an adjacent tile, the tile is checked for properties such as "occupied" and if not then the player is granted permission to move. This upholds puzzle logic, such as not letting the player walk or teleport into occupied tiles.
The Editor Lives!
I'm going through existing levels and replacing the old walls with the new version of walls. The editor spits out JSON that I just replace the original source version of the room with. It's working!
Life Update
I'm getting married in August so I will likely slow down production, and pick back up in September.
It makes me nervous to put this in writing, but I'd like to release the game early 2025. I think that's doable, with some long coding days over this winter.
1 Like