- http://www.gbgames.com/blog is GBGames' Blog: An Indie Game Developer's Somewhat Interesting Thoughts
Ludum Dare 24
Ludum Dare 20
October Challenge 2010 - More
Ludum Dare 18
Ludum Dare 15
The Heartless Cookie Terrorist Award
Awarded by AndrewBC on August 25, 2010
Charlie Sheen Getting Hammered on Screwdrivers Award
Awarded by Martoon on August 18, 2010
The "I Can't Get You Because You're In The Bike Lane" Excuse
Awarded by demonpants on December 17, 2008
The Photo Finish
Awarded by Doches on December 8, 2008
The Palm Of RSI Prevention
Awarded by Hamumu on August 23, 2008
Worlds Finest Juice Award
Awarded by PoV on August 9, 2008
kai says ...
I like how you indirectly control the archers by mousing over them. It would probably be harder if they had some delay in shooting (like 1 second to get the bow ready), because as it is you will always kill the invaders if your mouse is there before they are. Nice job.
matrin says ...
Liked the idea, but implementation is lacking.
Notch says ...
It\'s a shame you didn\'t manage to finish it.
Codexus says ...
The hovering thing is nice to fire a whole salvo in one move. Too bad there isn't much challenge.
Endurion says ...
Nice idea with the hovering, so no hurting hands from excessive clicking. On the other hand some kind of scoring or stages would've been nice.
Once one soldier was climbing on the very left side so i could not shoot him.
Hamumu says ...
I like the mouseover control. I always think that should be a theme. I have lots of interesting ideas for controlling things without clicking.
Of course, on the other hand, there's no game. But it's fun to mouse over the archers.
jolle says ...
Missing a game.
Foods look good though.
Morre says ...
The game idea's really good but it needs increasing difficulty, a loss condition, and no enemies spawning while looking at title screen... :)
There's a bug where knights spawn off the tower, which would be a problem if there was a win condition. As it is, the game was fun for a short while but it needs a bit more polish.
Very nice journal, food and timelapse stuff.
nilsf says ...
The hovering mechanic is a good idea, but too much of the game is missing.
Deepflame says ...
Too bad it's lacking a game, the controls took me a while to figure out. (I had to read the comments here, because I thought the game was broken.)
Innovative idea however.
Archive for the ‘LD #12 – The Tower – 2008’ Category
What Went Right:
- Simple game mechanics still work.
Like my LD#11 Minimalist entry, I wanted to use simple mouse-movement-only controls. I feel that mousing over your units to make them attack made sense, and while I only had archers available in the end, it seemed to work. It’s too bad there wasn’t more of a game built around the mechanic, but I intend to flesh it out after LD.
- I had an office door I could close.
My cats are incredibly reliable. If I am doing anything that looks like productivity, they will insist on sitting on my lap, resting on my arms, and otherwise preventing me from working. Being able to close the door on them helped keep me focused on game development. Towards the end I got lax about keeping the door closed, but the cats left me to work for the most part.
- Using Test-Driven Development
Test-Driven Development, or TDD, is great for designing your code. Also, since code changes often, you can feel confident that your changes won’t break functionality since your tests will tell you if they did break. More than once, I was surprised that a seemingly innocuous change resulted in failing tests, so I was able to keep the game working at all times. I know that I wouldn’t have caught one specific crash problem right away, and it might have resulted in a non-working game for hours, preventing me from submitting anything. Since I found those problems sooner, even in code that wasn’t directly being tested, I felt that using TDD was the right thing to do.
What Went Wrong:
- Learning Test-Driven Development while using it.
I know quite a few people would disagree with the use of TDD during Ludum Dare, but I think what burned me was my inexperience with implementing it. I spent too much time trying to figure out how to apply it to rewriting code that I already had written. My first bunch of tests were helpful, but all I ended up with at the end was a slightly smaller Game class with a separate Timer class, and it seemed that if I applied TDD to the entire project I would barely have an SDL window by the end. While my normal projects might benefit from test-driven design, my LD game needed to get finished in 48 hours, so I had to alternate between writing tests first and skipping tests. I’m sure once I get some TDD experience, I’ll be much faster and know when it is in appropriate to write tests. For LD#12, it was a learning experience.
- I still didn’t have a good handle on SDL
Last LD, I noted that I hadn’t practiced using SDL much, and right before LD#12 started, I realized that I still hadn’t done so. I never had to render animated sprites in SDL before, and I skipped it in favor of static images moving around, but not before spending precious time learning what I would need to do it. Again, there was too much wrestling with technology instead of game development, and this time it prevented me from finishing my game.
- Working long hours really does screw with your productivity
It’s common in the programming world to find people working Twelves, especially in the game development industry. Crunch times are intuitive. If a project needs to get done in a week, and there are two weeks of work to be done, then have everyone work longer each day. Well, it is common knowledge, even if that knowledge isn’t applied, that working longer hours doesn’t translate into greater productivity.
I experienced these issues firsthand with the 2nd day of LD#12. I realized I had worked about 12 hours straight by the end, and I was making sillier and sillier mistakes. Sometimes my tests would save me, but since I didn’t write tests for a good portion of my code, I had to figure out what I did wrong most of the time. Bugs were finding their ways into my code a lot easier, and debugging was painful. When I did LD#11, I got plenty of sleep and took frequent breaks, and ended up with a finished game. I wonder if I could have done LD#12 better if I took a few more decent breaks during that 12 hour stretch.
- I didn’t get game play until the very last minute.
I knew that getting game play up as quickly as possible was important, especially in a timed competition, and yet I believe I struggled so much with the technology that the game didn’t start to form until I had minutes left to package it up and submit it. I think if I had used a few more hours in a productive way, I could have made something enjoyable.
What I Learned:
- I still have a lot to learn.
It’s weird when you feel confident going into a competition like this and then hit a wall due to your own lack of knowledge. I was depending on TDD, SDL, and common game programming concepts such as OnMouseOver, but I didn’t have much experience with them before this competition started. I like using LD as a learning experience, but next time I’ll focus on learning only one tech or tool for LD at a time.
- Test-Driven game development is awesome.
Yes, the learning curve slowed my productivity down, but I already saw many benefits from using a test-first design for my coding. I could see that my code base was going to be much better for it, particularly in terms of my ability to make cross-platform games, but I had to stop applying it due to time constraints. I was already trying to incorporate TDD into my main development before LD, but now I see that it’s going to provide better benefits than I originally thought.
- I need to work on my pacing for LD.
It seems most of my productive work happens during the 2nd half of Ludum Dare, and it makes me wonder what happened during the first 24 hours. I saw that more than a few people had working prototypes up and running within a matter of hours, and I want to make sure my future LD entries are in a playable state as early as possible, too.
Once again, 48 hours resulted in a bunch of code and experience I didn’t have before the weekend started. Even though my submission can’t really be called a game, it has potential, and I had a lot of fun working on it. The next LD is in December. A few months should give me time to develop my skill and technology base.
If you were waiting for the Windows versions of my game, Entar was gracious enough to compile a version for me. I put together a Win32 package, and the link is on my final submission post.
Thanks again, Entar!
My first time lapse was over 10 minutes long, and so I had to cut out a lot of the repetitive images to shorten it. I also found a way to combine music with it.
Since I can never remember the magical incantations for getting mencoder to do anything, I created a Makefile and uploaded it to the LD wiki:
Here it is. I’ll say more later.
Tower Defender. EDIT: This is a source only version, and it is 8MB!
EDIT: Get your smaller Linux-binary here: Tower Defender for Linux
EDIT: Get your Win32-binary here: Tower Defender for Win32 Thanks, Entar!
Unfortunately I only got game play in at the last few minutes, and there are problems. For one, there is no way to win or lose. The enemies don’t know that they’ve already stormed the walls and will keep going until they hit the sky, but they do this cool floating thing…which is a bug. Mousing over the archers will make them fire arrows, and they take a bit of time to reload before letting you fire again. The arrows do hit the enemies and make them disappear.
I’ll have a post-mortem up soon.
Gizmo tends to like to hang out with me whenever I’m doing anything related to programming. I nicknamed her Hacker Kitty. She’s helping me eat my vegan pizza and apple juice.
Diego, on the other hand, just wants to know when I’ll be done.
Well, I’m not done yet, but I have a few more unit tests, and quite a few more lines of code without tests. Progress is being made.
I was sketching out some of the interactions and just trying to make myself aware of what it is I am tackling with only 8 hours left.
Based on these notes, I think my schedule should be as follows:
- Code to draw tower based on height (determined by difficulty, a nice to have later on).
- Draw an enemy sprite.
- Code to move enemies up the tower.
- Code to determine that game is over if they reach top of tower.
- Code to mouse over an archer.
- Draw an arrow.
- Code to move arrow.
- Code to handle collision of arrow and enemy.
And after all of that, I should have a good base to work with. I’ll see how much time is left and make further plans when those are done. The cool thing is that I can start writing unit tests again for the classes I’ll be writing.
I was up until 3AM trying to get some functionality in my program before heading to bed. I woke up about five and a half hours later, showered, and am waiting for toast for my breakfast. As of this writing, there is a little over 12 hours left in the competition, and I don’t have game play yet.
I’ll be getting this submission in under the wire.
I’m starting to wonder if I’ll ever get back to TDD, but for now I have a main menu background.
I plan on starting this game by mousing over the start button, the same way Minimalist did. I like the idea that the menu gets you used to the mechanics of the game. Maybe I’ll have a mini tower drawn in with one archer waiting as the start button.
There are only 19 hours left, but I need some sleep. Good night!
I decided that I need more practice with TDD and so skipped quite a few unit tests to get a blank SDL window up that I can close. The 10 passing tests I currently have were great for splitting off a Timer class from my Game class, but I can’t afford to spend too much time making existing functionality work better.
When I start working on the various game entities, I know TDD will be a big help, but for now I have put it on hold to get the really simple run() loop going. Of course, in order to get to the point where I can write more code than the basic boilerplate, I need to sketch out a rough design.
As of this writing there are only 23.5 hours left in the competition.
And my project is in bad shape. I have some decent notes, but the actual implementation is lagging. I have to remember that I still need to create art and sounds, not just code.
Will I make it? I should, even if it means cutting back on the scope of my initial design. I haven’t been writing as much code as I would have liked, but I’m not sure how much of it is due to the fact that I’m still learning TDD and how much of it is due to the fact that I’m practically reimplementing code that I’ve already written. Still, before my last break, I found that my coding time has been very productive, so perhaps I’ll see a working game sooner than I think.