Developer Diary #2: The Proof is in the Pixels
Last May, I embarked on a journey. I wanted to make a game! With no development or programming experience, I rolled up my sleeves and got to work. I downloaded GB Studio and joined a Reddit group. In my notebook, a premise for a story blossomed. Paper doodles soon became pixels. I stole time on weekends to tinker and test, dropping art assets into the development environment. It was a fun, wild, messy ride.
The ride isn’t over, but it has slowed down. Near December, I realized that I was trying to do everything all at once: learn to develop, implement gameplay ideas, and make artwork. The hard truth is that one must learn to walk before one learns to run. For my part, I was trying to leap over tall buildings in a single bound.
But enough editorializing! This is a diary. Onward to the entries.
A matter of scale
So. The Game Boy has a resolution of 160 pixels wide by 144 pixels tall. This means the presence or absence of a single pixel can make a big difference. Initially, I drew the kitchen in Mollie’s house without any reference for scale. When I dropped Mollie onto the background, she was the same size as the refrigerator. Oops. Furthermore, she could traverse the whole kitchen in two steps.
So, back to the literal drawing board. I decided to base everything on Mollie’s sprite size, which occupies a 16 x 16 grid. This removed some of the guesswork and allowed me to gauge how much detail I could achieve. For instance, picture frames will be empty because there are too few pixels to draw anything recognizable. But what if the player inspects them? Then I could cut to a “closeup” view of the picture, revealing clues or something quirky.
The bulk of my work has been drawing the house interior. Honestly, I’ve spent way too much time on it. The trouble is that I’m a graphic designer first and an artist… third? Fourth? I don’t know. My talent lies in the arrangement of text and images rather than making them. It seems that I’ve erased almost almost as much as I’ve drawn. And it’s still not done!
A few questions I’ve been asking: should rooms fit on one screen or span multiple screens? How about closets or bathrooms? Should buildings be smaller on the outside and bigger on the inside? Do I want to animate doors opening and closing?
Where does this indecision come from? Perhaps it’s the lure of infinite possibilities. I’m reminded of painter Bob Ross and his “bravery” tests. He would paint a stark vertical line through his lovely landscapes, seemingly destroying them. But then he would transform that line into a glorious tree that helped frame the foreground elements. My work could benefit from his bravery.
A matter of perspective
Lately I’ve been stumped about what to show and what to hide. Observe the bathroom. Do you see that roll of toilet paper? Great. How about the toilet? Excellent. The countertop should be visible, too. The mirror is a nice touch, no?
This is all well and good. But does it ruin things? By allowing the player to see into adjacent rooms, does that ruin the mystery? For instance, in the upstairs portion, Dad is watching TV. The player starts in Mollie’s room but can clearly see Dad nearby. This creates incentive to go and talk to him, but it may spoil the fun of discovering what’s behind a locked door.
You may have noticed that all of the doors face the player. This is because I haven’t figured out how to draw them sideways. It should be easy, right? Well, according to my Mollie scale, doorways should be a third taller than the surrounding characters. However, when said doors are viewed sideways, they look way too tall.
Walls present their own challenge. Some 2D games choose to ignore walls, such as Final Fantasy Tactics. Other games show walls in a top-down style like Link’s Awakening. I’ve decided to show all of the north-facing walls straight on. West and east-facing walls are represented as narrow vertical lines. This is largely how Pokémon does it.
Southern walls are a bit of a head-scratcher. If Mollie tries to enter Mom’s room from above, she will appear to be standing on top the door before it opens. Realistically, she should be partially obscured by it. Alas, GB Studio doesn’t allow sprites to pass behind objects. My plan is to avoid putting anything important along the southern-most walls except for doorways.
A feasible demonstration
Art woes aside, I’m pleased with my work on the story. It’s plenty weird. Sadly, my fledgling skills as a developer are insufficient. Thus, I’m hitting the pause button on story development before I bury myself. What I’d like to do instead is create a small game that can serve as a demo.
I’m calling the demo “The Tallest Tree.”
Making a demo will allow me to craft only the elements that are strictly necessary. Plus, I can share the demo with other people and get their feedback. This will be a feasibility test for my skills and determination. Most importantly, it will help me understand what’s working (or not working) in terms of gameplay.
Tentatively, here’s the scope of the demo:
- One main objective: cut down a Christmas tree
- One music track
- Three items (hat, axe, rope)
- Three scenes: The main area, the big tree, Viktor’s shack
- Four supporting characters: George (lost boy), Tom (lost boy’s dad), Viktor (groundskeeper), and a talking snowman
- Between 5 and 10 minutes to complete
Insights in the new year
In January, Erica and I traveled to the west side to celebrate her birthday. While visiting my folks, I showed the incomplete demo to my nephew Gideon. He enjoyed it and asked to play-test the final version. My sister Sarah also took notice! It was pretty amazing as my family gathered around my laptop, watching the pixelated Mollie interact with a snowman.
Although the demo is not finished, I’ve already learned a few things by observing how Gideon and my sister played it. First off, this style of game is largely self-explanatory. Gideon has played enough games that he didn’t struggle with how to use the controls. Sarah didn’t have any trouble either.
Anyone who has seen a Mario game understands how movement works. They’re also familiar with using at least one button: the A button, or the “jump” button. Less obvious is the ability to run faster by pressing and holding B. I used to marvel at how my cousin Nicole could make Mario jump so high before she told me the secret. So far, my demo only uses cardinal directions and one button for interactions.
I would like to include an inventory screen. Its purpose would be to show the player everything Mollie has picked up. In the demo, she’ll only have three items, so an inventory screen is probably overkill. Another thought is that players could use the inventory screen to select one of the items if they wanted to use it. The item would appear in the character’s hands or possibly in an item box overlaid on the main screen.
To have or to hold? That’s another inventory-related question. In Link’s Awakening, characters would say different things to Link if he possessed a particular item. It wasn’t always necessary to equip said item first. The player didn’t need to think about what was contained in the inventory screen. Is less thinking a good thing? I’m not sure.
As a fan of the Monkey Island point-n-click adventures, I have fond memories of using every inventory item available to elicit reactions from non-player characters (NPCs). It was almost a gameplay mechanic in itself. Sometimes though it felt like guesswork. Is it more enjoyable to equip an item and try it out or to have the game automatically know what you’ve got?
I’ll test all of these ideas in the demo. Perhaps there’s a middle ground. Items necessary to the story could be recognized automatically, ensuring that events move forward. Less critical items could then be equipped manually, like a magnifying glass, that would allow a player to inspect details of the environment. Said details might enrich the experience and offer clues to solving a puzzle.
Personally, I like finding secrets in games. In Mario games especially, I’ll hunt down every coin. This annoyed my brother endlessly when we played New Super Marios Bros. Similarly, it annoys my nephew Gideon, who would rather speed-run a level. My hope is that the demo is something anyone can enjoy regardless of play styles. As a slow-poke, I want to reward players for uncovering every stone.
Wrapping up
Currently, I am focusing solely on the game demo rather than the main game. The demo is not related to the main game except that it uses Mollie’s sprite. She’ll be called Donna, and I intend to swap out her sprite later. The scene is supposed to be wintertime, after all. Her clothes don’t fit the season.
In a few short months, baby number two is scheduled to arrive! Erica, Olivia and I are deeply excited. What little time I have to work on the demo will evaporate when Jack Henry enters our lives. That’s OK. I don’t expect the main game to be done anytime soon. However, I do intend for the demo to be finished by the end of July. Fingers crossed!
