The theme is “The More You Have, The Worse It Is”. Ergo, drunk driving simulator!
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!
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.
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:
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.
|LD 37||LD 35||LD 34|
|Rank||Top %||Score||Shape Racer||Spirit-uality|
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!
Best Ludum Dare game yet!
Time for rest.
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:
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.
At long last, I’ve made progress. It’s just a tiny bit, but I’m hopeful.
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.
After many hours of brainstorming and programming, this is the final result. It doesn’t look like much, but I’m ecstatic. This means I can tweak numbers and see how it affects the game at a glance. No more guesswork!
Shown here are the final results of 16 tests. Not pictured are the 16 individual detailed breakdowns. Every test is a complete game play-through. The AI chooses a random direction at the start of each day, and moves to the farthest discovered locale. Event options are chosen at random. The AI unlocks tech in a specific order. At the moment, only Food tech is researched. The game ends at 100 days, or when the Tribe count reaches zero.
I ran 256 tests once. It took just under a minute to complete, and produced an 11 MB log file. Not that I read through it, but it’s good to know I can produce a test of that size if the need arises.
I already have ideas on how to expand the testing, what kind of events are needed in the game, and even different AI behavior. So much work, so little time!