I have to be honest, I mostly didn’t participate in the last LD because I wasn’t a huge fan of the theme. I know, I suck, but it’s the past now…

….. But now, to make up for my laziness, I am bringing the past back!

Starting this Friday, I’m having a Quarter Quell (#HungerGamesReference). For a week, I will make a game based on one of the 25 first topics, and it would be cool if you guys joined me in this effort! If not, it’s cool lol.

You can pick any topic (or topics) from the random list below. I went to www.random.org/sequences/ and randomly selected 10 out of the 25 numbers:

So the topics are:

Advancing Wall of Doom
Swarms
Build the level you play
Evolution
Preparation — Set it up, let it go
It’s dangerous to go alone! Take this!
The Tower
Infection
Growth … <– “Grow”, also this May’s optional theme for One Game A Month
Roads

I think standard LD rules should apply, minus the week to do it. I plan to do this alone, but you can be in a team if you so desire. If you want to participate, post in the comments of this post your intent to do so… and share your finish products when you’re done!

If any of you decide to participate with me, let’s see what awesomeness we can create!

It’s only 1 AM, but having never programmed a basic platformer before, my meager attempt to get jumping has failed miserably for the past 2 hours or so. I should probably finalize an idea first. All of them are probably unoriginal, though I have a few scenarios I think are interesting. I think that’s what I’ll do. I keep of thinking of ideas and then settle on making the game on the most interesting one, not necessarily the one I think I can get done on time. How else am I supposed to improve if I don’t push myself? For, now, G’night!

Towlr and friends were last seen on Destructoid.

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

Several minds were destroyed that day.

PC Gamer (US) recently did a feature titled “50 games to play at work”.

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!

My LD12 entry, Cat Stacker, has grown up and now features assorted fruit. Also, instead of the original tetrisy controls, you can click and drag the current piece around with no time pressure (press A and D to rotate). There are 20 levels and it get’s pretty tough. Good luck! (^ _ ^)/

Cat Cat Watermelon

I will just apologize in advance, as the next level may shock and dismay..

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

Well, it seems I almost have a fully functional “game”.

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 .

Thanks to everyone who played my LD12 entry, Mr Blocker. As a number of people observed (myself included), it’s not much fun. Partly this was because I was very limited on time, so I deliberately chose a very simple concept so that I could finish in time.

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:

(more…)

I made a post compo version, fixing the typo in my name and adding an easy mode.

Get it here.

I too was waiting until after seeing the final results before I would post my post-mortem.

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) (more…)

Quite literally, postMORTEM. ANyway, after reading the comments, seeing my ratings and my own opionins, I’m ready to do this. Maybe next time I’ll write this during the compo, but I only decided to do it now.

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

The voting for Ludum Dare 12 has finally ended.  You can view the final results here:

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.

Yay, I finished rating everything I could. Just in time too! Lots of cool games, I have to think of a few trophies to award soon. Unfortunately I wasn’t able to run 9 of the games.

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 program games and stuff so I thought I would register on this site, but how do I judge? I can’t find the button. Thanks!

Post mortem, thoughts on things, etc. This post is mostly just going to be me rambling about my game, and this particular Ludum Dare. Basically, I didn’t really like the theme. Sure, it’s not a bad theme, really, but I couldn’t think of anything original to do. My ideas pretty much went from “Climb the Tower” to “Tower Defense” to “Build a Tower”, and back. Honestly, both styles of games would be pretty cliche, and I didn’t really want to do that. I figured there’d be plenty of other games with these basic rules, and I was right. That said, there were plenty of awesome and inventive games made too, and games that took these ideas and turned them on their head. Congratulations to everyone who submitted a fully fleshed out game, and good job to those who worked all weekend. I am not one of those people. (Rest of this, plus solution to level 3 after the more.. link

(more…)

Hi, all! I’ve made a small post-LD12 fix of Breaking the Tower, and I’ve included a high score list.

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

My 2nd Ludum Dare didn’t go as well as my first. While I managed to get Tower Defender submitted, it can’t be called a game so much as a tech demo.

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.

(more…)

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.