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!

Roomba’s Revenge

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.

This 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.