Hi, all! I’ve made a small post-LD12 fix of Breaking the Tower, and I’ve included a high score list.
|4.26||Codexus||3.96||Ariel Yust||3.96||Orangy Tang||4.19||allefant|
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.
This was my first Ludumdare entry, and not knowing just what I could manage in 48 hours I decided to stick with a simple idea and tools and libraries I’m familiar with. The original game idea was to make the player hit all the walls in a 2d space with a trickier-than-usual to control ball, although this didn’t quite work with the Tower theme. Hence, I decided to turn the walls into a scoring mechanism, and to make a tower to ascend or descend instead.
Here’s the postmortum I promised last week. I haven’t read the comments on my entry yet and I wanted to get my thoughts down before I did.
THis LD48 was my third, if you don’t count the two that I intended to enter and never did. My number one goal was to finish, and the number two goal was to do something fun. I’m happy that I completed goal number one, but failed on goal number two.
Technically, I didn’t really even submit a game. There is no real end condition or repeatable system that goes until you fail. I never got a chance to actually implement the “monster at the gates” scenario, as I fought with a stupid bug at the end brought on by stupid changes on my stupid part.
What did I do wrong in the LD12? I didn’t spend enough time on it. I should have squeezed three or four more quality hours in. My mother-in-law was visiting, and that led to the normal distractions as she visited with us and our newborn. I probably could have completed something that resembled a game with a little more time, and I know that the time existed. I just didn’t use it well.
I didn’t get any real animation done with the monsters or the dude. It would have been nice, but time didn’t allow it. I also used some sound, and while it wasn’t nearly to the level that I wanted it, I thought it was neat to hear the monsters gargle when they died and the arrow whisp away from the dude on the tower.
I think my usage of the angle/power aiming mechanism was a bad idea. I think I should have gone with the “point-and-click” method, which would have been easier for the user and fits better with the action oriented design. The arrow was made up of separate graphics rotated to the closest 15 degree mark. I could have implemented a rotation transformation, but that would have taken longer and probably been more CPU intensive.
So what did I do right?
I met the theme of the Tower by simply having a tower in which the dude fired from. I didn’t stop there, and created a middle floor from him to fire from and also made the doors at the bottom open and close. The tower isn’t just a pretty graphic. It’s functional and strategic.
The part I liked the most about my entry was the graphics. Most of them were sketches from my initial game idea sheet. I scanned it into the computer and photoshopped color into it and cut it into separate parts and images. I think it gave my entry a unique style that I’d like to use again in a future competition. I’m not a great artist, but I think if I don’t try to make everything perfect, it comes off better. Reminds me a little of the original South Park or other ‘construction paper’ style.
Another thing that I really think I did well was keeping the coding distractions to a minimum. By this, I mean that I didn’t get sidetracked coding something that wasn’t important ‘right now.’ In the past, I will start to code something that may come in handy later, but doesn’t really help me too much in completing more important foundation pieces.
So all in all, I think I did ok. I can see that I learned some things from the last time around and I really look forward to taking the things I learned here for LD13 in December. Same goals, but I will try to think through the game for a little while before coding to make sure that it is actually a game and hopefully fun.
I would call my game Incoming Fodder both a minor success and a minor failure.
My goal for this competition was to create sound and music in the game, and of course it must be playable. So I made a lot of sound effect, some good some bad, mostly bad when things get crowded there are so many sfx playing it’s annoying. The music, or what you might call it (You can kill the music) was a complete failure. There was a MOD player lib for flash that I though would be awesome to use, took about an hour to get it to work.
Then I needed to create music. I suck at composing, I know it, doesn’t matter what tools I use, it’s just awful. I might have a tune in my head, trying to get the music to sound like that never ever happens. So I scribble down something trying to make it sound like music, copy paste. Crap, I better sing the tune next time.
I chose flash 9 as platform, that was good. Learned a few valuable things, like it’s not easy to pause things running with event listeners without preparing for that before you build your system. I had to skip pause, lost some time there.
Game play wasn’t as developed as I wanted. I really don’t know why I didn’t have time to improve here, I picked the idea of the game so I could spend more time on polish, but I guess I wasn’t interested enough in the idea to really devote to it. I need to be quicker in this area. I need to focus on that in the next LD.
Coding OOP is lovely, I had one moment of awesomeness this time. I’ve built a tower that can shoot arrows, then I built a castle to protect, after a while I realized that the castle also should shoot arrows, so I made castle inherit tower and voilà it shoots arrows! I did have to make it own 3 more towers to make it have 4 arrow shooters.
Graphics was the least of my priorities and it turned out ok, the defeat screen it the best of the whole game.
Timelapse. You may recognize the music 😉
Since I’m only a few months into my game dev journey, I set a few concrete goals to ensure that I would finish with a game:
- Have gameplay decided on before bed on the night the theme was revealed
- Have gameplay/art 90% done by bed on Day 2
- Finish gameplay/art, do music, menus, polish, package, etc on the last day
- Also eat a lot of unhealthy food
My Idea: My main concern was to make my game about owls. In the end, I accomplished this, but I should have thought it through more. After getting most of the gameplay implemented, I started to realize that the scope of my game was way too small considering the time I had as well as my ambition. I was sure that it was too late in the 48 to start over, and I lost motivation.
Motivation: (That was a pretty direct segway.) I didn’t really feel like finishing my game. I didn’t put much effort into it until night fell on Saturday (awesome). That’s when I made the game’s song, and finished gameplay for the most part.
Packaging: I provided three versions of my game: an exe made with py2exe, an app made with py2app, and a source version. I guess I need more practice with py2exe. It took me a while to get my game packaged, and I even had to change some code in the game to make it work. My py2app experience was great, but the .app ended up being over 20 megabytes large. That sucks, sorry guys.
Music: I am really happy with the way my simple song came out for my game. I had a whole other song ready, but it just didn’t fit the mood of my game. The completion of this song actually brought me out of my motivation problems in the second-half of the competition.
Code: It should be no suprise that I had no trouble implementing this game. There’s really nothing impressive about the way it works. Some aspects are even quite underwhelming, such as the collision perhaps. Overall, I got to spend some quality time with vim and python…what more could I ask for?
Motivators: This section is pretty self-explanatory.
I Had A Wonderful Time: LD12 was a blast, I learned a bit and had a great time. A success overall.
I have a lot of ideas on how I can improve for my next LD. I feel like I can make a bigger and better game. I also think I can improve the efficiency of my music recording and packaging processes.
Well, I’m back from spending last week in LA at the siggraph conference. Looking forward to playing all the entries.
A quick postmortem: I was using this compo as a chance to experiment with Ogre3D, so I didn’t expect to end up with something too polished, but i did hope it would be at least playable, which didnt quite happen.
What went right:
- Ogre particles — easy and they look great.
- Art assets. I tried to focus on the minimum that I would need, and they turned out pretty good.
- Learning Ogre. I learned a lot more this way than just reading docs would have taught me.
- Great theme. I had a lot of good ideas for this one (maybe too many).
What went wrong:
- Camera — I spent a lot of time messing with the camera. Afterwards, i realized I should have just went with a fixed close-to-overhead camera.
- Starting with ExampleApp was more trouble than it was worth. In the end, I wasted a bunch of time rearranging it.
- Too many ideas: The theme generated so many ideas for me, I kept changing my mind and adding things. I should have gone with a straight up tower defense.
- Too ambitious. Didn’t get first-playable until Sunday.
I posted a little list of tips on LD Survival, and ended up ignoring almost all of them. That’s okay, I had a great time and got a bunch of experience with Ogre3D.
A technical note: I was using Ogre’s OpenGL mode during development, and noticed at the last minute that the D3D mode was much faster. So the readme encourages you to use the D3D mode. However, I didn’t realize until afterwards that it blows up after a few minutes, so if you get everything flying off the screen, switch back to OGL. I probably forgot to initialize something.
On 8/8/8 @ 8pm Ludum Dare 12 began, and the world would never be the same. The theme was ‘The Tower’, once again the theme ‘evolution’ was downed through natural selection. I didn’t find the theme very inspiring, but I was also brain drained from taking two finals earlier this day. I aced the classes though, so I was feeling good. One class was calculus, which probably influenced my choice of game.
I wasn’t having any particularly awesome ideas friday night, I wrote the basic “Hello, Tower” code. By the way here’s what I used:
Slow old laptop, which I’ve done all my coding on for about the past year. I like to write comfy code on the couch. Windows XP.
My IDE is Microsoft Visual C++ Express 2008, library is Allegro, graphics in Gimp.
Anyway I went to sleep without a decision at my usual 11pm, too tired to think. The possibilities I had come up with at this point:
- Grow towering corn stalks by watering, but watering off center will cause corn to grow at an angle and eventually fall.
- DeSprawler, pluck people from suburban houses and drop them in big city apartment towers.
- A tetris game where you cleared equations instead of lines.
I woke up at my usual 8am, still not enthused about any idea. After lunch, about 1, I had decided on and started to code tetris. Now, I’m glad I finished it and I’m happy with it, but I could have come up with something more original, but so much time had already passed, I figured this would be simple to do in the time I had.
Also, funnily, I almost did a tetris clone for a previous LD. In LD6 (Light and Darkness) I started a game which involved working at a solar panel assembly plant. Solar panel parts would come on a conveyor belt, in tetris-like shapes (but I was going to have many more shapes) and you would pick them up with the mouse and drop them into a grid. The object was to fill as many grid cells as possible, but to make things trickier, the lights were slowly dimming, but completing a panel would raise the light level depending how much of the panel grid was filled. I didn’t finish that game in time, but now that I have a tetris engine, it would be pretty easy to finish it up to some extent. I put this into consideration when deciding on my LD12 game, which is actually not a good basis for the choice.
So, Saturday was making tetris for about 10 hours, rotation is the tricky part, I drew out all the pieces in all the positions on graph paper and typed in about 300 lines for this data. It’s all modularized so I could easily add more pieces and positions (I was thinking, tetris with 8 direction rotation, bricks on diagonal lines). I tested and got the numbers and symbols in the bricks and tried forming equations. They weren’t coming out too well, always the wrong symbols, I was thinking of giving up now because the game seemed overly frustrating. At this point there was not the tower of equations in the start. The game hardly had to do with the tower theme.
I played Notch’s entry: Breaking the Tower for at least an hour on Saturday night, too much fun, I had a few tabs of the game open and would leave them alone to just gather up resources while I coded. Note to self: there will be time to play other people’s games when they’re good and done after the compo ;] These web browser games are great, such easy distribution! This is exactly why I learned Java earlier this year, to distract people so I could win at LD ;]
Saturday night I went to sleep at about 1am, pretty much given up, woke up at 9am, lollygagged, at about 11am I decided I would go ahead and finish it. Sometime after this I came up with the tower idea, put that in, and now I was making equations! I got into it, making the equation checker, and I was doing pretty good on time. The game was a grid on a black screen with green text until about 4pm, 4 hours from the end, when I started making graphics. Making the background with help, code for level starting and sequencing, and tile graphics came pretty quick.
About an hour from the end, I remembered that in LD10.5, the game I submitted didn’t run for some people because I didn’t include any runtime libraries. So I researched that, found some libraries I hoped would work, but I didn’t actually get to test them on a virgin computer until after the end. This was because when I built the game in release mode, I got a screen full of tiles! One hour from finish and here’s the showstopper. Only happens in release, so I couldn’t debug easily, I was stumped. I narrowed it to some problem accessing the grid data, and switched _setstr to strcpy, and it was fixed! Whew, 15 minutes from the end and I almost didn’t have a game. Built my zip, wrote my post, uploaded and that’s a wrap. gg.
I’ve posted pictures of some of my meals, workspaces, kitties, and screenshots as the game was being made at a picasa album here: http://picasaweb.google.com/greencow/LudumDare12
No, I didn’t record one. But I’d like to next time, if somebody can tell me how. SO, if you can, comment here to tell me how I can record a timelapse on Windows XP please. 😀
Well no video Just some time scale of how things went. Well times are not precise but close.
Time for some thoughts. Check them out below the cut.
It’s now Wednesday, and I finished my game Sunday evening. I’ve had a few days to think about it and my experience.