GBGamesOk, I have a window that opens and closes. It’s not that amazing, but it is a lot of boiler-plate code. I probably should have declared that I will be using some existing code to, you know, render a window.
Anyway, on to lunch. That’s right! It’s time for my award-winning peanut butter and pickle sandwich!
I also had carrots, broccoli, grapes, and a peach.
Also, my cats are dealing with my LD-induced schedule fairly well:
I took some time to figure out what features I’ll need to implement, what art and sound I’ll need to create, and what the complexity of it all will be, and I’ve come up with a backlog of 103 Agile story points.
Now, iterations are going to be kind of loosely based on “Whenever I get it done” as opposed to time-bound sprints. Still, having all of the work figured out up front helped me figure out that I was missing some features. For instance, an instruction screen! Also, I feel that the rest of LD will be much more focused. I’ll always have a piece of functionality assigned to me that I should be working on.
I started my day right: with a banana!
After reading for a bit, catching up on LD posts, and awarding some trophies, I finally made myself a full breakfast!
As you can see, I had scrambled eggs, buttered toast with some cinnamon sprinkled on top, and a glass of orange juice! I also have my unread “Artificial Intelligence for Games” book handy. I have a feeling I’m going to need it.
But first, a quick shower! Then I can get back to working on my game in earnest. In the meantime, I’ve realized that my hero is going to need to know how to fight an enemy. I had a couple of states as Fight or Flee, but what does Fight mean? I think I’ll change them to Chase/Evade, and Attack is a completely different state.
My plan: when the hero is chasing an enemy, it tries to get adjacent to it. Then it can attack. The attack occurs, damage is calculated, and then the hero has to wait a few moments before he can attack again. Hmm…maybe the hero should be put into another state after an attack: rest mode. This way, he can’t attack and flee immediately. He has to stick around long enough to be attacked himself.
Ok, Self, don’t panic. I’m sure the AI isn’t going to be THAT overwhelming.
Another mock up!
I still don’t have code, but I’ve decided that the individual squares/tiles of the game will be 16×16. It’s tiny, but that means the graphics don’t have to look terribly great. The hero is 8×11.
I wish I knew a better color scheme to use, though. Colorblind players, let me know if you can’t see anything because the greens, blues, and reds blend in together. B-(
My next task is to actually create real tiles and sprites, and then I can get started on some code to render it correctly.
But first, I think I’ll go to sleep. Good night, LD!
After thinking about ways to play as the hero and using enemies as weapons, I decided that I would make the player a villain who summons and sends out minions to attack the AI-controlled hero.
I created a mock-up of the UI:
You can see that the hero’s status is listed at the top, and the player can see how many resources are currently available, along with what minion types can be produced. They will have different costs and varying abilities. Or, at least I’m planning that they will now. When the deadline looms, I might have to limit the variety.
You can also see the world map. I didn’t spend too much time drawing out everything, but the basics are there. The hero is visible and moving around the world, searching for weapons, health, dungeons, and your castle. There will be obstacles, such as trees, mountains, and water. There will be towers/dungeons. Whenever a tower/dungeon is cleared, the hero gains access to new areas. Eventually, the hero will find your castle, and you’re done for.
Unless, of course, you can get your minions to do their job, hunt down the hero, and kill him first!
I mocked up a close-up of that first area as well:
The star is a weapon upgrade. The heart is health. The barrel/spindle thing is supposed to be the tower. Circles are obstacles. I moved the man around, imitating what I expect the AI should look like. In doing so, I realized that I needed to figure out what visibility the hero will have. It wouldn’t be right for him to make a direct line to the castle. He’d have to explore, so I think he’ll have a fog of war to deal with. He’ll normally be in exploration mode and can see a few squares around him in any direction. If he spots a location with a weapon, health, dungeon, or castle, he’ll switch to “Move me there in the fastest way possible” mode. If he encounters an enemy, he’ll go into Fight mode, unless he has low health, in which case he’ll be in Flee mode.
I also realized that I needed to decide what happens if he sees a target, starts moving toward it, but spots a new target on the way. Should he move to the new target? Should he ignore new targets? I decided he should have a queue of targets, and then I realized a prioritized queue would be best. If he sees a weapon upgrade, he’s going for it first. If he spots health, he’ll only go to it first if his health is low. If he has perfect health, he’ll ignore it. Towers/dungeons/castles will be the last targets he’ll go for. This way, if he has low health, sees a weapon upgrade and a tower, he will head towards the weapon. If he then sees a health upgrade, he’ll go to the health upgrade first, then go back to the weapon, then head to the tower.
But what should the player be doing? I want the player’s main action to be clicking on locations to place enemies for the hero. At the top of the screen, you’d click on the enemy you want to purchase, then you’d click on the world map to place the enemy. Obviously you shouldn’t be able to overwhelm the hero with enemies right away, so your limited resources would stop you. Also, do I want the player to be able to place enemies anywhere, or should they only be placed in specific areas/spawn points? If the player can place the enemies anywhere, then the hero is simply going to be fighting them right away. If, however, there are going to be specific spawn points, such as the tower/dungeons, then the enemies will need to explore and find the hero, and it gives more importance to the fact that the hero is not only getting to new areas but also eliminating your spawn points whenever a tower/dungeon is cleared.
With a few hours of prototyping, I think I understand my game design that much better.
It’s time to prototype some ideas! I have a chance to play with my new barrels and hearts!
But let’s take a step back and try to come up with some ideas. Assuming you play as the hero in the game, what are the various ways you could use enemies as weapons?
1) You could use the enemy’s body as a projectile. Your attack might send Enemy A flying, but when A hits B, B is hurt. Maybe A is immobile, especially if they are somehow stuck together now, as below:
2) You could force the enemy to use its own projectiles, which happen to be damaging to all entities in the game, including other enemies. Somehow, you have to provoke the enemy into attacking. In this example, you can see that the enemy throws out its spines, leaving it naked and vulnerable. It would probably need to head home to reload, and the other enemies in the vicinity were killed.
3) You could pick up the enemy, causing it to panic and flail. Until it can get itself free from your grasp, you can move it close to other enemies and let it destroy them.
4) You could use bait to lure enemies into combat with each other. When they see the steak in this example, the two enemies can’t help themselves. They love steak! Unfortunately, only one of them can have it, so they end up in a dust cloud. Only one will survive. And get steak.
5) You could take control of the enemy in various ways. First, you could attack an enemy, bring it under submission, and train it to fight for you. It’s kind of like a Pokemon or the monsters in Rune Factory, if you’ve played that one. Second, you might have the ability to control an individual enemy’s mind or take possession of it’s body. It’s kind of like the game Space Station Silicon Valley for the N64. Third, maybe the enemies all follow whoever holds a certain token or item, like a wand or staff. If you are in control, now the enemies are yours to command! Fourth, you can find a way to mount and ride an enemy. If you can do so, you can then use it to ram into other enemies.
So these are some of the ideas I have running through my head. Even though I’ve been thinking about sending enemies after an AI hero for much longer, I’m starting to like the mechanics listed here. Any thoughts?
I was hoping that “Enemies as Weapons” would be the theme. I normally do not think about game ideas or concepts before the compo starts, but this time, I couldn’t help but think about how I would approach this one.
In Super Mario Bros, it’s common to use Koopa shells to take out enemies, so I tried to think about how the hero could somehow change the state of a foe to make it harmful to its allies. Could you pick them up, which causes them to lash out? Could you simply hit one, which makes it do something to protect itself instinctively, but its defensive weapons happen to be harmful to enemies as well?
But then I thought: what if I allowed the player to generate enemies for an AI hero? Imagine having a bird’s eye view of a world, and you can see the hero approaching your domain, but you can select an appropriate type of enemy, create it, and send it to meet the hero. At first it might be easy, but the hero has multiple lives, so you’d have to send more and varied enemies to stop him/her.
I liked the idea of generating enemies to go after an AI hero. I’ve never had very interesting AI in my previous games, but I’ve recently been reading “AI for Game Developers” and was getting a bit inspired. Ludum Dare is usually a chance for me to learn something new, so maybe this time around I’ll be learning how to implement some AI capable of avoiding obstacles, evading other entities, and figuring out how to get through the world.
Or, I should realize I only have 48 hours to implement the entire game and I might not want to spend too much time figuring out something as huge as advanced artificial intelligence. Simple AI is sometimes good enough.
I did five Ludum Dare competitions in a row, starting with LD #11. I missed out on a couple, but now I’m back for #18!
I’m excited! Only a couple more hours to go.
Everyone’s favorite 48-hour solo game development competition, Ludum Dare, is running in its 18th iteration starting tonight at 9PM Central Time (US).
As always, I’ll be updating my game development progress here and on the LD blog.
Currently, the final round of theme voting has contenders such as Technology in the Wrong Time Period, Cooperation, Enemies as Weapons, and Evolution.
Oh, and Double ZOMBIE Rainbow is another theme.
Two weekends ago, I hosted and participated in the MiniLD #20 competition.
Mini LDs are usually looser than regular Ludum Dare competitions in terms of rules enforcement, voting, time start and end times, and themes. The host can also enforce a different set of rules. For instance, one MiniLD involved using a specific palette of colors from a 64×64 image to load levels from, and it was interesting to see all of the completely different games share the same level data.
For MiniLD #20, I picked the theme “Greed”, with an optional fun theme of “Fishing”. The special rule I made: “Only one of each.”
In programming, it’s easy to make lots of copies of objects. Well, I’m putting a stop to that! For this MiniLD, you’ll need to ensure that every object in your game is unique. If you build a wall, there better be a single wall (it doesn’t matter how complex it is) and not many tiles composited together to make a wall (unless all of those tiles are completely different from each other, which might make an interesting game…) Granted, maybe everything derives from a common object, but you can’t have two objects that are exact copies of each other. If that means you can only make a few objects, then work within those constraints. B-)
While there was some griping about this rule from the participants, many of them pulled through and submitted a game. In all, 24 entries were submitted.
Unfortunately, The Old Man and the Monkey Thief, the game I was working on, wasn’t one of them.
Also, there were some complaints about how the MiniLD was handled overall, and while I wasn’t taking any of the complaints personally, I did think I let some people down. What follows is a post-mortem of both the game and the competition as a whole.
What Went Right
became 
and this spatula 
became this Unique Spatula 
.
Oh, my kingdom for an artist!
But it worked well enough, and it was relatively quick. I even did a decent job creating the main character with a pencil drawing, did the layer tracing thing in the Gimp, and came up with a digital old man who didn’t look half bad!
Overall, tracing with layers in the Gimp made quick programmer art even quicker than it usually is! I didn’t have to worry about being bogged down in getting the lines or curves right.
Also, I’ll go into more detail below, but I’m glad I had my backup plans! When a storm knocked the power out for me and apparently 30,000 other people, I’m glad I had my Uninterruptible Power Supply to keep my desktop computer from getting more damaged that it could have been. Also, my laptop let me continue work for over an hour after the power went out, and so it was lucky that I replaced the battery the week prior. When the power didn’t come back in the morning, I took my laptop to a new, powered location, and I was able to keep working even though my apartment went over a day without power. It was a horrible situation during a timed competition, but I think I responded to adversity well.
And it helps to have an encouraging girlfriend remind you that you can’t give up. B-)
What Went Wrong
I lit a few candles, one in my office, and one in the dining room so I could see when I go out to get some water out of the fridge. Maybe 50 minutes later, the smoke alarm went off. It turns out that the dining room candle was on fire.
Now, I don’t play with fire much, but it wasn’t the fire itself that scared me. It was the fact that the candle, the thing that is meant to be used to hold a flame, was on fire! Another note for next time: don’t put out candle fires with water. The flames exploded upwards before dying out, and suddenly it was dark. I could hear the heated glass and metal parts of the candle holder tinkling, and I had no idea what was going on. And of course the office candle was also out since the melted wax drowned the flame. I had enough with fire for the night, so I didn’t bother relighting them.
So I sat down at my laptop and continued to work. I lowered the brightness and shut down many unneeded applications and was able to eek out 10 more minutes of battery life. Then I had nothing else to do but go to bed. Of course, I was wide awake. I could have searched for the flashlights in the dark or tried the candles again, but I decided this was a forced break and went to bed. My DS was still charged, and I played Advance Wars: Dual Strike for a bit before sleep took me.
The next morning, there was still no power. I learned it wasn’t just my apartment. It turns out that a huge part of Des Moines was without power due to the storms. The library is closed on Sundays due to budget cuts, and I wasn’t sure where the nearest wifi-enabled cafe with power was. Luckily my cell phone still worked, so I had people I could call and a basic way to do searches. My girlfriend was out of town, but I had the key to her apartment, so if she had power, I could work there, too.
I had options, but I’ll admit that I felt a bit defeated that Sunday morning. I wasn’t as enthusiastic about getting up and running again as I’d like to be able to report. Maybe it was because I was exhausted. Maybe it’s because my home office chair is hard to sit in for days at a time. Maybe I just missed seeing people. I was a new full-time indie, and I was secluding myself in my office for way too long as it is. Maybe I just needed exercise. Maybe I assumed the power would come back within hours and I wasn’t sure if I should venture out or stay home. Whatever it was, my motivation had dipped to the point that I was dragging my feet to decide which of these options I’d use.
When I talked to my girlfriend, she was very encouraging, especially as she heard the reluctance in my voice. This weekend was MiniLD weekend, so there’s really no excuse for me to not do what I can to continue. I packed my laptop, the laptop riser, some game dev books, and some papers and notes, and I headed over to her place. I didn’t have the key to the front door, but the doorbell is linked to her cell phone, so she buzzed me in remotely. And she had power at her apartment! Glorious power! I was able to continue work.
Of course, I lost a lot of my waking hours. While I don’t like shifting blame, especially since I had options, there aren’t many options at 3AM during a storm. Now, if my life depended on it, I’d have no qualms about waking people up at 3AM, but for a MiniLD? Still, while the power outage disrupted my work, it didn’t stop me completely.
All of these things are fine on their own, but since I was supposed to be focusing on my game project, they were distractions, and I failed at putting them off until after the competition.
Now, I think the idea of using noise to get around the limitation was clever, but outside of that, there were two options: do lots of unique content, or do a game involving only a few unique items. The latter would definitely be doable and be more along the lines of what I was hoping for.
So of course I ended up making a game that required lots of unique content. B-(
Now, being the host, I knew about the special rule long before anyone else did, but I didn’t think about the kind of game I would make until I started the competition. In hindsight, I should have cheated and thought my game idea through before the theme/rule announcement.
The Old Man and the Monkey Thief was supposed to be about an old man who goes to sleep one night only to wake up and find that all of the unique treasures he collected over the course of his long life were stolen by this energetic, ninja-like thief. The old man then had to go into the world, collect these unique items, and use them to save his wife. I figured he could use the fishing pole as a way to retrieve otherwise inaccessible items, and so the secondary theme was satisfied.
What I didn’t realize was how much work it is to program unique items! I spent a huge chunk of a day getting the fishing hook and the key to work. By the time they were implemented, I was afraid to add a third item because of how much work would be involved, and time was running out. Now, this is 48 hours. Imagine being a game developer on a 3 year project and learning that you need to implement another item without letting the deadline slip. I got some insight into that kind of despair.
Essentially, having only one of each item meant that they were either reusable, like the fishing hook, or one-offs, like the key. Either way, this rule encouraged feature-creep if you intended to make a game with a lot of unique content. If I could do it all over again, I’d have tried to do more with the fishing pole alone rather than try to have more than one usable item. Less is more, and I probably should have made a note that it was my original intent with the rule.
Except something went wrong. For some reason, the LD post didn’t publish, and it took some time to get it corrected. I was away at an event, but I checked in, found out about the problem, and got it working somehow. IRC participants learned about it, but people who were depending on the website being updated at the correct time were out of luck.
I didn’t request a submission form for the competition until near the end when I realized that there were so many participants. Some people had finished before the form went up, so they had to retroactively submit their games. Not a big deal, but it could have been smoother.
And the end? I could have handled the ending better.
Since it was only a MiniLD, the 48 hours is a bit flexible. While it officially started at a specific time, the usual expectation is that you could do any 48 hour period in that weekend. Since I had power issues, and other people were also hoping for a little more time, I thought I’d allow the competition to continue into Monday.
Then the fact that I’m running my own business took over, and other priorities came up. When I finally had time to dedicate to LD again, I learned that some people felt like the MiniLD had no closure. It was understood to be over, but there was no fanfare or official word. The submission form allowed for the entries to have ratings, but since voting was not enabled, participants couldn’t vote. MiniLD #20 felt like it just stopped, especially for people who weren’t in IRC and were relying on the main website for their up-to-date competition information. New LDers can’t be faulted for not understanding what was happening. I had every intention of providing a proper ending, but as the host, I dropped the ball.
What I Learned
On the other hand, if a game makes use of a single mechanic, suddenly it’s much more manageable. What if the entire game involved the use of that fishing hook? I probably could have finished a game using just that one mechanic.
All that said, I think MiniLD #20 was a success for me. The Old Man and the Monkey Thief is the first game I’ve ever created that made use of a scrolling background. Previous games used a single screen. To determine where the old man can and cannot walk, I normally would check the tiles, but since I didn’t have tiles, I did something I’ve never done before. I created a black & white version of the entire world map, which the player never sees, and one color represented where the player could walk. Once again, a 48-hour game development competition allowed me to learn some new techniques. I also learned what areas I need to work on. Discipline and project planning in 48-hours is one thing, but discipline and project planning in months or a year? I won’t last very long as a full-time indie if I don’t figure those out.