Last month, I made 100 Pixels to Midnight. Click here to play.

My intention with this game was to teach the player something. Like the Sims, or more appropriately, Sim City, teaching moments aren’t explained to the player. In the Sims, a burglar freely robs your house if you don’t have an alarm system. In Sim City, land values suffer from cheap coal plants pollution. There was nothing telling the player “if you do that, then this will happen.” The game responded to the player organically.

I brainstormed a number of games, and this one seemed the funniest. Adding narration was easier than I thought it would be. Playtesters seemed to think it was funny.

Since this was supposed to be a one-month game, I wanted the simplest mechanics possible. It may have ended up too simple. I’m itching to program something with more meat to it, like a simulator. But for the first month of the year, this was a good test run to see what I was capable of.

Originally, the art was double the size. I’m glad I cut back, and I feel like the art could even be smaller. The chosen palette worked out, for the most part. The program automatically generated animations, making it possible to cram so much art in so little time. Speaking of so much art – I rushed the end sprites; it took around an hour to add one building. I ended up doing the minimum buildings required in the end. I didn’t even touch the end scenes (thank goodness for Simpsons). Art in general was the bottleneck to this game, and I was pretty frustrated with it.

Playtesting helped immensely. One, it gave me a break from art! And two, it helped me see how bad the game was at explaining things. The narration was confusing, nobody understood when the narrator died, and people didn’t know there were alternate endings. Oh, and they couldn’t beat the game! I’m not sure if I actually fixed any of these problems, but I spent much-needed time on the narration. I’m pretty happy how it ended up.

I’m not sure how I’m going to solve the “art” problem. Animation takes a lot of time, and I’d rather be programming. For 100 Pixels specifically, I definitely should have cut the preview window. The purpose of the window was to showcase the pixel art and the consequences of bombs, but it took up a lot of screen space, and it (at least!) doubled the art load I had to do. I could have spent that time on more buildings. For bombing effects, I could have placed smoke animations on the plots. While adding “preview window” to the TODO list was easy, the effects of that decision almost tanked the game.

Well, I’m already in the middle of my next game! It’s art-based, and even less mechanics. Wait a minute…

I went into Ludum Dare 43 thinking I was going to solo the whole thing. My usual teammates, my brothers, had a show on the first night. We went to our uncle’s funeral the next day. With limited time, I thought I’d do a simple game and not bother anybody. After doing so many LDs with people, it’d be refreshing to go solo.

Ludum Dare 43’s theme was Sacrifices. Play the village shaman and assist villagers in sacrificing animals to appease the gods!

Naturally, I over-scoped the game. I turned a simple concept of a ritualistic shaman into a number of tedious mini-games. Memorization. Drawing. Potion brewing (and cleaning). Space management. One would’ve been fine. Two might’ve worked. Four was just too much.

Thankfully, I had some help. My SO saw my plight and brainstormed ideas with me. One of my brothers joined mid-jam and took over the audio and models. Twitch chat offered advice and technical assistance, especially in the final hours. Without everyone’s help, the game wouldn’t have been the barely-playable state that it is now.

An early build of the game, featuring models and coloring by yours truly

If I could do the whole game again from scratch, the entire game would be one 2D screen. A villager’s face pops up in the corner, saying they want X with Y. You choose a color from a palette (no crafting involved), draw the symbol, confirm your drawing, and see how close you got. Simplify the game to its essence: drawing patterns in different colors.

I think it would have been better if the colors represent gods, and the requests be fulfilled via symbology. Simple requests (like, dislike, cure) would be represented by a box, a line, or a circle. Complex requests (love, hate, harvest) would build on the simple symbols, like a filled box, criss-crossed lines, or a tree in a circle. The symbol-drawing is what made the game unique. It would’ve been trivial to add more symbols with the way I programmed it. If I had focused on symbols more, I think the game would be both simpler and better.

For the (inevitable) Post-Ludum build, I made a number of changes, most significantly the color palette. After hearing the music for the game, I wanted to go all in on an ’80s retro theme. Due to time pressures, we didn’t achieve that, so I added it in after. I found some ’80s-looking fonts, as well. And the villagers sport various retro-inspired apparel.

Palette 2.0: ’80s Edition. I based the whole thing around an ’80s neon pink. Don’t leave the arcade without it!

Changes touched nearly everything in the game. The ritual book uses more symbols and less text. Villagers enter through the door instead of from somewhere off-screen. The drawing pen no longer requires the user to let go of the mouse on the ink – hovering over the bowl instantly changes the color. This fixed the awkwardness of clicking a sacrifice. Clicking was something I tried to avoid.

More importantly, the way villagers enter and exit was revamped. In the original build, the villagers never stopped coming. It didn’t matter if they received their sacrifice or not. I thought that losing a chance to please a god would be a nice detriment for the player, an incentive to go faster.

But the game was never supposed to be about racing the clock. That’s only there so the user has to do something, rather than nothing. The game is about color and symbol matching. So let the player draw! Before, the player had to get through 15 villagers in 5 minutes. Now, once 10 villagers leave happy, the day ends and the game is over.

Throughout the weekend, I kept wondering why I had set the resolution to 640 x 514. I didn’t question the preset in Unity; I obviously added it for a reason. I figured I researched it before and that was the best overall resolution to use. Turns out 640 x 514 is the resolution used for Ludum Dare’s title covers on the website. D’oh! Needless to say, the resolution was fixed for the post build.

Spiked chokers were a thing back then, right?

One thing I thought I did well was blocking-out everything the first night. I made a villager: three vertical cubes, the head colored differently than the body. Every other object was then sized around this. I gave everything to my brother the next day, and the models turned out great. No time-consuming resizing!

In my opinion, the thing I did worst was scope. “KISS” (Keep It Simple, Stupid) is written in my LD notes for a reason. I rushed the brainstorming portion, but it’s important to get the gameplay right from the start. Otherwise, what’s the point? Why put all this effort into a bad game?

On the last day of the competition, I thought the whole thing was a bust. I just wanted to finish it and move on. Playing it now, the game isn’t so bad. It was a little too ambitious, sure, but all the elements are there. I’m hoping the Overall score will be at least 3.0, but it’ll probably be in the mid 2s. We’ll see in a month!

The theme is “The More You Have, The Worse It Is”. Ergo, drunk driving simulator!

Day 1

Day 2 – Getting Drunk

Day 2 – Blackout!