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.

Tags: flash, OOP, post-mortem, postmortem, tower, tower defence

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. 

Tags: ld48_12, postmortem, tower

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.

Tags: postmortem

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.

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!

Tags: LD #12 - The Tower - 2008, postmortem

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. ;))

Tags: breaking the tower, update

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

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.

Tags: postmortem

Alright, so I’m at that point in my life where I’m cooking my own meals. Problem is I have no idea what to cook and not much experience. I’ve been experimenting but I’d like to expand things faster. So here’s the game, I list all the foods I currently have access to and you name something non-simple that I can cook. General instructions appreciated. Preferably, something I can cook in 25 minutes in the morning, toss in a sandwich bag or some cellophane and eat it at school.

Foods after the jump.

In no particular order:

Broccoli, bell peppers, tomatoes, corn, mushrooms, zuchinni, carrots, eggs, potatoes, spelt bread, pita bread, tortilla/wrap bread, lettuce, chicken, various pastas, pasta sauce, granola, olive oil, salad dressing(maybe), Provalone and monteray jack cheese, goat’s milk (seriously, think of it as really whole milk), orange juice, frozen shrimp, various spices, rice, oatmeal, peaches, and white onions. And probably some more I can’t think of right now.

Please nothing involving a microwave. Preferably something I can cook in a frying pan or casserole. Thanks.

Tags: food

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!

Tags: help

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.

If you can’t get enough of Ludum Dare, then get ready for Mini LD #3 coming up next Friday (September 5th).

This one is hosted by myself.  Hosts get the privilege to do some pretty wacky changes to the norm, which I’ll be  abusing on several fronts.  The first, you’ll be getting your theme extra early.

Theme announcement, Monday September 1st.

In IRC, I’ve been hyping this one as a “very different” theme.  One that I think really suits a few extra days to think about.  Then we convene as usual on the Friday, and make it happen.

Stay tuned.

I’d also like to encourage any LD veterans to consider signing up to host a Mini LD Compo.  It’s pretty straight forward.  Sign up, show up, announce a theme, and write a few posts to round out the whole thing.  Your usual #ludumdare administration will be glad to help.  To learn more, see the Wiki.

http://www.ludumdare.com/wiki/mini-rules

And to sign up, see the Wiki.

http://www.ludumdare.com/wiki/mini-host

We’re still looking for someone to step up and take October.  Got a great theme that hasn’t done well in theme voting?  Here’s your chance.

See ya next week.

– Mike Kasprzak (PoV)

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. 😛

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

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)

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.

Tags: LD12 - The Tower, postmortem

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

Get it here.

Tags: LD #12 - The Tower - 2008, post-compo

Well, this is kind-of compo related, as I’m devoloping my library thing the wiki says I can have. I keep getting these warnings when compiling:

1>c:\program files\microsoft visual studio 8\vc\include\xlocnum(590) : warning C4312:
‘type cast’ : conversion from ‘uintptr_t’ to ‘void *’ of greater size
1> c:\program files\microsoft visual studio 8\vc\include\xlocnum(566) : while
compiling class template member function ‘std::istreambuf_iterator<_Elem,_Traits>
std::num_get<_Elem,_InIt>::do_get(_InIt,_InIt,std::ios_base &,std::ios_base::iostate
&,void *&) const’
1> with
1> [
1> _Elem=char,
1> _Traits=std::char_traits,
1> _InIt=std::istreambuf_iterator>
1> ]
1> c:\program files\microsoft visual studio 8\vc\include\xlocnum(1367) : see
reference to class template instantiation ‘std::num_get<_Elem,_InIt>’ being compiled
1> with
1> [
1> _Elem=char,
1> _InIt=std::istreambuf_iterator>
1> ]
1>c:\program files\microsoft visual studio 8\vc\include\xlocnum(590) : warning C4312:
‘type cast’ : conversion from ‘uintptr_t’ to ‘void *’ of greater size
1> c:\program files\microsoft visual studio 8\vc\include\xlocnum(566) : while
compiling class template member function ‘std::istreambuf_iterator<_Elem,_Traits>
std::num_get<_Elem,_InIt>::do_get(_InIt,_InIt,std::ios_base &,std::ios_base::iostate
&,void *&) const’
1> with
1> [
1> _Elem=wchar_t,
1> _Traits=std::char_traits,
1> _InIt=std::istreambuf_iterator>
1> ]
1> c:\program files\microsoft visual studio 8\vc\include\xlocnum(1373) : see
reference to class template instantiation ‘std::num_get<_Elem,_InIt>’ being compiled
1> with
1> [
1> _Elem=wchar_t,
1> _InIt=std::istreambuf_iterator>
1> ]

Anyone know what’s going on, or how to fix it? I’m using SDL and VC++ 2005 Express.

And also, anyone know an easy way to keep <pre> tags inside the column thing? I had to find where it went over and make my own line breaks… And I don’t know if it’ll still look right if you have a different screen resolution. Thanks in advance!

EDIT: Aiee! I give up… I’ll just use some other type of formatting…

Tags: compiler warnings, help, SDL, VC++

Here it is.  Bright and early Monday morning, the theme for Mini LD 3 is:

Tool

You’re welcome to take our regular open interpretive approach to themes, but I’d like you to hear me out first.

There are a ridiculous number of possibilities for this theme, but I’d like to focus on one.

Think back to Ludum Dare 12, or any compo prior that you’ve entered.  In making or planning your game, what “something” would have saved you hours of work, or allowed you to do that wilder game idea of yours?

That’s what you’re making this weekend.

Now because this is a Mini LD, you’re not required to share your source.  You’re welcome to collaborate with someone, and are encouraged discuss with others in IRC.  And to shake things up, I’ll throw in the added note that you’re not even required to share your tool.  You’re encouraged to, but if you’ve got some proprietary tool that you’ve been meaning to make, this weekend is looking pretty good.

What I want from you though, is to talk about it on the blog.  Your file format thought process; User interface considerations; What problem you’re solving; How much you hate mappy; And so on.

Tool development is a secret art of game development.  Not that it’s particularly difficult, just we don’t really talk about it.  That’s my goal with this Mini LD.  To get some genuine discussion out there for arguably one of the most important secrets of game development.

And hey, if we get ourselves another sfxr in the process, that’d rock too.

So take the week.  As much or as little time as you need, and think about what you’d like to make.  What problems you’ll need to solve, any preparations you’ll need to make, and so on.  Then join us this weekend and make it happen.

Since this is a Mini LD, and the theme is known early, I doubt I can control the start time, or random bursts of inspiration.  You’re encouraged to schedule your work for a convenient start time the weekend.  However, if preparations go too well, tell us all about it

I’ll be collecting and posting a summary of this week and weekends events on the Monday.  Please let me know in your posts what you’re actually making, and that you did (or didn’t) finish.

Not sure what to do?  Here are some suggestions:

• Map Editor (Tiles, Elements, Polygons)
• Data Editor (Numeric Data, Points and Polygons)
• Menu Editor
• Animation/Particle Effect Editor
• Font Editor/Builder
• Sound Effect Maker, VST Instrument (if sfxr isn’t enough)
• A File Format (with loader and saver)
• A wrapper library, or generalized interface for several libraries (compression, image files, etc)
• A process for managing content (graphics, audio, maps, dialog/text/localization, etc)
• Write an article
• Crash course yourself in a topic (physics, trees, sound synthesis, a programming language, etc)
• Ask the chat room (#ludumdare on irc.afternet.org)

Bottom line, pick something to either benefit you, or benefit the community.  Good luck.

– Mike Kasprzak (PoV)

My first miniLD, and such a great idea from PoV.LD’s max my productivity, so this mean i will have a tool that i need created very fast.

I’m curently jugling the idea of a “Cave story” side scroler. For this i need a tile level editor. And allthough it will be made for a side scroler, it could be usefull for any kind of tile based level. Ill se how far i get with it over the weekend.

Since i have been working on this project allready, some of the stuff will be premade, but i hope it won’t brake the spirit of the competition. I allready have the file format somewhat done, and im was already doing the ingame loading part, and i do want to finish that befre the compo, im not going to just drop it all and let it sit for a few days.

I will however do a lot of the interface stuff myself, thats just how i am. I will use a partialy created library from me, that will covers messeges to GUI objects (i will post the source before i start). The objects don’t realy exists yet (just the container object),  so that will probaly be the main thing.

As for the levels, the idea is, to make a tile world, build from particular levels.  And when you move from one level to the next, it’s neighbour load into the world, without loading screens.

Let give the thing codename  TLM for now. Maybe add an x or z when i’m done. 😀

PS: I created a tile picture thingy, and before saving it in jgp i played a bit with the settings. From a crips, clear, few color picture, i got that monster, but i thoght it was more amusing than the plain tile thing.

Tags: precompo, tile level maker, TLM

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:

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.

I’ve been thinking about Mini-LD #3. I’ve decided I want to make one of these:

• A C++ wrapper library around an older C library,
• An editor/loader/file format for data in Chipmunk, a physics library
• An editor for a game with a concept of levels but no level editor (or at least finished)

I’ve started already on one of the first one – a set of classes to simplify interaction with the SDL graphics library.

The last one I’ve made before – and for a Ludum Dare entry! The Castle Smash Map Editor has a thread at the Hamumu Forums, but all the download links there are invalid. I don’t have a real website to put it on, so unless you people have any ideas, you can download it from MediaFire here. The zip actually includes Castle Smash, because that’s just the way I did things.

I think, given the current state of things, that I will go for the second choice. Good luck to everyone else who participates, and have fun!

Tags: castle smash, castle smash map editor, final, mini-ld 3

…before the event even started! Hacked together a 2D Vector class in python so I won’t have to worry about the license and bloat in other libraries. Yay.

You guys are free to use it in any way you like, you might want to mention me in the credits for making an awesome, easy-to-use vector class but that’s completely optional. 😀

Feel free to look at it and laugh at my mediocre python skills.

SOURCE: Vector.py

Update: I also made a nice build script that packages my source directories into a zip, but that one’s not for sharing, bwahahahaa! (It’s custom-made so I think you’d make your own faster than actually trying to modify mine to work with your projects.. :P)