Category Archives: Programming

Ludum Dare 43 – A Post Mortem

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!

Ludum Dare 39: Day 2

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!

ezgif.com-cropStreamed 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: Oh What A Difference A Day Makes

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:

day 0 day1It’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!

LD38 Update Day 2

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

2017-04-23 LD38 intro

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

2017-04-23 LD38 shooting ufos

“Die aliens, die!!!”

2017-04-23 LD38 volcanos

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.

Ludum Dare 38 Under Full Swing

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:

First look at gameplay

Defend the planet!

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

Ludum Dare 37 – A Post Mortem

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.

 
LD 37 LD 35 LD 34
Rank Top % Score Shape Racer Spirit-uality
Overall 167 7% 3.76 3.32 2.93
Fun 87 4% 3.85 3.27 2.76
Innovation 231 10% 3.52 3.12 2.93
Graphics 219 9% 4.00 2.91 3.20
Audio 102 4% 3.82 3.19 2.81
Mood 168 7% 3.76 3.13 2.81
Humor 62 3% 3.85 2.55 2.63
Theme 124 5% 4.12 3.79 3.66

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!

Test Timing Improvements

I was getting frustrated by long test times, so I did something about it. Previous data showed initialization took upwards of 80% of the total testing time, so that’s where I focused my effort. The results:

2016-11-21-test-time-halved

What took 2.2 seconds per test before now takes 1.4 seconds! Each test is 128 game playthroughs, which is enough to create visible trends in win percentage. This multiplied by eight different tests is a time savings of six seconds per total test run. While this may not seem like much (and maybe it isn’t), waiting 17 seconds is a lot different than waiting 11 seconds.

Now to resume figuring out how much to cost this tech! Clearly 200 Wood is too much, but what if I tweak the AI…

Update: I recreated the test from the last blog post by running 512 games per test. Compare the two times below.

2016-11-21-test-time-comparison

Balancing Update

At long last, I’ve made progress. It’s just a tiny bit, but I’m hopeful.

2016-11-18-test-resultsThis is the result of a month’s work of balancing and testing. If I knew what I was doing, this would have taken a week at most. But I didn’t, so it went through many iterations.

I eventually scrapped everything I was working on and went back to the basics: one “harvest” equals 10 food. Then the first question becomes: how much meat does the AI gain per day?

I had to implement some smarter AI behavior, namely:

  • Only consider unlocking +Meat Skill technologies if it has already discovered the Hunting Grounds
  • If it has found the Hunting Grounds, travel there each morning. Otherwise, stay put (and look for the Hunting Grounds)

From there, I figured out how much food to consume per day. Then, I tested different food costs for the first technology. Then the second tech. Then the third, which is displayed in the table above. If I want a survival rate of say, 60%, I want to set the third technology’s cost to be 600 food. It’s that easy!

Before, I was aiming for final end-game amounts (like how to feed 1000 tribe members), but couldn’t fine-tune the early game like I wanted. The changes wouldn’t effect the survival rates in an expected way. I like this bottom-up approach because I can see how each alteration changes the game.

A friend suggested copying another game’s numbers. So simple I’m kicking myself for not doing that earlier. At least my current approach looks promising.