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!

This week I fleshed out the Rumor Generator. Basically all the random generators from my old spreadsheet has been implemented. The goal is to create an entire world at the click of a button.

New features:

• Religion and Arcana facts, similar to the Rumor and History generators from before
• Quick NPC generator
• Name generator for any building your adventurer’s would likely visit in a city
• Town demographics for creating an entire town at the click of a button

My next task is implementing collapsible buttons to better display the city information. I plan on adding such buttons to the entire world data, generating data on each continent, country, province, and city. Not sure whether to generate it all upfront, or on the fly as the user clicks around. It seems like a lot of unnecessary generation if the user only wants data on one city. Maybe I can just create a separate generator for the World.

Rumore Generator 1.1

Need random rumors for your D&D compaign? Not satisfied with the ones already out there? Want rumors tailored specifically for your setting?

Well, look no further because Anthony’s Rumor Generator is here!

Features:

• Randomly generates seven rumors or historical facts
• Don’t like them what you see? Refresh the page for seven more!
• Use the location links to adjust the names of places used in the generators

Right now, the generators start off using my current campaign’s location names. I plan to loading random from the start, and then using a load/save feature for regular use. There are also problems with plural usage, which I intend to alter by hand when copying for game use.

Rumor Generator

Not as big of an improvement as Day 1 was, but we’re getting there. Energy levels are definitely a lot lower than yesterday. I think we’re running out of something something. (That’s funny because the Ludum Dare theme is Running Out Of Power, ok) I need sleep!

Streamed for 12 hours today. And programmed for more. Had to learn how to do the plug’s cord without anybody watching. And imported the new models off stream; it’s tedious stuff.

Mmmm sleeeeeep.

Ludum Dare 39 is Running Out of Power. After many hours of brainstorming, we decided to let me choose among the favorites. It was either a space sim, or an electron puzzle game. Since I don’t know the first clue about circuit boards, I went with the tried and true space sim.

The catch: you only have one plug to power all your systems. You must power your warp drive, but when enemies come flying in you have to fend them off. Call in for assistance, or shoot them down yourself. Raise shields, scan for distant bogeys, and try to make the jump to warp speed before you explode!

My goals for this Ludum Dare are: implement an animation (a real one!), and maintain a positive attitude. Last Ludum Dare I was overly harsh on everyone, and I really regret it. So far, all is well, and it seems everyone is enjoying themselves a lot more. We’re keeping it small this year, so it’s just me, Louis, and Vince again.

Compare the following work-in-progress gifs, taken 24 hours apart:

It’s amazing what a dedicated day can make. These are 100% my (boxy) models, so adding Vince’s models will only make it that much better. And of course Louis is doing an outstanding job with the audio and music so far. Can’t wait to see what the next 48 hours brings!

Here’s some new gifs of the game, 24 hours later.

“Heya boys and girls! Can you help me defend the motherland against the illegal alien refugees?”

“Die aliens, die!!!”

Enlist the aid of Mother Nature to ward of the invading fleet.

Everything is to tiny. It makes me sad. Going to enlarge the player tomorrow to bring some life back into the game.

Just finished the first full day of Ludum Dare 38!

The theme is “A Small World”. Brainstorming made me realize why I’m in such a bad mood during LD: I hate how we can’t make all the cool ideas we come up with! I really wanted to make a 3D alien abduction game, but we decided to go with a 2D planetary defense game. Here’s a first look:

Defend the planet!

I’m streaming the whole thing over at https://www.twitch.tv/messinabrothers, so come check it out!

Voting is done, and the results are in.

Roomba’s Revenge placed 167th out of 2390 entries. Pretty good!

The group decided on a tried and true template: destroy everything you can see. Unity’s physics engine makes implementing destruction a breeze, so I focused more on the overall experience rather than gameplay mechanics.

While the game came out feeling finished, I really wish we had chosen a more innovative game. That’s where I think Ludum Dare shines; creating games that wouldn’t otherwise come into existence. My enthusiasm and thus motivation to program was lacking, especially at the beginning. I didn’t lose any sleep over the weekend. At least this LD proved that our group can make a functional, fun game that people enjoy playing.

I read up on project management beforehand and got to use a lot of what I read throughout the weekend. My favorite parts were the one-on-one discussions I had with everyone. I would talk about what they made, how to implement that into the game, and what features they should work on in the meantime. This was an improvement over the previous LD where I made everyone write up any suggestions to a shared word document, which was rarely used. This also allowed everyone bring up any qualms they had about the game in a controlled environment. Rather than yelling into chat and talking over one another, it gave everyone a chance to be heard.

A big part of the project management tips involved listening, which I may have overdone. People would ask for suggestions about what to create, and I refused to help them along. I did this for two reasons: I wanted everyone to have ownership over their contributions to the game, and I wanted to see what people made given no direction, which I thought would help creativity. The results are as follows:

Audio: Players really liked the audio, and I would often firing up the game just to listen to the music. But the musician had a tough time getting the sound right, and was disappointed in the final outcome. A lot of recorded music was discarded, and the end result was nothing as he imagined.

Graphics: The only suggestions made for the 3d models were what types of objects we wanted in the game. The modelers tried their best to come up with them all, but probably half of the models that were created weren’t production ready and had to be cut from the game. If I had discussed with them what was important to make and how to create models that fit into the game better, I bet we could’ve included a lot more destructible objects into the game.

Menus: I told the designer we probably would need a main menu, a pause menu, and an end game menu. She went to work, but because I asked for so little, she spent a long time making just the main menu. While the outcome was beyond great, I could’ve been more clear in what I expected from the UI. My biggest letdown is the in-game interface: text for the timer and battery life, instead of something more visual, like a clock, or battery icon.

Here’s the breakdown of the scores, with past Ludum Dares for comparison. While I personally thought innovation was lacking, we placed in the top 10% in that category. Note: voting was disabled for LD 36 (thank goodness), and I did LD 34 on my own.

All-in-all it was a good time, and the game (and results) speaks for itself. I really enjoyed being more of a project manager this time around, but it came at the expense of sub-par gameplay. Couldn’t have been happier with my teammates though. Just wish we could’ve broken into top 100 overall.

As always, looking forward to the next one!