Posted February 12, 2019 by Samantha E. Schaffer (~Rina)
#development #design #color #hacks #art #concept #implementation #bitsy #bts
Hi, I'm Samantha! I'm an American artist and software developer based in Adelaide, Australia, and sometimes I make games!
I decided to document some of the development process for this particular game: M.E.C.K. 415. I think the game is deceptively simple, but a lot of effort went into giving the game a specific look and feel, so I thought it might be useful to go through it!
This game was a joint effort between me and my partner Tom. Tom did the majority of the concept and narrative work, while I did the art and implementation. For this reason, the parts I worked on are the focus. If you want info about the other bits, badger him into writing his own devlog.~
I knew I wanted to make a game for the January bitsy jam, but I had absolutely no idea what to make. My games are generally fairly plot-light (purposefully, so I don't need to sweat the details), but I couldn't think of any way to do "mech" in my usual vague way. I was coming up short.
The day before the start of the mech bitsy jam, I turned to him and said, "First thing off the top of your head: describe a bitsy style game with the theme 'mech'."
After a beat, he replied: "Maybe it's about someone who is the only one left on the planet and has to build a mech to escape before a world-ending event?"
I grinned, gave him a kiss, and informed him we were going to make a game together.
The next day, we discussed more details about the game, answering questions like:
Initially we disagreed on what the world-ending event should be. Tom wanted the urgency of an asteroid, where I wanted to slow burn and real-life parallels of climate disaster. Since the main difference between these two would just be narrative, we compromised by deciding to make two versions of the game. One version would be written by Tom and feature an asteroid; the other would be written by me and feature a climate disaster.
If you've played the game, you know that this idea was ultimately scrapped.
One of the reasons it was scrapped was for time, such is the nature of game jams, after all. Another reason was that I liked what Tom did with the narrative too much to want to replace it with my own.
Where the game would take place was a much easier question answered. Tom said he saw the game taking place entirely in the avatar's lab. I asked if he could draw a picture, and he did. The resulting sketch translated extremely well to bitsy's signature pixel art style.
Gameplay flow was another idea that was fleshed out and then dropped. Initially the player was going to need to complete the mech in-game before being able to fly away. The player would need to choose a mineral to make the new circuit board out of, refine that mineral, build the circuit board, install the correct algorithm, before finally installing the circuit board and flying away.
If you have any experience with bitsy, you'll know this is kind of asking a lot from a bitsy game. I was fairly confident I could achieve it with the Dialog Choice bitsy hack (thus why all the stages only have two options), however I struggled to get the hack working as intended.
Additionally, I worried the focus on making correct gameplay choices would cause the player to skim dialogue for the answers as opposed to engaging with it emotionally.
Oh, and why is the game called "M.E.C.K. 415", you ask? Well, when I went to start the game, I mistyped the title as "Meck" and we thought it would be fun to try and retroactively justify it. And it's 415 because they were easy numbers to draw in pixel art.
Sketch in hand, I got to work laying the foundation for the bitsy game. My first realization was that the sketch wasn't a square, meaning either the game needed to be a minimum of two rooms (stacked on top of each other), or one room that doesn't extend the whole width of the bitsy canvas. I quickly dismissed the latter option, since it wouldn't leave us with enough room to work with. I settled on two rooms: the mech and the lab. The perspective in the mech room is more of a neutral view where the lab is more of a high view or even bird's eye view. This is to hopefully convey a feeling that it's really one space, but the transition between rooms is more of a camera transition than a physical one.
Once I had the overall structure of the rooms implemented, I hit a bit of a wall with what to put in the lab. What would a person have in a lab? I don't know, the last time I was in a lab was probably in high school? Tom gave me a bit of guidance with the gameplay elements as a starting point, and from there I mostly just added random placeholders to get a feel for the space.
I knew I really wanted the art to help convey the perspective, so I purposefully designed the lab with the idea that the player would be able to go in front of or behind tables. As far as the art itself goes, this was fairly straightforward, the tricky thing was getting it to work happily it bitsy, which I'll talk more about in the Bitsy Hacks section.
One of the challenges with bitsy is finding a good color palette (at least for me, as someone pretty color challenged). Because we were using the transparent sprite background hack, the sprite color needed to contrast with both the background color and the tile color. Additionally, the mech used the tile and background colors, so they needed to contrast as well.
To work out a decent color palette, I put the pixel art into photoshop and isolated each section.
I knew I wanted an additional color for the diagnostic light and the circuit board, and I also considered having another additional color for the mech itself.* I also knew I wanted the scheme to be reddish overall.
*I liked the idea of the player being able to step behind the legs of the mech, but to achieve that, the mech would need to be a different color (since the background color would be made transparent). Ultimately I didn't think it was worth the added effort.
Using a combination of PerBang.dk's Color Scheme Generator (my go-to resource for this kind of thing) & Adobe Color, I finally worked out the color palette we ended up using.
This game is a hacky piece of work! Huge shoutout to the bitsy-hacks repo, without which none of my bitsy games would exist.
The following is a list of all the hacks the game utilizes and what it uses them for:
| Hack | Usage |
|---|---|
| 🔝 direction in dialog: provides a variable with player direction | This hack was used to prevent the player from being able to talk to object from the wrong side of the table, as well as to gate the player from being able to climb the ladder when the player was currently behind it. |
| 🖼 dynamic background: HTML background matching bitsy background | Pretty self-explanatory, this hack was used to keep the HTML background matching the current bitsy palette. |
| 🔚 end-from-dialog: trigger an ending from dialog, including narration text | This was used to trigger the end when you enter the mech! This actually is combined with "Exit from Dialog" to facilitate the palette swap on the ending. The dialog for when you interact with the mech entrance is:
Well... Here we go.(exit "ending,0,0")(end "3...(p)2...(p)1...(p){clr3}{wvy}RUMBLE{wvy}{clr3}(p){clr3}{shk}FWOOOOOOM{shk}{clr3}(p)Oh, God...(p)... It's working.(p)Am I... going to survive?(p)I... I am.(p)Elysia. Here I come.")
The "exit" takes you to an empty room with the ending's blue palette just before the end sequence is triggered. |
| 🚪 exit-from-dialog: exit to another room from dialog, including conditionals | This is used for a couple things. As mentioned above, it's used to swap the palette just before the ending. Additionally it's used as a gate for the ladders to make sure you're going up them from the correct direction. In the final game there are actually two mech rooms, one where you're on the scaffolding and one where you aren't. This hack is used for the gate between them. |
| 🔀 logic-operators-extended: adds conditional logic operators | This is used to be able to check multiple player directions in the game dialog conditional, instead of one at a time. |
| 📃 paragraph-break: Adds paragraph breaks to the dialogue parser | Another pretty self-explanatory one. Tom especially was very particular about how the dialog looked in-game, and the paragraph breaks hack was an easy way to help assure it looked nice rather thank fiddling with it by hand. |
| ⏳ permanent items: prevent some items from being picked up | Because the game has a lot of layering, it was important the player be able to stand in front of objects, so any object that the player stands in front of is actually a permanent item. |
| 🛑 solid items: treat some items like sprites that can be placed multiple times | For most of the sprites, they're actually split across two items, the lower half being a permanent item that has no dialog, and a solid item top half that contains its dialog. The top half was a solid item instead of a sprite so that it could be easily layered with other items as well as copied across multiple rooms. This made it easy to make a duplicate mech room that served as the room for when the player was on the ladder, since all of the items could be the same. |
| 🏁 transparent sprites: makes all sprites have transparent backgrounds | This hack is, in my opinion, the most important. I'm not a huge fan of bitsy's default behavior in terms of how sprites cover tiles. To achieve the visual I was after, the background of sprites (and items), needed to be transparent, so they could be layered. This does however pose an additional challenge when it comes to working out the palette. |
I don't really know why I wrote this. I'm also not too sure why you read it? I hope it was helpful in some way to you. We had a good time making M.E.C.K. 415, and we hope you had a good time playing it.
Oh, and I'm sorry about the cat.