next »

[Slader16]

Just found a massive bug in my entry that was causing slowdown for many people, caused by one stupid line of code! I was drawing shadows over every tile on the map instead of just the ones that were on screen, guh  

Uploaded a fixed version now though. I think that's ok in the rules, but I've left the buggy version up too just in case.

I think that you're fine to upload fix updates, at least I hope so  (because I've uploaded 3 updates so far )

Every Ludum Dare entry page shows the rules on post-compo fixes:

MY GAME CRASHES, IS UNBEATABLE, OR I MADE A TYPO: We allow you to fix crash or win condition bugs after the deadline (in a sense, like “porting” to support more players). We also allow “typo” bugs. I.e. A true that should have been a false, a word that should have been a different word, very tiny changes that you would have caught if you had more sleep. We leave this open to interpretation, but generally speaking your game should be identical to the game you submitted. No new features, just things you messed up last minute. Typos.

Whether or not you're allowed to fix it depends on the severity of the problem and the amount of code affected.

A clear example of a bug that's allowed to be fixed is a bug I had in my previous LD entry, World of Minimalism: you could make a tile solid by checking the 'solid' box, but unchecking the box didn't make the tile non-solid again. This would lead to someone inevitably making the starting tile solid (ended up happening a couple times) and players not being able to fix it, making it impossible to even move. Tiny amount of code, game-breaking effect.

An example of a bug you're not allowed to fix is the major bug in my current LD entry where you get stuck in the floor occasionally (until you jump or move in the other direction). It's very annoying, but the game is perfectly playable. It took some serious debugging to find out when exactly the bug occurs (not entirely sure about the REASON the bug occurs), and the easiest fix (which I ended up using for the post-LD version) was to write some code to check for the condition that would trigger the bug and escaping that condition (the bug only triggers exactly on the border of tiles, so I just move the player's X position by 1). (The 'proper fix' would be to just rewrite my shitty physics code.)

It took significant effort to resolve an issue that made the game less fun. I would've fixed it during LD if I had the time, but unfortunately, I didn't - shit happens, that's how LD works. My entry is judged by what I did in 48 hours, not by what I did in 48 hours and then another day for fixing stuff.

I agree with everything you said, especially the last sentence. 

[Pineapple]

Hey everyone pay attention to my post-compo development

http://forums.tigsource.com/index.php?topic=35589.0

[Erik Schröder]

Here's my and Skomakar'n's entry - Stache Of Glory 2: Shavin' Through Dimensions.

I think it's pretty alright, although we totally forgot to tell people you could wall-jump in the game. Also, the yellow zones are safe zones, so stay in those before the time runs out.

I wrote the music and created some tiles and that sweet logo, Skomakar'n co-programmed it (along with a friend of ours, Carl) and created some graphics as well. Character and item sprites were created by another dear friend of ours, Mehdi.

[Slader16]

I just uploaded a Mac and Linux port for my game:
http://www.ludumdare.com/compo/ludum-dare-27/?action=preview&uid=26474

[Raiyumi]

Just found a massive bug in my entry that was causing slowdown for many people, caused by one stupid line of code! I was drawing shadows over every tile on the map instead of just the ones that were on screen, guh  

Uploaded a fixed version now though. I think that's ok in the rules, but I've left the buggy version up too just in case.

I think that you're fine to upload fix updates, at least I hope so  (because I've uploaded 3 updates so far )

Every Ludum Dare entry page shows the rules on post-compo fixes:

MY GAME CRASHES, IS UNBEATABLE, OR I MADE A TYPO: We allow you to fix crash or win condition bugs after the deadline (in a sense, like “porting” to support more players). We also allow “typo” bugs. I.e. A true that should have been a false, a word that should have been a different word, very tiny changes that you would have caught if you had more sleep. We leave this open to interpretation, but generally speaking your game should be identical to the game you submitted. No new features, just things you messed up last minute. Typos.

Whether or not you're allowed to fix it depends on the severity of the problem and the amount of code affected.

A clear example of a bug that's allowed to be fixed is a bug I had in my previous LD entry, World of Minimalism: you could make a tile solid by checking the 'solid' box, but unchecking the box didn't make the tile non-solid again. This would lead to someone inevitably making the starting tile solid (ended up happening a couple times) and players not being able to fix it, making it impossible to even move. Tiny amount of code, game-breaking effect.

An example of a bug you're not allowed to fix is the major bug in my current LD entry where you get stuck in the floor occasionally (until you jump or move in the other direction). It's very annoying, but the game is perfectly playable. It took some serious debugging to find out when exactly the bug occurs (not entirely sure about the REASON the bug occurs), and the easiest fix (which I ended up using for the post-LD version) was to write some code to check for the condition that would trigger the bug and escaping that condition (the bug only triggers exactly on the border of tiles, so I just move the player's X position by 1). (The 'proper fix' would be to just rewrite my shitty physics code.)

It took significant effort to resolve an issue that made the game less fun. I would've fixed it during LD if I had the time, but unfortunately, I didn't - shit happens, that's how LD works. My entry is judged by what I did in 48 hours, not by what I did in 48 hours and then another day for fixing stuff.

Oh man! I think I have to revert back my files then. I did an update just to make the game less "impossible" for most players by moving the camera view down so they see where they're landing in 1 section. Will that be fine?

Unfortunately, I'm not on my main comp atm.

EDIT: Reverted back to previous version. But I'd still like to know if this is an acceptable change. Much appreciated! 

[dlan]

made this game :

http://www.ludumdare.com/compo/ludum-dare-27/?action=preview&uid=11151

we spent most of the jam implementing the mechanics, so there is not much content here, and the
enemies speed is probably too fast  still, we got the arcade feeling that we wanted.

[Slader16]

Just found a massive bug in my entry that was causing slowdown for many people, caused by one stupid line of code! I was drawing shadows over every tile on the map instead of just the ones that were on screen, guh  

Uploaded a fixed version now though. I think that's ok in the rules, but I've left the buggy version up too just in case.

I think that you're fine to upload fix updates, at least I hope so  (because I've uploaded 3 updates so far )

Every Ludum Dare entry page shows the rules on post-compo fixes:

MY GAME CRASHES, IS UNBEATABLE, OR I MADE A TYPO: We allow you to fix crash or win condition bugs after the deadline (in a sense, like “porting” to support more players). We also allow “typo” bugs. I.e. A true that should have been a false, a word that should have been a different word, very tiny changes that you would have caught if you had more sleep. We leave this open to interpretation, but generally speaking your game should be identical to the game you submitted. No new features, just things you messed up last minute. Typos.

Whether or not you're allowed to fix it depends on the severity of the problem and the amount of code affected.

A clear example of a bug that's allowed to be fixed is a bug I had in my previous LD entry, World of Minimalism: you could make a tile solid by checking the 'solid' box, but unchecking the box didn't make the tile non-solid again. This would lead to someone inevitably making the starting tile solid (ended up happening a couple times) and players not being able to fix it, making it impossible to even move. Tiny amount of code, game-breaking effect.

An example of a bug you're not allowed to fix is the major bug in my current LD entry where you get stuck in the floor occasionally (until you jump or move in the other direction). It's very annoying, but the game is perfectly playable. It took some serious debugging to find out when exactly the bug occurs (not entirely sure about the REASON the bug occurs), and the easiest fix (which I ended up using for the post-LD version) was to write some code to check for the condition that would trigger the bug and escaping that condition (the bug only triggers exactly on the border of tiles, so I just move the player's X position by 1). (The 'proper fix' would be to just rewrite my shitty physics code.)

It took significant effort to resolve an issue that made the game less fun. I would've fixed it during LD if I had the time, but unfortunately, I didn't - shit happens, that's how LD works. My entry is judged by what I did in 48 hours, not by what I did in 48 hours and then another day for fixing stuff.

Oh man! I think I have to revert back my files then. I did an update just to make the game less "impossible" for most players by moving the camera view down so they see where they're landing in 1 section. Will that be fine?

Unfortunately, I'm not on my main comp atm.

EDIT: Reverted back to previous version. But I'd still like to know if this is an acceptable change. Much appreciated! 

I also have a problem with collision that I need to fix, but I don't really know if that counts as a bug.

[paulmcgg]

Here's mine: http://www.ludumdare.com/compo/ludum-dare-27/?action=preview&uid=21390



Happy with the style of it, but the gameplay idea didn't pan out as well as I would have liked. This time I was adamant I was going to do something not mechanics heavy but ahhh got talked into it again. xD

[ekun]

Just made a video about Chronodrive's level editor!

[wccrawford]

I would actually prefer having a stricter delimitation of 48h vs. Jam. With Jam being for teams and 48h being the single developer one you can't compare them in fairness.

They already keep them separate.  Every entry you rate says whether it was Jam or not.  And the ratings, too.  And the ratings are kept separately and listed separately at the end.

The only thing more you could do would be to actually make 2 separate sites for them, and I really don't see a need for that.

In addition, in the past, the best Compo games have rivaled the best Jam games.  This time seems to be different, but that could be because of the theme...  Or maybe it just attracted stronger teams finally.

[Impmaster]

Yo guys, someone played my game on Twitch.





I'm so proud of myself.  

Too bad she only has 7 followers though... 

[JobLeonard]

"It's loads of fun, even if you suck at it."

That's a pretty awesome seal of approval.

[cirpons]

Made a quick'n'hackish cga graphics snake clone:
Minty Snak3
I think I could make some post compo development, starting with a good cleanup.

[VDZ]

Oh man! I think I have to revert back my files then. I did an update just to make the game less "impossible" for most players by moving the camera view down so they see where they're landing in 1 section. Will that be fine?

Unfortunately, I'm not on my main comp atm.

EDIT: Reverted back to previous version. But I'd still like to know if this is an acceptable change. Much appreciated! 

I must stress that I'm not some kind of LD judge or anything, just a normal participant who's been doing LDs for some time. If you want to really be sure, the IRC is generally a better place to ask; there's people involved with running LD in there as well, in case you really need to get an official decision.

Anyways, unless my interpretation of the rules is wrong, balance fixes (genuinely improving the game, not even fixing actual bugs) are among the things the rules exactly try to prevent. If it's literally impossible, you can fix it, but if you didn't have the time to balance everything out to make it more fun, then that's just something you should've reserved more time for during the actual compo. Post-compo edits are for fixing a broken game, not for improving a functional game.

[Raiyumi]

Thanks! I'll check it out.

I'll keep it to fixing game-breaking bugs. I'm quite new to how LD works.

[Geti]

You can upload explicitly post compo versions alongside your compo version. It's not that big a deal, just keep the actual compo version around for people to rate and post on the blog about post compo changes.

[LD Smith]

My entry is Bomb Squad, a game where you have to disable the bombs by cutting the wire associated with the bomb's color.  Each bomb is set to go off in ten seconds, and the overall objective is to achieve a low property damage value.

http://www.ludumdare.com/compo/ludum-dare-27/?action=preview&uid=19778

[Mr Speaker]

My first time to take part in Ludum Dare. I made a very simple game about a master car thief, 'Gone in 10 Seconds.' Thanks to Nicolas Cage for all his spiritual guidance on this one.

http://www.ludumdare.com/compo/ludum-dare-27/?action=preview&uid=21166

This was my favourite entry (out of the 100+ I've played). The style (graphics and overall aesthetics) was so "Commodore 64" - I had massive grin on my face the whole time I was playing it.

[Panurge]

I'm really flattered to hear that, particularly because your game (Time Flies Straight for anyone who hasn't yet played it) was mind-bendingly good. I have a hunch and a hope that it should do well when the results come in.

[JobLeonard]

Time Flies Straight is my top pick as well.