http://www.destructoid.com/monday-mind-teasers-towlr-170815.phtml

Several minds were destroyed that day.

Because you should be playing games, not working

And on that list, #32 is Notch‘s “Breaking the Tower” from Ludum Dare 12.

Pixels in print

Congratz Notch!

Also, thanks to MrPhil for sending me the photos.

If you see a Ludum Dare entry on a major news site or gaming magazine, let me (PoV) know! Thanks!

Cat Cat Watermelon

Cannon Hearts Tower is my entry for miniLD6, the secondary theme is ‘LD12: The Tower’ and the tertiary theme is ‘miniLD5: Cover someone else’s game’. This is a cover of Sivart13′s game for LD12:  “Cannon Hates Tower”.

Use up and down to aim your cannon and hold space before releasing space.

This mini game will be used in the LDCollab framework as a single level, with the other miniLD6 entries.

This first version does not use score files.

The Max Score is 1000. Post your best score in the comments. I’ve gotten 650.

Download: http://sites.google.com/site/roboticarts/cannon-hearts-tower

I wasted about 10 hours trying to figure out how to integrate the ragdoll physics into the Ogre engine.  I broke down and tried using the OgreOde ragdoll example, but compiling is a nightmare with different versions of Ogre and ODE.  So I decided to scrap that for now.  Instead of ragdoll physics, the player basically lays down flat on the ground.  Its good enough I guess.

Since I wasted alot of time on the physics I have to cut some of the features such as curved roads.  I have to integrate sound into the game still and some sort of menu for game startup and death.  Then ill try making at least 2 more levels.  So I think a total of 3 levels will be good enough.

More apple pie and tangerines .

As the game stands, once you have a reasonable idea of how the disasters work, it’s basically a matter of coming up with a strategy to work around them and following that. The simplicity of the game means that there is little variety in useful strategies. Following a strategy just means dropping blocks in the planned places, so there is not much skill or variety in that either.

My original idea regarding the style of play was that disasters should be unstoppable: the player either builds towers specifically to be destroyed by disasters, or builds towers in such a way that the effect will be minimal. A number of people suggested adding a way to avoid disasters, or allowing a level to be completed as soon as the targets were met, rather than after the time expired. That goes against my original idea, but it might make the game more interesting.

I might release an updated version with tidied code, a readme and key repeat for dropping blocks. Thanks to Morre for pointing out the lack of automatic key repeat; I use a strange keyboard with that built in, so I didn’t notice. I won’t be adding any more levels or other features because I don’t think the game would be entertaining for long enough for them to be worthwhile.

The only complicated part of the code is that which determines whether the targets for the level have been met after the time expires. There is a little complexity in the code to determine what gets destroyed in a disaster. Mostly, the code is fairly straightforward.

Because of the simple nature of the game, I thought there might be some entertainment in working out how disasters behave. However, this seems to have caused some people confusion and frustration. In case anyone is interested, here is how they actually behave and how to deal with them:

Lightning – destroys the tallest column on the field and any ajdacent columns of equal height. If there are several columns of equal height, it chooses so as to cause the most damage (by destroying as many adjacent columns as possible). If there are still several options, it chooses between them randomly.

A number of commenters worked this out. The obvious strategy for dealing with lightning is to build a single column higher than any others to draw the strike.

Earthquake – destroys the tower with the greatest height/width ratio. The height is measured from the tallest column of the tower, rather than being some sort of average. If there are several towers with equal ratio, the earthquake chooses between them randomly.

You can limit the damage done by an earthquake by building a tower one square wide and sufficiently tall to draw the earthquake. If you need to build a tall tower, you can put a couple of blocks next to it to increase its width.

Fire – starts at a random square on the surface of the field (at the highest point in a column). Moves one square horizontally in both directions and rises to the tops of the new columns. If it would have to move down to remain on the surface of the field, it stops. Any squares the fire passes through are destroyed.

This seemed totally random to some people. You can reduce the damage by dropping single blocks along the play field and on top of your towers to break the path of the fire.

Get it here.

First I’d like to say well done to everyone who took part and completed a game within the time limit, and thank you to everyone for giving me honest reviews. I had great fun taking part and learned an awful lot about game development during and after the contest.

(post mortem continues after the break)

I have to say that I agree with most of the ratings and reviews given for my entry TowerAssault0. Although it’s not bad for something that took ~2.5 hours in the creation, it was entered into a 48-hour competition and on that basis my entry stinks, and I’m glad everyone judged it on that basis as this gives me something constructive to build upon for next time.

What went right:

- Actually getting something almost playable out the door.

- The graphics turned out quite nicely by my own standards.

- From my aborted earlier attempts, I now have the beginnings of a fairly robust 3d game engine in flash, and I now know my way around Flex/AS3.0 somewhat and should be able to start developing with it properly.

- I’m quite proud of my submission considering how little time I had to spend on it.

- The learning experience. I learned heaps about deadlines and problem solving through this, and will be eager to use the fruits of these lessons in the next competition.

What went wrong:

I don’t want this section to turn into a hand-wringing self-deprecating whine, but a lot of things seemed to go wrong for me in this contest (most caused by myself)

- Lack of preparation. I basically started the competition with no knowledge of flex or AS3.0, and had to learn as I go along, and had not previously developed a game to completion since Amos Pro on the Amiga some 13 years ago. In hindsight I should have done some warm-up projects using the platform I was targetting.

- Overambition. Using a new platform is bad enough, but trying to create something completely unfamiliar (a wireframe 3d first person tower exploration game a la the freescape games on the 8/16 bit computers of yore) while combatting the above problems was completely beyond me.

- The awful awful online Flex documentation.

- I left the decision to abandon Flex/AS3.0 for my competition entry far too late, and then tried to port stuff back to Flash8/AS2.0 and continue on the weaker but more familiar platform, with some success.

- Failing to learn from my earlier mistake, it was very late in the competition before I realised that I would have literally NOTHING to show for my effort. This led to me to a choice between the total failure of not submitting anything at all, and the poor fallback option of rushing a quick-and-nasty flash game out the door. Had I decided to abort earlier than I did and go down the route of quick-and-nasty flash game I might have been able to add more gameplay to my entry and make it better.

- Out of time - I wasn’t able to finish my entry, the plan had been to give the player several attempts to hit the castle before game over, but as I ran out of time I wasn’t able to code all the things required to reset the game back to initial settings keeping the castle at the same distance, so I forced it down the route of a browser refresh. A cheap and nasty way around it. This got the most criticism of all, and deservedly so.

- Spent too long in IRC and not enough time writing code. Enough said

I’m going to rustle up a post-LD version and will post it here in the next couple of days when I get a chance to work on it.

The good:

- I got a game released. I wasn’t really expecting to get one done, but I did.

- The gameplay. WIth GM, collison detecting/stopping you from moving in only one direction can be tough. I pulled it off though.

- The tower and key sprites. I’m not very good at computer art, and not much better and paper art, so these were pretty good sprites for me. I am thinking that making part of the key in 3d would be good, but as of now, I’m just learning to use Blender, so during the creation part, I couldn’t have done it.

The bad:

- The player sprite and the wall sprite. I could have done better with those.

-The game itself. It needed more levels and, quite obviously (:P), a game over/you win screen.

-The fact that I used GM to make it. I wanted to use SDL to make it, but I had no time.

Overall, if I added more levels, more detail and more traps, I think that it could become sort of fun.

Until next LD,

Demize

http://…/ld12/?compo_limit=57

Congratulations to all our winners, and to everyone that entered.  We look forward to seeing you next time.

The next main competition will be in December.  Date to be announced soon.

Don’t want to wait that long?

Stay tuned for Mini LD #3 in September.  Details to follow.

Thanks to everybody who rated my entry. I’m planning on making a post compo version with an easy (or maybe it should be called not as hard) mode. How should I implement it though: I’m thinking either give the guy a few hit points or having less monsters or maybe more checkpoints. Perhaps a mix? Please let me know what you think. Oh and I’ll also fix the typo in my name.

I decided with about 6 hours left to make a simple text adventure, using some of the base code from other projects I had done to make it online. To anyone who downloaded the source and wants to know what code is original to the competition, and what was reused code, well, the connect.php and Page.php were both reused from elsewhere, everything else was either modified code, or original.

Anyway, I spent about an hour getting the entire thing to work, including setting up the database that would store the game content, and the code for making a choice. Then I spent more time getting a editor set up, so I could make the game easily, by just clicking a link, filling in some text boxes, and hitting “save”. This made the game easy to make, and it only took about 2 hours to finish, polish, and put online. I still ran into a few bugs, such as the ‘reset game’ bit not working, and I added in a ‘start over’ option around the end of the competition time.

The two major problems I have with the game at this point are that it’s impossible to draw a map of level 3, due to the way some rooms loop backwards (it’d be possible if you looked at the page source for each part, and mapped things out that way, but it’d be time consuming, and might not help), and that I didn’t add in items. Adding in items would have made it possible to have puzzles that didn’t require having a maze, or going to the correct room first. Thus, it would have made branching paths and other complicated things that make a text adventure good, as opposed to just a choose your own adventure book about Schrödinger’s Cat.

As for level 3, I’m sorry if you got stuck on it. I realize that I should have put room numbers in the areas, so it’s at least possible to find your way out. The ‘good’ thing to know is that it’s still a pretty small area. There’s only 10 rooms in the entire game that consist of level 3 text, and the way out is located when you reach a room that you can go only straight, or left. Go straight.

Maybe I’ll expand on this little engine and add items, then I can make a much more complex text adventure that would actually be fun, and challenging. Who knows. Until the next LD, folks.

Click here to play, or check out the highscores here (although at the time of posting, there are none. I hope it works. )

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.

The bad

Idea and gameplay: A few hours before the theme was announced I had an idea that I wanted to do. When the theme was announced, I realized that I could fit the idea within the theme, with a few sacrifices. Focusing less on hitting the walls and more on reaching the goal led to a few problems; for example, if you miss one shot when at the end of a level, you risk going all the way down. If this happens, you might as well start over. This isn’t good, especially from a beginner’s perspective.

Difficulty: The game ended up being too hard for many. I’ve had others saying it was too easy. I suppose the difficulty curve is to steep; I also believe that the dampening function in the game wasn’t intuitive enough. A quick tutorial and a gentle difficulty curve could’ve made this more fun.

Bugs: There aren’t many bugs that I’m aware of, but there is one that is pretty nasty – going through the walls. This happens occasionally if you hit a corner. Being pretty rare I didn’t think of this as a big problem, but I think I should’ve spent more effort on fixing it.

The good

GUI: Having controls in the bottom left isn’t all that great, I should’ve made a tutorial instead. Apart from this, however, I’m pretty happy with the little details in the GUI. I should thank the testers for this, especially GBGames in the #ludumdare irc channel. Small details like turning the screen red when you’re dampening and an additional power indicator close to the cursor helped make this game at least fairly intuitive. I’m also happy with the way the minimap turned out.

Style: I’m pleased with the style of the game, and what little textures I actually made. The graphical style works nicely for me, and I believe it makes the game look at least decently polished.

Sound: The sound effects in the game are minimal, and all made with DrPetter’s SFXR. That being said, I’m happy with how they turned out. They’re not annoying, and introducing them to the game really improved the feel, giving the balls a certain “heaviness” they hadn’t had before.

Fun: Being in the contest was lots of fun. I also think my game is pretty good fun to play.

Conclusions

With a few hours to go, I was so satisfied with the game that I didn’t focus all that much on developing levels. Or anything else related to the game, for that matter. In retrospect, I should’ve spent this time designing a tutorial and perhaps a title screen and a difficulty choice, rather than chatting around on IRC (which was loads of fun, by the way).

I’m glad I entered the contest and I’m happy with the result, and I’ve had a lot of fun participating. I’m sure I’ll be back for another LD 48 in the future!

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. 

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.

Preface

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

The Bad

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.

The Good

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.

Looking Ahead

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.

Thanks Guys