WIP WednesdayWIP WednesdayWIP WednesdayAugust 9, 2023August 9, 2023August 9, 2023
This post is also available on my Patreon. Join up and get pixel art for your game!
Hey everyone, I’m here for another Work-In-Progress Wednesday!
Welcome to all the new patrons since last time! I hope you’re enjoying the artwork and finding a good spot for it in your games.
As I mentioned in my previous post, I’m doing Low Rez Jam this year! The only rule of the game jam is to make a game in a 64×64 resolution. I decided to make a sort of tower defense / RTS game, a first for me. I’ve been hard at work, and want to show off the progress!
Above is a screenshot from Monday. Placing walls is one of the main parts of my game idea, so that’s what I worked on first! …Well, first was getting the shell of the game running, and laying out the level, and adding camera movement, and adding cursor movement. But after that, it was time to build some walls!
Speaking of the camera and cursor movement, I decided pretty early on that I wanted to avoid using the mouse, which is typical of the tower defense / RTS genres. This is Low Rez Jam, so you’re probably not gonna be playing in fullscreen. Moving the mouse to the window edges to pan the camera would be tricky, and clicking stuff in the world always takes some effort to transform coordinates and whatever. So, I decided to have keyboard and controller support instead. On keyboard, WASD moves the camera, and the arrow keys move the cursor. You can also pan the camera by moving the cursor to the edge of the screen, and panning the camera also keeps the cursor in the screen. It’s actually pretty slick!
On controller, it’s pretty similar- Left stick moves the cursor, while right stick pans the camera. The D-pad also moves the cursor exactly 1 tile in any direction. I’m going to try and support both keyboard and controller for release, but we’ll see how much time I have.
The next thing I worked on was adding some state to the tiles. You can see up in the debug window where it now shows the tile type, HP, and whether or not the tile can be walked through.
As you might have noticed by now, all the walls are basically 1 tile thick, and extend upwards 1 tile. After playing around with placing walls, I quickly noticed that parallel walls adjacent to each other didn’t look good and didn’t auto-tile correctly. At this point I felt like I had two choices: Restrict wall placement so parallel walls can’t be adjacent to each other, or allow the placement, which would make the tileset more complicated.
Even though it would complicate the tileset and the auto-tiling algorithm (which I had to fully rewrite), I chose the latter. What’s interesting about this decision is the reasoning. The reason for this isn’t technical, it isn’t (fully) artistic, and it isn’t game design. It’s actually about player expectations!
If I give the player a cursor and allow them to place walls, but disallow wall placement in certain spots without any obvious reason why, it’s going to confuse the player. It’d very quickly make you ask “Wait, why can’t I place a wall here? What’s wrong with this thing?” …And that’s definitely something I’d like to avoid, because placing walls is such a core mechanic!
Finally, I added wall damage. I set up the tileset in such a way that I can just offset the tile ID by a fixed amount to get a different state of damage for the same wall piece.
I can’t wait to work on the actual game part of this game next, haha! I’ll try to be in touch this weekend with another WIP post. See you next time!
– Will