-
Mr. Sun’s Hatbox is Out Now!
-
GameDeveloper.com Road to IGF Interview
Who are you, and what was your role in developing Mr. Sun’s Hatbox?
I’m Kenny Sun, the solo developer behind Mr. Sun’s Hatbox. I worked on almost every part of the game on my own including design, programming, art, animation, sound design, and music.
What’s your background in making games?
I first started making games in high school and released a few flash games on Newgrounds. Then, in college, I took a few game design classes and made a couple of Game Maker games on my own. One of them, Circa Infinity, got some attention and helped me get a job in the industry as a programmer at Harmonix. I worked there for a few years while still making my own games on the weekends. Eventually, those projects made enough to cover my living expenses so I quit in 2018 to try making indie games full-time. I’ve been doing that ever since, aside from a year-long break when I had the chance to work as a programmer on Return to Monkey Island.
How did you come up with the concept for Mr. Sun’s Hatbox?
I initially came up with the idea for the game in 2015 after playing Metal Gear Solid V: The Phantom Pain. I really enjoyed the Fulton recovery system where you attach balloons to stunned enemies to lift them into the air and kidnap them. So, I stole that idea and combined it with elements from another favorite game of mine, Spelunky.
I started to prototype the game in 2016, but quickly abandoned it after realizing how huge of a project it’d be given my limited free time (I had a full-time job back then). I forgot about it for a while, but then on my birthday in 2019, my housemate suggested that I should take the day off from the project I’d been working on and start something new as a treat to myself, so I decided to take another stab at the idea. I’ve been working on it ever since.
What development tools were used to build your game?
I used Unity as the engine, FMOD for audio, Aseprite to make the pixel art, and Logic to make the music.
You describe the game as a ‘slapstick roguelite platformer’. What drew you to bring slapstick into such a stressful, tense genre?
I actually didn’t seek to make a funny game when I first started developing it. I’d only started leaning into the humor after I noticed a lot of slapstick moments during playtests. As I added more and more funny elements, the humor became the identity of the game.
Mr. Sun’s Hatbox features a ridiculous array of tools and hats for players to work with. What thoughts go into designing weapons around silliness, slapstick, and humor?
There were a few approaches I took to coming up with ideas for items:
- Steal ideas from other games and add a funny twist. For example, I stole the boomerang from Spelunky and made it so you can’t catch it when it returns to you, it’ll just knock you out.
- Start with a funny visual idea and try to determine how it would work mechanically. A lot of the animal hats started like this, like the frog or snake hat.
- Start with a mechanic and think of items that would plausibly fit it in a funny way. For example, I had the idea for a gun whose bullets would bounce around the level. Turning it into a ping pong paddle that shot bouncing ping pong balls elevated the idea into something funny.
- Lean into the kinetic aspect of the game. I noticed that a lot of the game’s funny moments came from characters being bounced around the screen, so I added an array of hats that would launch characters in different directions.
- Add items that have no in-game benefit. Some of my favorite items are things like the blindfold, which literally covers your vision if you put it on. Or the headphones that just play different music when you wear them. Even if there’s no point to using them, they create a funny moment of surprise the first time you encounter them.
- Get ideas from friends. Many of the game’s best ideas are from playtesters and pals.
What challenges do you face when you have so many silly effects your weapons and tools can cause?
Readability can be a challenge, especially when using low-resolution pixel art with my limited art skills. One way I addressed it was to show a text popup whenever you pick up an item that tells you what it is. Even with that, there are still moments that happen too quickly for someone new to the game to parse. I didn’t really do anything more to address that though. It’s kind of something that you just get used to as you play the game.
Can you tell us a bit about how you came up with the art style? What made the look of the game feel right for an experience focused on silliness?
Since I’m fairly inexperienced as a pixel artist, I don’t really have the skill level to define and execute a unique art style. A lot of what defined the style was actually the tutorials I watched to get better at pixel art. Pixel Pete’s tutorials were the basis on which the style for the items came from, while AdamCYounis’s tutorials helped me figure out how to make the background tiles and buildings.
What thoughts went into the design of the base, and how players can build/expand on it? What do you feel this added to the game?
The actual structure of the base was defined very early on, with it just being a simple 4×3 grid of rooms. I kind of went with the simplest idea and stuck with it because nobody complained about it. I guess one thing that did change is that, earlier on, you didn’t even have to place rooms; they’d automatically get built as you progressed in the game. Later on, I updated it so you had to manually pick where each room would go. There is no mechanical benefit to placing a room in any specific place, but it added a small bit of customizability to an otherwise invariable part of the game.
Did you work to infuse that same silliness into the rooms and what they do?
I don’t think I actually spent that much effort trying to make the base management side of things silly. There’s some dark humor in there; one of the rooms lets you brainwash enemies you capture into joining your side. And another room that lets you perform lab experiments on your units to extract and instill personality traits. But even then, I never went out of my way to make those bits funny, they were just the most straightforward way to translate those mechanics into something narratively feasible. I guess the only intentional humor in the base management side is the narrative bit. Why is this delivery company digging a huge base of operations under their client’s house? Poor Mr. Sun.
As a developer, how does it feel to work on a game focused on humor and making the player chuckle? Does it feel different in some ways compared to development of other games?
It’s nice because it’s easier to tell if you’ve done a good job by seeing if people laugh while they play. And it’s always satisfying when I’m testing out an item and laugh out loud at something unexpected happening. On the design side, there’s a lot less pressure to make the game feel balanced than a more self-serious game. But otherwise, it mostly feels the same as making any other type of game.
-
My Work on Return to Monkey Island
Return to Monkey Island came out today! I worked on it as a programmer from June 2021 to June 2022 to take a break from Mr. Sun’s Hatbox. It was a really cool opportunity! I learned a great deal from my time there and I worked with a lot of amazing people. Most of my work was in programming overarching gameplay systems, so I’ve had my hands on basically every corner of the game. Below is a list of everything I worked on, I’m keeping things very general so there aren’t any spoilers or specifics about what happens in the game.
Hint System
I wrote and implemented almost all of the hints in the game. The hints are all in a huge dialogue tree, which I wrote in the engine’s narrative scripting language, called Yack. They dynamically react to the player’s game state and try to determine the most relevant information to display. Yack is closely integrated with the engine’s gameplay scripting language, called Dinky, which made it very easy to access in-game variables related to the player’s progress.
Gamepad Code
I did most of the scripting for the gamepad controls. Every interface or interaction in the game that required different behavior between mouse and controller needed custom code. Player movement and object selection were a big part of it. Internally it was called Direct Drive, since it allows the player to control Guybrush directly with the left stick (as opposed to controlling a virtual mouse, which most mouse-based point & click adventure games seem to do).
Tutorials
I wrote and programmed all of the tutorial prompts in the game. Additionally, I did most of the programming work in the main tutorial area (internally called the Playground). You’ll probably skim or skip through these parts, oh well.
UI Programming
I wrote a lot of code for the game’s UI, particularly the options screen. There is no visual editor for the UI, it’s all generated and positioned manually in code.
Trivia Book
One of my first tasks on the project was to implement the Trivia Book, an in-game collectibles system. Throughout the game you’ll find Trivia Cards scattered around. If you pick them up, they’ll get added to a book in your inventory, where you can look at them and answer trivia questions about Monkey Island and Lucasfilm Games.
Remunging Art & Animation
A lot of my time working on the game was bringing in assets from the artists and animators into various areas of the game. The artists and animators did not have access to the engine or git repository, so any changes they made would have to go through a programmer to bring it into the game. The word “remunge” was thrown around a lot, which basically meant a programmer running a python script to convert PSD’s or animations into files that the engine could use. Then, we’d manually place each asset in-game through an editor interface.
Puzzle Programming
I programmed the last major chain of puzzles in the game. I also implemented a few of the Hard Mode variations of a few puzzles.
Cutscene Programming
I scripted most of the interstitial cutscenes in the second half of the game (cutscenes introduced with ‘Meanwhile…’ text).