scavenger suite title image

Today I’m going to introduce you to Scavenger Suite, the game I’m building with Bitsy. This is my first devlog, if you can call it that (it feels wrong to call myself a game developer at this stage in my learning process, but that is nevertheless what I’m doing).

If you’re not familiar with Bitsy, it’s a free online game editor for making small 1-bit style games. I highly recommend trying it out for yourself.

photo of power lines against a winter sky

Photos I took in the wintertime inspire the color pallettes and imagery in the game.

top down

I was inspired to make Scavenger Suite while taking walks with my dog, on early mornings when the neighborhood was quiet. At the time, I just had a vague idea for a game where you can wander a deserted town and explore abandoned buildings. I enjoy the exploration areas in post-apocalyptic games like The Last Of Us, and I wanted to make a small-scale version of an exploration game with a melancholic atmosphere.

I wrote down a page of notes that I added to whenever I thought of something new. Initially, I thought the story would involve ghosts that you could interact with, and flashbacks where you could see glimpses of the town in its former glory. The idea for a dog companion didn’t occur to me until later, and this steered the story in a different direction. But the first two ideas that I wrote down remained core to the game:

The “top-down map” idea was one of the first things I tested out in Bitsy. I wanted the player to be able to move seamlessly between a zoomed-in, side-scroller type view and a zoomed-out, top-down view of the larger area.

test sequence of player moving between top-down and side-scroller views

Interacting with the house sprite in the map view will take you to a "zoomed in" side view of the characters.

My game making process generally starts like this:

  1. make it work
  2. make it pretty

The artistic limitations of Bitsy are helpful for learning to make a game. It forces me to focus more on the “make it work” part before spending too much time on the visuals. In these early tests, I focused on getting the basic gameplay mechanics to work how I wanted them. In addition to the top-down map areas, the other important feature of gameplay is being able to switch between characters to enter a room or solve a puzzle.

test sequence of player moving between controlling human and dog characters

Interacting with the dog sprite switches the player’s control to the dog. (The dog is walking backwards, but I can fix that later.)

With these two basic mechanics in place, I could begin building a scene around them (making it pretty). Then I could refine details like changing the direction of the avatar when appropriate, adding dialogue and creating environmental obstacles for the player to overcome.

scene of human talking to dog, then dog exploring house

open world

One of my goals with Scavenger Suite is to try to say as much as I can with as few words as possible. I want the player to feel like they are guiding the story with the actions they take. This is a bit of an illusion, because there is a linear story being told. But it’s important to me for the game world to feel big and open: a place where the player can wander and explore with the characters, rather than being led through a tunnel.

In order to do this, I have to design the world meticulously. Using Bitsy, which is extremely beginner-friendly, allows me to practice working and thinking in terms of programming without having to learn all the code first. If I want the top-down map to have several entrances to more detailed areas, and those areas change depending on whether you’ve visited them already or picked up a certain item, I have to make that work. My notebook is filled with to-do lists and possible if/then/else branches. I like this problem-solving aspect of game creation. It’s tedious but fun. It also gives me a better perspective of how much effort it takes to make one simple thing work in a game.

top down map view of a rural area with a river winding through

Top-down map view of the river section of the game.

The "river" section of the game took me a long time to design. It is the largest and most open region so far. I wanted to ensure that the player could explore the main landmarks in any order they choose, which meant I had to hone in on the next steps in my process:

  1. make it work
  2. make it pretty
  3. make it make sense
  4. test everything over and over again

I want the player to have some freedom in choosing where they want to go. In the context of the story, this means that every possible choice has to make sense as something the characters would choose to do for themselves. I try to achieve this primarily with dialogue. (In Bitsy, "dialog" means any chain of events that is triggered upon interacting with an object or sprite, but in this case I'm referring to the narrative text that appears for the player to read.) Scavenger Suite doesn't have an outside narrator, only words spoken by the characters. The spoken text serves as a series of hints for solving puzzles, but it also gives context for why the characters are doing what they're doing. My hope is that I've provided enough clues for a player to move through the game at a steady pace, without giving so much away that it becomes boring. I won't know if I've succeeded until someone actually plays the game, but I can test it for myself to make sure the dialogue flows smoothly and appears where I want it to appear.

traveler talks to dog at the riverside

A dialog box with narrative text is prompted when the player walks up to the dog sprite.

The hardest part of designing this area was making sure that the player can solve all the puzzles in any order without breaking the game. The puzzles aren't complex or numerous--basically you may encounter a task to complete in one area, which requires you to find an object in another area. For design purposes, this means that a given sprite will interact differently with the player depending on which areas they've visited or items they've picked up. Some of the sprites' branching dialog (this time I'm referring to the Bitsy definition of "dialog") end up looking pretty confusing.

click to see an example of how the "mailbox" sprite functions on the map.
  • if food = 1, then:
    • if rocks >= 1, then:
      • move player to farmhouse (repaired chimney)
    • else if farmhouse key = 0, then:
      • move player to mailbox
    • else: dialog: player needs rocks
  • else if shelf key = 1, then:
    • dialog: player needs food
  • else if farmhouse key = 1, then:
    • dialog: player needs rocks
  • else: move player to mailbox>

The reason why it ends up looking like this is that I often use items as invisible keys or triggers. For example, the player receives an invisible "farmhouse key" after visiting the farmhouse. Now I can change how the character interacts with other sprites or objects based on whether or not they have the farmhouse key. There is probably a simpler way to do a lot of this in Bitsy, but I still haven't figured out how to use variables, and this way makes sense to me. If it works it works, right?

I'm not the kind of person who can plan everything out before building it. I learn a lot about the story and characters as I put the world together, and I learn what will or won't work with the gameplay as I test it over and over again. Fun fact: I had to fix two big errors that I missed while writing this blog.

Now that I've tested the river region in as many ways as I can think, I'm ready to let other people test it out! I think it makes a good standalone demo to give you a sense of what the rest of the game will be like. You can play it right here!