The final tweaks are done… Still some weird things going on but enjoy and comment !

Congrats to the team !

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

Hey, turns out, the first level of my game is unsolvable.

Bummer.

It’s true, though. I ran it through an 8 puzzle solver and found out there was no solution. I just made one typo, apparently, that broke the entire thing apart.

If I could, I would fix it, but it’s too late for that. Basically, the game can not be beaten in it’s current state. I apologize for wasting anyone’s time (although not many people have played it, anyway.) It’s ridiculous that just mixing up two numbers in an array can cause this. I could plead for a special competition exemption to fix it, but I don’t see the point. So, go check out my game, and face off with the odds (0:1) by trying to beat it! I mean, hey, Chuck Norris can! http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=11003

P.s. If anyone right now is thinking about giving me an “Epic Fail” award for this, you have my approval.

dot is a top-down 2d space game in which you control a tiny planet with a volcano during his quest to find his parents.

The style was inspired by simply rendered storybooks and the gameplay was influenced by Osmos and the early Asteroids games.

Play and rate dot.

What worked well:

Working Solo

This is the first game jam I’ve done where I did everything solo. This worked really well for me because it allowed me to settle on an idea very early on – during the other two jams I participated in, we spent multiple hours agonizing over interpretations of the theme and possible mechanics. As I have realized, deciding these things as soon as possible in the process is paramount to creating a finished entry. In prior jams, I had never worked with the people with whom I participated before, and that was extremely limiting because it meant that we didn’t know each other’s strengths and weaknesses, nor our collective familiarity with the tools we were using. In both cases, I started doing artwork and ended up as one of the lead programmers. Since I knew I would have to do everything this time around, I was able to scope my work really well.

Refining Assets & Keeping the Art Simple

Unlike in my previous jams, I started out with art assets I made in Inkscape in just a few minutes and focused my initial effort on creating a functional movement system. In the past, I focused too much effort on making pretty 3d models and rendering them out to sprite sheets. You can’t really make a good game if you spend all of your time on pretty pictures. When I finally did start to work on more polished graphics, I avoided 3d modeling and made black and white 2d line drawings in Photoshop. If I participate in a group jam in the future as an artist, I’ll make sure that the programmers are sufficiently familiar with the game frameworks we are using that I don’t need to take an active role in coding in order to get a playable game.

Working in a Publicly Accessible Area

I worked on dot in a lounge at my school, which made it really easy to convince passers-by to playtest the game incrementally as I was developing it. I got a significant amount of really helpful feedback from their comments and from watching them play my game, which helped me refine the control system a great deal. For example, the indicator that tells dot where his goal is used to consist of faded black circles on the corners of the screen, and the people who tried it out attempted to avoid them; they thought that they were being chased by dangerous obstacles. Doing this also gave me validation for the game when I was starting to wonder whether it counted as “fun” – one player desperately retried my nigh-impossible asset test level dozens of times despite getting frustrated and kept coming back to check on my progress.

Perhaps most importantly, though, it made sure that I actually got the game to work properly – I was in danger of wallowing in minor details near the end of the first day, and one of my repeat visitors told me to stop messing around and focus on the core gameplay.

Using Unity

I have mixed feelings about using Unity to develop games because of its lack of true Linux support and its nature as a closed source development environment with expensive add-on licenses for features that could be accomplished very easily (and for free) in other systems. However, Unity is incredibly easy to use, it has an excellent component system, and I was able to deploy to the web and Mac OS X/Windows with the click of a button. During Ludum Dare 22, we spent about 2 hours generating a working Windows .exe and ran out of the time we needed to generate more than long-winded source compilation instructions for other platforms.

Using github with gh-pages

Being able to generate new test builds every few hours and post them to the web with only a few lines of html in Vim was possibly the greatest boon ever. We didn’t use any version control during my first game jam, and that gave us a lot of headaches that we could have easily avoided.

Updating my Journal & Making a Livestream

I didn’t do this during any of my prior jams because I thought it would be wasting valuable time, but I think it really paid off this time around by keeping me on track in the game development process. My livestream solution was incredibly hackish, though, and I would like to know how the other mac developers handled this. Just before the competition, I spent four hours writing a convoluted sequence of shell-scripts to get an old version of VLC to stream a sequence of images to twitch.tv, which ended up taking up most of my CPU power. I scrapped that and moved to a piece of javascript that one of my friends wrote, which allowed me to display images once every 30 seconds or so as they were updated on Dropbox. Dropbox banned me from public links for 3 days because of excessive traffic, and my friend made a strange php upload script for me that allowed me to update much more frequently, but still with a really ugly system that involved using my ability to host things on my school’s servers.

Getting Sleep

I barely slept during my past jams, and I think that might have been part of the reason that I never finished something to the degree that I did this time around. Sleep is important.

I still feel somewhat like a zombie now that the competition is over, but at least I was able to think clearly while I was doing things. If I were to change the way I did things, though, I think I would have gone to sleep earlier and gotten up earlier as well – 6:00AM and 5:00Am seem a bit late to be going to sleep while needing to be productive for multiple days in a row.

What didn’t:

Level Design

I didn’t leave myself enough time for level design and ended up making only three levels, of which the third is very poorly designed because it can cause you to win accidentally.

Music/SFX

While I did end up creating music for dot, I have absolutely no musical background and ended up repeating a sequence of four notes I haphazardly stumbled upon in GarageBand after humming something that I thought might sound interesting. I also didn’t have time to do any sound effects aside from some voiceover that I recorded in Audacity using my laptop’s built-in mic. I really need to find a better mic next time. However, I am still rather proud of the fact that no one who played the game complained about my unpolished audio and very few people realized that the voice was me. Apparently I’m just a really good voice actor?

Level Transitions

This is the largest contributing factor to wasted time during the entire competition. Making level fades properly in Unity is really challenging because of the component-based system forcing complex object interactions. When a fade starts, I needed the character to stop moving and the next level to start loading once the fade was complete. Ideally, the next level would start loading while a fade happens on top of a still image of the current screen. I’m pretty sure that the indie version of Unity doesn’t support that behavior, and I don’t really want to get attached Unity pro if I can only get a demo version. If I ever end up making a game good enough to fund my purchasing a Unity Pro license, maybe I’ll look into doing this better.

Anyway, I am still pretty unhappy with the fades between levels and worked on them instead of making more (and better) levels, which was pretty silly of me.

End Game/Story

The end of the game is pretty unrefined/confusing, and I wanted to tell a much longer story through animated cutscenes between the levels. If there is enough interest in seeing those things (give me some comments and feedback!), I’ll look into expanding dot for Kongregate during the summer.

Overall Impression:

I’m really happy that I actually made a (sort of) complete game this weekend, and I’m satisfied with the core game mechanic. I feel like I learned a lot about Unity and game design in general during the past few days, and I’m definitely going to try to compete in LD24.

Going off on a bit of a tangent, I thought it was really surprising that some people who play dot get lost in space for up to 15 minutes while others play through the entire game in under 2. Hmm…

Congratulations if you read all of that. Remember, you can play and rate dot here.

The Two of Us – Play Here

Check out Incredible Ape’s Jam entry, Lililput:

Lililput

It’s abuot spleling.

Just got a timelapse capture of Toad Warrior up. First Ludum Dare, and I’m very proud of my effort!

Play/rate here.  I hope you enjoy playing the game as much as I’ve enjoyed making it.

I know how you feel, Rodriquez.

Well, it took me 24 hours longer than I expected, but my game ONLY DUST is done (ish). Play it here:

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

Now, time for sleep. Stay tuned for some kind of post-mortem-thingy.

Prepare to extract some oil.

Well those were some stressfull hours,it was our first time participation but it was a great experience.

I’m really sad of not being able to do everything we wanted especialy not being able to finish what we had,i just keep thinking if only i had 2 more hours…

A main gameplay aspect was not done so i’m not even sure if what was done can be called a game but i hope someone enjoys what we were able to achieve.

TimeLapse: http://www.youtube.com/watch?v=kxQDyMAWqKs

Kind of a guide / playthru.

KITTEN ALERT

play it!

I’ve written an extensive 3-part postmortem on my web site, narrating my thought process as I worked through the weekend on my compo project, and describing in detail some of my programming techniques (no code, download my source to see that).

Here’s the uber brief synopsis:

What went well:

1. Really liked the bacteria behavior.
2. Good use of translucent graphics.
3. Very happy with the effects I achieved using stochastic functions.
4. The controls ended up working out pretty well — this was the first time I’d done a game where the controls are so indirect, and you control hundreds of objects.
5. Performance is good despite having a few thousand objects in play.
6. <3 Game Maker for rapid development

What went wrong:

1. Didn’t get to complete all the features I’d planned.
2. Spent a lot more time debugging and tweaking the controls than I ever imagined I would need to.
3. Game is short.  <1min/play is pretty typical.
4. Could be more depth to it, if I’d made it a little more complex by including some of the features I’d hoped to complete.
5. h8 Game Maker for debugging.

What I’d like you to know:

1. This is the second weekend in a row that I built a game!  I’m taking a break next weekend:)
2. I’m really happy that I participated and completed my project.
3. I am looking forward to doing more of these.
4. Can’t wait to see people’s comments, find out how I ranked, and try other people’s games out!

Tags: Bactarium, Chris Sanyk, postmortem

Nooo! It appears that I missed the deadline on submission. We haven’t even worked on it since around 8:30 yesterday. Here is our submission anyways! 1 programmer, and 1 artist. It’s a co-op game, but you can play locally. P1: WASD to move, E to swap acorn, Spacebar to attack. P2: Arrows to move, Right Shift to swap acorn, Right Ctrl to attack.

http://dl.dropbox.com/u/4370089/Nutbuddies/WebPlayer/WebPlayer.html

This was my first LD and pretty well the first game I’ve ever made from the ground up. I finished with about 3 hours left and I was very impressed with the results! 😀

What Went Right

I was very surprised by how fast I came up with the premise for my game and by the speed I created my assets. I was also very impressed that I had little bugs or errors during the development for my game! 😀

What Went Wrong

When testing a game, ALWAYS USE A DEBUGGER! There was one really bad bug in my game, and it seemed like I could never get the bug to occur in the debugger but I could always get it to happen when running outside the debugger. I also think I took the event much too casually, and that let little time to add more content into my game.

What I Thought

I LOVED IT!!!! There is no better way to express it! The 48 hours development time is great motivation! Getting constructive criticism from the community is also great! I very well plan to enter then next LD, because the thrill from this one was just fascinating!

You can check out my game here, and if you play, please tell me what you thought! Also all constructive criticism is very much welcome 😀

Well, even working up to the final minutes, I wasn’t able to get enough game into my…uh…game.  The control mechanics and getting the scene put together with all of the UI elements ended up being more complicated than I expected.  I’m happy with the way the game feels at this point, though, so I’m looking forward to adding in the combat to see how the full arc of the game feels.  Here’s a screenshot of the final state as of the jam ending:

You can play what I ended up with by the jam deadline here.  Since there wasn’t any time for any real tutorial or documentation, some instructions:

– Drag the mothership to move around.  The mothership is the online thing under your direct control.
– Clicking on the buttons on the lefthand side of the screen produces a new computer-controlled minion.
– Minions will stay near the green waypoint (the little green icon that starts on your mothership).
– The waypoint (and thus, your minions) will stay with your mothership unless you place it somewhere by clicking within the green circle representing your area of control.
– If you move too far from your waypoint and it leaves your area of control, it will return to your mothership.

Things That Didn’t Make It

– There’s no AI.  That big purple mothership?  It’s just sitting up there.  It should be chasing you, pumping out it’s own minions to hunt you down.
– Speaking of that, there’s not combat.  All those health bars and nothing to do with them.
– There’s no cost to making a new minion – the intension was to have a cooldown cost for each ship type, as well as a materials cost.
– With combat working, I was hoping to have each destroyed minion leave behind wreckage that could be reclaimed by a non-combat gatherer minion.
– Sound effects, menus, and any other polish stuff.  I never get to these, though, so I almost forgot to add them here.  I really need to learn to pump out a couple of basic sounds and a simple background loop right at the beginning so these don’t get left behind.

The Future

Without a game to actually play in here, I don’t know if the thing is any real fun if you actually had human or computer enemies.  My immediate plans are to hit the points above that would turn it into an actual game.  After that, I think I’d like to give the whole thing a less-abstract coat of paint and play with some different art styles.  I’d also like to see the thing running on an iPad or iPhone, since all the interaction maps well to touch.  From there, I’m not sure – should it be some sort of arena-based competitive thing?  Should it grow into a more open, exploration-based single-player experience?  Assuming interacting with the game proves enjoyable, I’d like to explore some of these possibilities.

Tags: gamejams, ld23

Challenge met!
We posted our game right on the deadline!
Everything is not perfect but we’re pretty happy with the result.
Thank you Ludum Dare for this unforgettable experience!

Feel free to comment our project: Ayond

Aw, yeah. Wunderworld was finished in time.

It’s more of a tool than a game, because you can build your own dungeon with it. Put a sword and some enemies in it and you can fight. Place a goal, and it’s winnable. Unfortunately it lacks some premade levels, so I made a trailer to show the features and work-/play-flow:

It’s inspired by Ultima Underworld, thus the name (I even wanted to name it “Wultima’s Wunderworld”, but I just couldn’t justify the “Wultima”, as you don’t play a character).

I recommend the standalone version (Windows). The Mac version has Mouse controls too sensitive, so I’ll hae an update ready in some days. And the webplayer version works, too, but it doesn’t save your levels as a textfile, unlike the standalone, so you can’t trade them with others.

Please play and rate Wunderworld!

Tags: finished, gameplay, level tool, trailer, wunderworld

With 6 minutes left on the Submission Hour counter, Tyler and I finished our game, World of Destruction!

The actual mechanics of our game are quite fun, and it’s hard not to keep your own head from ducking while in a firefight with an enemy tank.

As we were both first time LD’ers (and completing our first real game), we learned quite a few things. Most importantly, never spend too much time on trivial things. If there’s a better/faster way to do something, go for it. I can admit we spent too much time on actually creating the game lobby and not as much time on the game itself as we should have, but all is done. Another thing we learned is to keep your ideas small. Our initial plans for having 3×3 map worlds would’ve taken way too much time to create, so in the end we settled for a map that’s 72×48.

I’ve got my timelapse encoding right now, so expect that later!

– PROWNE

—————————————————

My first real game ever completed and my first LD.

The feeling is surreal to be apart of this and to call myself a developer. I’ve always looked up to them and dreamed of being one, but now I can proudly call myself one!

Even though I did no real coding and only artwork/map creation it was still so much fun. Being apart of the process was the best thing ever.
I can’t wait to keep on going and improving my skills.

I want to thank everyone from LD for everything they have done! Thank you for the opportunity to compete!

-TLitten

Tags: as3, flash, postmortem

So, I did not complete anything for this Ludum Dare.  Maybe next time.

What Went Wrong

• Could not come up with a good idea for the theme
• Sick with a persistent headache all weekend
• Debugging quirks in Unity took longer than expected

What Went Right

• I liked what I made
• The character controls feel good
• The animation is kind of nice
• I think it could have been kind of fun if I had a few more days

Play The Unfinished, Unsubmitted “Game” Here

Tags: fail, ld23, pirate, unfinished, unsubmitted

I dare you to beat the Sun.

It isn’t impossible, I can guarantee, but you really need to be an asian level gamer.

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

Go on, get on it!

Tags: 72h, jam, LD #23, Make A Game, Overpopulous

Hey all, still haven’t written my postmortem yet.  Instead, I worked on adding the few features to my compo game that I didn’t get done in time.  If you liked the game I submitted for the compo, I think you’ll like the improvements!

Original Compo Game

Improved Post-Compo Game

Ran through the game again and noticed a few bugs, which are now fixed:

• Score: counting errors resulting in inaccurate Births, Deaths.
• Collision(enemy) bug resulting in every collision killing an enemy regardless of its health.
• Fixed a few minor bugs in the Player controls (I think for real this time)

If you’ve already downloaded it and played it before, it’s worth downloading again and trying it out with the fixes.  Gameplay should be a good bit more challenging than in 1.0.

Tags: Bactarium, bugfix, Chris Sanyk

Wow, what a weekend. This was my first Ludum Dare, and I can certainly tell you that I was not prepared. Deciding to do the LD48 in the spur of the moment, with about 3-4 hours of prep time is not easy. Attempting to code it using a library you have never worked with, in a language you have barely used, is even more so. Doing all this when this is the first actual game I have ever made, even more so on top of that. Honestly the only thing I’m actually proud of for this is that I managed to actually complete a full game in such a short period of time. I personally don’t feel like the my game is very noteworthy in any particular way, except maybe its ability to frustrate with the precision jumping room, but I feel great for having actually completely a game, and in 48 hours no less! (though actually much less than that, due to various reasons that you will see) Alright then, let’s have a look at the breakdown of what happened during those 48 hours:

Day 1 (including prep)

At about 2pm my time, with the LD48 kicking off at 9pm, I remember it suddenly and go check the website. Having always wanted to get in on this, I suddenly decide that now is the time. Having recently been doing some web development stuff and enjoying Javascript with the little bit I have used it, I decided to just go all out and code entirely in Javascript with HTML5 technology. The only problem with this being that I did not know any good libraries I could use to actually make the game with. So I did what any developer would do: googled. I ended up finding some huge list of engines, and eventually settled on using the CraftyJS engine. This was a huge mistake.

Don’t get me wrong, the engine itself seems like it’s fine and probably works well. However, the documentation is currently lackluster, there are barely any tutorials, and worst of all, the basic movement bits of the library that it provided did not work with the type of game I wanted to make. I am stubborn though, so I decided to just push forward anyway. Eventually I managed to cobble together some basic code that allowed me to move about and go into a new area. A new area that lagged all kinds of horribly even though it wasn’t even that large. At this point it is 5am, I am frustrated, and my small level is lagging a lot. It was time to go to bed.

The next day, with about 3-4 hours of sleep, I made the smart move of switching to another engine, one that has good behaviors built in for sidescrolling. This time I was using the Stencyl program to create a flash game. Unfortunately I had not used Stencyl in a long time and had to re-learn a lot of stuff on the fly. Beginning all over again is frustrating, and I begin to worry that I will not finish my game at this point. Doubly so because I have social obligations for that day, ones that would end up consuming a good number of hours during the dare. However it is while I am out, hacking away at some behaviors with my laptop, that I start to feel like progress is being made. I only make a little progress today, but what I do get done feels like an actual accomplishment.

Final Hours

I got around 6 hours of sleep that night, and still felt kinda like crap. But I had a game to make, and nothing was going to get in my way. This is honestly the day where pretty much everything got done. I pretty much put most of the game together between 9am Sunday morning and 8pm Sunday night. There were a few hours that I was productive on Saturday, but most of it happened on Sunday, particularly after the scrap of the first engine and everything I had to do on Saturday which was not making games. Honestly, this period of time was the most enjoyable of the entire dare. I had started to gel with the tools I was working with, and they are easy enough that adding content was an absolute snap. At around 7pm, I was feeling like the game was pretty much done, so I managed to spend a little time with SFXR to get some sound into my game. Then I discovered a few more bugs here and there and managed to quash them with an hour to spare. The most annoying and irritating part of this entire process was the fact that Stencyl kept spawning these invisible tiles that were totally unselectable from the scene editor, and I had to re-design a couple scenes several times either trying to get them to go away, or to work around them. They’re still there in the final product, but I designed the levels in a way that it is impossible to notice them.

Last Points

I really learned a lot of things during this, as short a time as I got to spend on actual development of the final product. The most important of those being that knowing the right library/framework to use BEFORE the dare starts is incredibly important. It is also very important to know the language you will be using fairly well. Attempting to basically learn a new language with all its little issues and workarounds on the fly is a bad idea. It is also a very good idea to know you will be entering the dare in advance so you can schedule your life around it. If I had been able to commit myself to the dare for those entire 48 hours, I think I could have created something a bit more interesting, a bit more refined, less frustrating, etc. It is also a good idea to try and keep in high spirits the entire time, always saying that you WILL finish your game no matter what, even if you have to cut lots of features or levels. That is much harder than anything else, but if you want to actually complete the dare it needs to be done. You can spend a nigh infinite amount of time polishing some small aspect of the game, but getting a full and cohesive game out there, even if it isn’t perfect, is much more valuable in the end. Particularly if you have never done this, or never made a game.

All in all, this has been very fun, even if I was discouraged for a bit in the middle, and I did not get to spend nearly as much time as I would have wanted focused solely on game creation. I’m going to use the time between now and the next dare to learn more about Stencyl, as it really is wonderful to use, so that next dare I can actually be prepared. This might have been my first LD48, but you better believe it won’t be my last. I can’t wait for the next one, and next time I’m going to attempt to create something much more interesting.

SlimeABug is a game made by ghoulsblade, hagish & SiENcE.

Play and Rate SlimeABug!

A tiny alien blob from outer space gets stranded on earth in a front garden. Use your blobs shape-shifting abilities to find the way back to your spaceship. Consume corpses to learn new forms and use the abilities they grant.

We hope you enjoy the game!

cheers
SiENcE

Man, Ludum Dare is hard, even as a team. 5 dudes working on a game, and still took us the exact 72 hours the Jam allows. Was surely a crazy ride. I could go on about the “we learned alot, next time we’ll kick more ass”, but we hear enough of that already. :3

So here’s my experience during this wacky weekend.

The Good

• I just can’t believe I managed to spur 7 god-damn songs and a full batch of high-quality SFX in 2 days! Didn’t even need the 3rd one, all the audio was done by Sunday. Shows that I’m becoming speedier in delivering my work.
• Got a better and more practical feel of my tools, something I never really had before this game. Learned to use them in unison (FL + Audacity + bfxr + freesound.org etc.) to overcome the lack of recording tools, and got some good results.
• Learned how my team self-organizes. This game alone allowed me to follow the rhythm of my colleagues and adapt to it on the run, since we have no set leader/manager for the actual game-making. And boy, we work pretty well together! 😀

The Bad

• DO NOT MAKE A PUZZLE IN LUDUM DARE. Not even for the Jam. Unless you really know what you’re doing. You wouldn’t believe how difficult and time-consuming it is to make a single logically-solvable level, let alone 10+ of them.
• We bit more than we could chew, but still managed to work around the issue. My idea got a bit too carried away for LD’s proposal, and the theme entered mostly in the story, and very little in the game itself. (yes, the game’s idea was mine)
• We didn’t execute the idea flawlessly, to be honest. The game was fun for me, but I do understand where people are coming from when they say the box-moving was a bit tedious. It was bad planning, but from my part mostly, since part of the level design was mine too.

The Details

1. FL Studio is pretty strong!: This weekend I put the poor thing through some crazy stuff to get the correct sounds, and it did a pretty good job. Cut one in Audacity, effects in FL, edit the rendered sound, get the freqs right… it was very confusing. FL is excellent, you guys should try it out.
2. Not everything gets to the end: A tip for artists out there: don’t expect your “magnum-opus” piece of game art (sprite, bg, concept, song, whatever) to go into the final game. Not because it was hated, but just because the game worked better without it. Such is true even for coding and game design: a LOT of things are cut out for the sake of a better experience in general. From the 7 songs I made, 3 of them didn’t make it, for the sake of auditive consistency and file size. And these three were calmer, soothing versions of the ones in the game, meant for the surface ambients and cutscenes. Shows how erratic game devving can be. =/ EDIT: Turns out it was just a bug! 7Soul had a power outage that wiped this section of the game’s code, adding only the adv. songs. He already fixed it! But the advice above is still valid regardless.
3. Communication is key: This game took us every single hour we had, but still came out. We finished an actual game. I can certainly say that it was partially thanks to Skype, since none of us know each other personally. By being able to request each other’s aid without resorting to scrappy alternatives, we managed to get a much smoother workflow going. So if you’re setting up a team or working with one, pay a good attention at how your team will communicate. Protip: voice-chat leaves the hands free for working. ;D
4. More is about to come!: This is not the end for us, oh no. We are gonna make MORE games. Now that we know how we work together, we’ll improve a lot more, and bring more polished work to the indie game world. Dead Pixel, in case you don’t know, is the team we made. 5 brazilian devs, mostly artists. Even if we’re not specialists, we know what we do best, and we’re always improving. So expect more games from our group!

Conclusion

This was very fun. Certainly a great learning experience, and got us finishing something for once. You can follow us on http://www.deadpixelgames.com.br (the site is in both EN and PT) for news about our crafts, or our twitter accounts.

At Twitter I’m @Xwing9, and our group is @indiedeadpixel.

HAPPY 10th BIRTHDAY, LUDUM DARE! AND THANKS FOR ALL THE FISH! <3

Pin Party Video Postmortem

I did up a video postmortem of my game for this Ludum Dare! Check it out at the link above, if you’d like.

Play c!ph3r »

Post Mortem

Now that I’d had a bit of time to recover, I thought I’d share a few notes from my experience this weekend doing the Jam.

1. This was the first time that I’ve worked with someone else for game art. It was also Worm’s first time working on a game, much less a game jam. While we had a pretty decent system down (Skype + Twitch + Dropbox), there were a few rough patches early on where there was some wasted effort. To his credit, Worm stuck it out, and if nothing else, he contributed a mighty fine splash screen! =)

2. Programming-wise, this was my first real project using Snax, my custom pre-processor for Haxe. It made things much easier overall, but there were a bunch of annoying behaviors coming from Haxe where I wasted time trying to get basic things like Float/Int conversions to work out right. Snax is getting close to where I can probably make it open source, so let me know if you’re interested.

3. I’m pretty happy with the game. This was my first time doing something rather puzzley, and I’m glad I was able to use all of the game elements in combinations that feel fun. I’m particularly happy with the way the player sprite evolved into a sneaky-hacker-spy type guy and how that idea influenced the game mechanics.

Anyway, I hope you like it. =)

Buggy, Tank and missile launcher – How it started

Forgot a link: http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=7283

This was my second LD entry, and it was Cavit’s first entry. I really enjoyed last LD Compo (and have since been active on IRC), and asked Cavit if he would like to join. We had a blast this weekend creating this game :).

The concept was created pretty easily. I woke up at about 7 am on Saturday, looked at the concept, went back to bed with a notepad. At about 8 am I had a number of concepts, and started concepting them on paper. Cavit joined in about an hour later. We discussed what idea’s we had, and this was the one we felt sounded the most fun and easiest to execute.

On saturday we first started by putting down the basic. A world, rotating cubes around it and clickable stuff. Cavit started on the building with the separate floors, and a simple Unity UI. I started with the planet, lanes and rotating units around the planet. After this basis was done Cavit continued with pure coding, while I started on models. I think it took about 3-4 hours to do all the models and animations. By about 7pm we had a working prototype with units rotating around the planet attacking each other and a building. Once we had the prototype the controls were not as intuitive yet. We stopped at about 2 or 3 am I think, we had a working version and were feeling good about it.

On sunday polishing started. I wrote a complete custom UI and created new buttons. Cavit started working out as many kinks as possible, set up basic AI, set up some basic menus. At the end of sunday we had a polished version.

On monday Cavit needed to go back to work. I spent the day integrating the upgrade system, tweaking the balance, and improving the AI a bit. In the evening Cavit worked on sound, and I built a second level and did some more menu tweaks. We sent in the game at about 2:30 am. Of course, we had a gameplay breaking bug within half an hour ( money labels did not show up). We are not sure why it happened, because it did not happen in the editor, but we needed to recode the ui system a bit, and went to bed at 4 am on monday.

What went wrong?

– What you see in the unity editor might not be what you get on other PCs. We had a really nasty bug after launching, needed to test on more computers

– Games like this are hard to balance, one player will beat it easily, others will not be able to make it. Needed more levels

– There could be some more depth in the game, we had more conceptual stuff on paper that did not make it in.

– Would have been awesome if the game had been multiplayer

– Health stuff: We worked until too late, now our sleep schedules are messed up, ate too much wasabi chips and other crap, need to spend a lot of time in the gym now.

What went right?

– Prototype done on the first day

– The game was easily extendable, we could add layers like upgrades later on.

– We enjoyed working on the game, it is a happy looking game, and that made us happy to work on it.

– We kept the graphic assets requirements low. This way we could focus on the gameplay (this was a fix to my biggest mistake last LD)

– We cleared our schedules as much as possibly, this made it easy to focus. We worked with skype on almost constantly, and in general we are very good at working together.

What did not make the game?

If we would make a full game out of this. We would add a number of features.

– Base defense, like turrets.

– Camera zoom, so you can see more of the battlefield

– Minimap with circle and dots of friendly and enemy troops

– Flying units so you can bypass lanes/death from above.

– Multiplayer

Conclusion

Cavit and I had a  lot of fun, and are definitely joining next LD. We are thinking about making a more full-featured game out of this for PC/Mac/iPad/PSN? after we finish the project we are currently working on.

Just wanted to say, we had a total blast making “Ant Command” for the Jam. Really cool to see all these entries. I’m blown away by what people can create in a couple days.

We’re convinced this is probably the best way to prototype games for iOS or whatever – just such a cool way to stay focused. We spent maybe 2 hours picking the game, and jumped right into development after a reeallly short design phase on Friday night.

We’re calling this a big success story, although in the end, we only had an hour or so left to mess with the gameplay after it all came together. We’re pretty thrilled with the result, and I’m sure we’ll be taking this game to the next level.

A little more Postmortem’y thought:

What went wrong:
– Stressed out our wives a bit Next time we’ll probably make some plans to have some activities for the kids or something.

What went right:
– Unity – holy crap, they make it easy. We were able to figure out stuff we’d never done before in the engine in a matter of minutes (music, some basic UI, rigid body physics…)
– Taking Sunday off! Ok, we did a little bit on Sunday (Forest wrote some music and I was fixing a source control problem.) but for the most part, we relaxed and just did game design in our heads. When Monday morning rolled around we were ready to rock.

(Play Ant Command)

Tags: postmortem, SuccessStory

This is my second Ludum Dare- on the last one, there was a screen where I was able to view all the entries and see what I had given ratings to, etc. Where can I find that screen? (I feel like I’ve looked everywhere).

Also, is there a way to sort by submitted type? I don’t have Windows and I’d like to only see submission that are OSX|Web|Flash|Java.

Thanks!- this past weekend was a blast and I’m hoping for many more. Thanks for putting this together.

Ludum Dare vs gaming platforms

I know I know… the competition is over. Bu it was such great fun to work on this game and people liked it so i thought i should create a couple of more levels. I will upload the new gamefile tomorrow (i hope) with DOUBLE the levels! Wohooo!

In the meantime: have fun playing the 2days “old” version of “Save your folks – or just dont”

PLAY THE GAME

Ah right and here´s a new screenshot of a Level called: OSTBLOXX II:

While Zeik and I figure out our post-mortem thoughts and plans for future tweaks to our game, have a timelapse video courtesy of Cake! And since she’s the artist and designer of Pow! Pow! Pow!, be prepared for lots of colors and cute little aliens. (As well as not-so-cute bigger aliens.)

Play/Rate “Pow! Pow! Pow!” Here

Brief Summary
– Character and asset creation
– Environment design
– Inspiration from The Twilight Zone
– Designing a set of cohesive enemies
– Planning storyboard ideas
– Level design through XML on Dreamweaver and figuring out exact pixel positioning through InDesign
– Brainstorming harmonious typography combinations (Existence Light with Arvo)
– Brief poor attempts at sound editing and sound effects
– Random one-second blip of Michelangelo’s “Pieta”
– Lots of Twitter and IRC shots. Yikes.
– WEBCAM PHOTO TIME!!!
– Excluded: All the facebooking and AIM-ing that ensued

Tags: timelapse

All right, we did it! Almost can’t believe it, it’s among the most insane 72 hours I ever had!

Tiny Shards is a tiny platformer with multiple levels and enemies, a few power ups, a little plot and the hope of some meaning!

PLAY IT HERE

Feedback is more than welcome! Hope you people enjoy! 😀

Well, all in all I’d say that my first entry was a success! There was a few mishaps and perhaps some things I could improve on, but for a first programming competition attempt, I was surprised at how well the end result turned out. I have to say that Ludum Dare is a great thing, because I’ve started a a few “games” before but none of them ever ended up getting finished enough to be called games, but this was different. I think I can safely say that I made a “game” this weekend and I’m quite happy about it. I hope to participate in future LD48’s and I had a great time in this one!

Happy coding guys!

–Topaz

Well, yesterday I decided to do post-mortem work on my immune system game RTS game.

Currently, I have only one campaign level – but I did a lot of refactoring in the game logic code.
Let me know what you think about it, any hints appreciated

The first campaign level shows you how to use the immune team and the supporting leucocytes, so it’s more kind of a tutorial:

http://martens.ms/ludum-dare/ld23-immune/

The concept of the game:

You can either play the virus team or the immune system team. You (currently) have two Computer players taking part in the game. One is neutral and controlled passively by the Immune System. This neutral Computer is the one that controls the leucocytes that are controlled by the interleucines (produced by the immune’s globulines) and will attack the cells that are under control by the virus team. The viruses team advantage is that their spawn rate is higher than the spawn rate of the immune system and that they are much stronger than globulines (but weaker than leucocytes).

The immune system player is the one that is defensive, but he can also attack with “Blitzkrieg” strategy and making the virus team busy whilst using his leucocytes bonus.

The virus player is the one that is aggressive, he is the one that has to infect as much cells as possible. The more time he has, the stronger he gets and the harder it is for the counterpart to eliminate the virus player.

Taking further the concept:

What I wanted to achieve is a more realistic RTS game that is balanced and has a tech tree with different units. So, for example, the cell will have different “buildings” inside:
The nucleolus: This is the one that is producing the DNA, splitting and results in “more units” if upgraded
The cytoplasma: This is the part that is the shield of the nucleolus, it will upgrade the health of the cell so that it can take more damage until being captured.
The ribosomes: The research building. Use it to research DNA upgrades (mutations) for your team. For example, this is the place to equip leucocytes with better amino acids; the place to get T-killer or -helper cells as reinforcements. The counterpart (virus team) can research their own upgrades here. For example a by-strength upgrading until you reach Ebola.

(Doomsday) Super weapons:
The immune system team can have fever as a super weapon. It is limited by time (e.g. every 3 minutes) and has the capabilty of completely killing all cells at the game board (excluding the viruses that are currently produced inside the cells). It will also neutralize the immune’s captured cells and remove the leucocytes on the gameboard.

The virus team has the super weapon of upgrading to the T-virus (haha, resident evil and zombies! :D) which is therefore able to attack t-helper cells (like HIV) AND to attack t-killer cells, which are the ones that can completely destroy cells like a “bomber” in a classic RTS game.

Let me know what you think about this concept… and if you have suggestions: They are very appreciated!

Tags: antivirus, cell, immune, realtime, RTS, strategy, virus

(linky.)

What went right:
-I ended up doing everything I explicitly planned to do.
-I learned a little bit of Javascript/HTML5 (still not exactly sure which is which to be honest). Actually LD is the reason I know any Javascript/HTML5, but most of the learning happened before the actual event.
-The exploratory nature of the game is close to how I want it. I wish I could reward the player more for exploring, but I didn’t have time to code minor prizes or stick them in the world. But I like that there’s multiple paths to success and that you aren’t always exactly sure what you’re supposed to do next. With no user feedback (during the contest), it’s possible it’s too hard to figure out what to do next. Hm. Maybe Ludum Dare games should aim to be easier since user feedback is hard to get, if not impossible.
-I like that the dustinator has more than one use and that the items complement each other. I wish there were more multiple use and complementary items.

What went wrong:
-I think the game has little replay value. Unless you want to continue exploring the star system (I feel like that’s unlikely) or do a speed run or something (definitely exceptional). I’ve thought of two solutions so far. One: procedurally generate the world so it’s unique every time. I think I avoided that because I figured it would be impossible to make the exploration how I wanted it. Maybe it would’ve been in the 48 hours, but it seems easier now, perhaps because the Terraformer Breath level design I did has solidifed in my brain after sleeping, and now I can more easily think how to express it in code. I’ve also been toying with the idea of abstracting procedural world generation so it can be created once and used on many games. Supply the player’s abilities and goals, some world generation functions (like makePlanet), and a simulation function, and let it make a world for you. Anyway, two: have more random elements. Which is really a superset of the procedural thing, but I mean even in a static world, other random elements can give replay value. Like smarter enemies that do something different every time or randomized planet motion or something.
-I chose to use HTML5/Javascript to reach a larger audience. I think this was the wrong choice. I’m glad for what I learned and I wouldn’t go back and change it, but I think next time I’m going to stick with my preferred C++/SDL/OpenGL kind of stuff. I felt so limited once I saw what people who didn’t use HTML5/Javascript made. Javascript debugging is horrible compared to C++ debugging (unless I just don’t know what tool to use — I was using Firebug). Not to mention I’m a fan of lightning fast barebones programs, and Javascript doesn’t seem to cut it.
-Though so far people seem to enjoy the disembodied voice, I definitely thought I could come up with a lot more funny things for it to say. I guess it’s one of those laws. Divide how many jokes you think you will think of by 3, and that’s how many you’ll come up with. Not to mention it was hard to think of things that were funny and not too insulting to the player (I don’t think that’s a trait of my personality, but it’s possible).

What’s going to happen (before the next contest in which I partake):
-Expand Dan’s Tile Maker. The atmosphere tiles should’ve been easily creatable from some transition function. I decided not to add in the functionality during the contest and just Gimp/MSPainted them. I could’ve created the atmosphere tiles way faster, and made them all pretty and texturey.
-Finish a midi editor I’ve been working on and get it distributing. The vim (but hopefully more intuitive — not that vim isn’t intuitive, vim lovers!) of midi editors.
-Make and distribute a library that uses SDL and plays midi files through a bunch of signal processor units you can configure to make instruments out of.
(If any of those things exist already, tell me!)

Hey !
I’m Eldaryze, the programmer and sound designer of the getRandomName() Jam Team.
Here is my 72h Timelapse of the game making.

Check our entry here !

Tags: 2D, as3, eldaryze, enimal, flash, Flixel, getRandomName, jam, ld23, oxydam, super, timelapse, tiny, world

Well More went wrong than went right in terms of my game, but the amount of fun i had and things i learned trumps that.

WHAT WENT WRONG:

1.Firstly i didn’t spend enough time thinking about a game to make(WORST MISTAKE EVER!), So it ended up as a collage of things ive always wanted to try.

2.I tried to implement to many things into my game at once and therefore they didn’t work properly or as well as they could.

3.LEARN MORE ABOUT ARRAYLISTS!!!! I used an arraylist to render and collide my enemies which sometimes(As I later found out) randomly throws an error crashing the whole program!

4. Monitor my time more closely(I probably should of tested more often and got other people to play my game)

WHAT WENT RIGHT:

1. I Got my game in a playable state(…?)

2.I made a tile map thing that i could easily change(Never tied it before)

3. I Quite liked the art that i went back and drew more carefully.

IN A NUTSHELL:

I had a heap of fun and will get to play some games(can’t wait)  And I hope other peoples postmortems are more positive than mine. Ill be back for the next LD48 thats for sure.

Play Asylum

what went right:

• I did use the tools I know – so my workflow was quite good and I could jump into the action right away
• reading through the Flashpunk documentation before LD started turned out to be a quite good idea. I learned of some function I didn’t knew exist – and although I didn’t use this specific one’s – reading the documentation of your engine is never a bad idea
• this old-school 8bit style graphics are very easy for me to produce and many people like my stuff – so I assume I’m good at it. it’s a good idea to stick to what you’re good with for LD
• I took some time to think about the theme and develop a pretty good concept in my head which I played through “with my mind” several dozen times. prototyping with your mind is something that people should invest more time for

what went wrong:

• time management … oh boy did I screw up.
  initially I thought I’d have the whole 48 hours but suddenly stuff happened and I even ended up abandoning my LD entry completely at one point. it was only several hours before the deadline that I got time to continue working and had to code in lightning-fast mode. the complete development only took about 12 hours.
  because of this I also had to cancel several features and make my game a lot shorter than I initially planned
• I didn’t do any sound … mainly because I didn’t have the time. but also because I’m quite inexperienced with audio so I figured to finish everything else first.
  as the development progressed it turned out sound is very much needed in this game and it could get literally 10 times better with some good audio – so I recorded some effects but sadly didn’t have the time to implement them
• the beginning of the game is much much too long. everybody who played it in the context of LD told me so. and that’s exactly the point. I playtested it only on it’s own and didn’t realize that most people would play it in a series of LD entries, so my game would start quite lame in comparison. this is a lesson learned – always account for the fact that your game is going to be played in a series of games.

what didn’t make it in the game:

the main level was planed much much bigger. I planed platformer elements (canons, enemies, moving platforms, portals…) that should make it more of a game. during playing this the background story would have been unfold and the player would have learned how the character ended up in the asylum and a bit more about what the monster represents. I also tried to use a bit of psychology for this – the hanging chains, the long fall and the shrinking room are all symbols for his story.

the game would be much better and much more disturbing as well as thought-provoking if I had the full 48h instead just a quarter of it – it also would feature sound

what my conclusion is:

I’m happy I didn’t abandon the project and finished what I could. all in all I’m quite proud – I don’t think it’s to shabby and it’s my first LD after all.
however – for my next LD I’m definitely going to make sure to no be kept away from working on my entry.

Tags: postmortem

After our first Ludum Dare, we are really satisfied with the feeling. It was a great experience and we enjoyed (in some weird ways) developing under a great time pressure.

Tiny Ranger by Monkey Armada

You can download/rate our game here: http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=2883

We had a lot of errors and problems related with our lack of experience in the beginning of the compo, next time we will face them totally aware.
Also, a new team mate joined us. He had no previous game development experience, so we spent quite a lot of time explaining the basics. Good thing is he adapted really fast and gave us some interesting points of view through the dev process.

Eitherway LD has brought us some interesting game ideas that we hope to develop further in a less stressful way, hehe.

What went wrong:

– The whole thing was awfully planned, as none of the team members could spend the whole weekend working in the game, due to previous unavoidable plans. We hope it will be perfectly scheduled next time we enter the LD.
– We should have prototyped everything better. The idea was not polished when we started coding, so we had to develop it while being implemented.
– We were too optimistic about what we could achieve, a lot of features and ideas had to be discarded in the end.
– our development tools were not totally ready and we spent 3 hours trying to install them in an old computer wich kept continuously crashing.
– Had some problems with the algorithms/bugs, must review some math before start coding :P.
– The aesthetics were not totally consensuated by the team, so some artwork was rejected at the end.
– We should have focused a bit more in the gameplay, it lacks fun and variety.
– Lack of social connections. (twitter, forums, comments…)
– Too much stress and anxiety. We have to learn to take it easy in these situations.
– The lack of planning lead to a slow production process in artwork, which could have used some improvements.

What went right:

– The final result is quite good for all the things that went wrong.
– We finished all the main features in time.
– Recorded a time-lapse!
– SFX implementation was really fast.
– Learned a lot from mistakes.
– Our lead artist finally managed to get involved with the code. That didn’t make a real contribution to the final result, but we think it can be a start point for future contributions to coding.
– We are thinking to give Tiny Ranger a chance to become a commercial product.
– We are very happy about the outcome of the dare. We did not expect that we could achieve such a good looking result when working under pressure.
– Our designers have found it really fun to work without creative limits, with the exception of the main theme “Tiny planet”, which is more an inspiration source than a limitation to the productive process.

(tl;dr: check the last paragraph)

I’m using a Linux system. That decreases a lot the amount of games that I can actually play from the entries.

Entering “linux” on the search box gives (at least some of) those games that have Linux binaries available. But this leaves out the ones that would be playable in a web browser.

Basically all other web technologies than Unity can work on Linux. A lot of entries have a “Web” link to a version that is potentially playable in a web browser. Not many of those state what technology the web version is actually using – is it Flash, HTML5, Java applet or Unity. (and many entries do state that, well done!)

A plea to those having a web version of your game available: state clearly on the link and/or on the description what technology your game is using.

So, thanks to a caffeine, bacon, and sugar fueled event that I happened to be taking part in (the Nokia Lumia Hackathon held in Johannesburg over the same weekend of LD23) I ended up doing LD and the Hackathon at the same time. This presented a whole bunch of interesting problems, the first being that I started after the rest of the hackathon participants (9 hours later to be precise), and the second being that compared to what they had to do I had more work to complete (they could use free sounds and the likes thereof where I had to make my own content. This wasnt a problem particularly, but I definitely got labelled as a weirdo for the weekend.

So, as part of the weekend’s happenings I had the perfect setup for a Jam, there were matresses, people to bounce ideas off of, unlimited coffee, snacks, fruits, cooldrinks, water, and recreational additionals (pinball machine, kinects, a foosball table and so on). This meant 3 things for my LD participation, first that I never had to worry about meals, they were at fixed times every day, and I never forgot to eat, second, I never had to go far to get a random snack or a new cup of coffee (or bottle of water), and so the vast amounts of coffee I consumed didnt dehydrate me, and thirdly I had my friends supporting me from the very start which helped me keep focussed and motivated to mission on in my code.

You can view a lazily-unrotated image of the game here.

How I prepared:

• I spent a lot of my non-studying time practicing doing random things that I would need to do for LD, these included art (drawings in photoshop), and random songs in FL Studio
• I made sure during the nights before the theme announce that I got enough sleep so I wouldnt be too tired from waiting up till 2AM to get the theme

What went right:

• I picked the first idea I came up with at the time, simplified the mechanics, and focussed on prototyping the base mechanics immediately. This meant that I knew how it would feel in the end result. After prototyping I was however slightly dissatisfied about that “fun” aspect of the game, but I decided to stick with the idea anyway so I could have more time to polish the entry.
• The mechanics were easier to implement completely than I imagined they would be, so I ended up spending the majority of the time I worked on the entry polishing the game. The accomplishment of this LD that I enjoyed most was the fact that this is my single most polished game I have made so far. Regardless of the simplicity of the game mechanics it is visually appealing (at least it is to me), and I hope to in future maintain the same level of polish in games I make.
• I had constant distractions, which made it easier to focus on the work in sections. I didnt tire my brain out by focussing solely on one thing (though Saturday morning I got close), working near people that needed my helped me a lot in this regard.

What went wrong:

• It turned out that I miscalculated the time till theme release, and ended up sitting around doing nothing for an hour, as the theme was actually released at 3AM rather than the 2AM I was waiting for. So I ended up shifting my schedule up from sleeping from 3 till 7 to sleeping from 4 till 8.
• I should have gotten at least an extra hour of sleep as when I got up Saturday morning I struggled to find the single issue with mechanics that slowed my completion of the game. Had I gotten some extra sleep I could have potentially finished earlier (I spent 3~4 hours finding and fixing a single bug that ended up being a simple vector addition that used the wrong components).
• I got quite stressed because of the pace I worked at, ideally I should have gotten more sleep on Saturday night instead of tanking the tiredness and working till completion by 2AM (roughly), but I think this may have been the influence of the other LumiaHack participants as I spent quite a lot of time helping them with their development.

What’s going to happen (before the next contest in which I partake):

• I decided to scrap RapidXNA development (I love RapidXNA and will keep using it for my Dream Build Play entry) mostly because XNA support is up in the air, but also because it is time I started supporting multiple platform
• Im hoping to learn DX11 and OpenGL 4.0 development, and using that I want to wrap them for the 3 main platforms (Windows, Mac, Linux) so I can release on all 3 simultaneously while developing only for one, but this may not be ready for the next LD.
• Im quite happy with how quickly I can develop the actual mechanic parts of the games I write, so I will keep practicing my art and music making skills, and hopefully for the next LD I can tackle a more adventurous entry that requires more content (simple mechanics, large amounts of content).
• I will until end of May be focusing on my Dream Build Play entry (for Windows Phone 7), after which I will do exams, after which I will begin looking at the DX11, OpenGL 4.0 and “multiplatform” library that I would like to build. (I may need to rope in someone with a Mac at some point to build/test for me)

Thoughts about my game in general:

• In the end I didnt work out a second idea and build it instead of submitting the first idea because the content took too long for me to build, if I had chosen another idea after the initial prototype I would probably end up with a more “fun” idea for my entry. Im going to have to think of ways to kick start my game idea thought process when I start these compos so I have ideas to choose between.
• There are a bunch of additional mechanics that I think would have been cool to add: Suns in the vicinity that you could accidentally travel to and die, black holes that suck you in if you travelled too close, moving past a nearby planet could skew your travel and make you miss your target. Mostly these didnt make it in as I thought it would be too punishing to the player, but also because for the LD theme I couldnt think of the best ways to implement them to emphasize the theme. I will have to address adding of content (mechanics wise) in future.

Strategy / simulation by Suese

Click here to play / rate.

Tiny Civilization

The timelapse of my Ludum Dare #23 entry “Plane Walker”.

Tags: timelapse

Okay I have joined LD twice with this but there’re something that I don’t understand. Please consider that these question will look super noob. I’m pretty sure I’m not alone about ranking table

• I understand R and C stuff but what is D? I score 3 entries with my own scored by 4 people and it got D:45. How is it calculated and will this affect final score?
• What is L? I can’t find example and still not understand.

Introduction
Finally, relaxation! Our two-man team (Ryan and Jon) buckled down over the 72 hours to churn out this Unity powered scandalous adventure game. However, it didn’t all go smoothly. A relaxed Monday turned into a stressful race to submit the game as the deadline inched closer.

External Sources
Lorc’s Icon set (used for a portion of our action icons)

Our team reduced the use of outside materials as much as possible. The icon set did not cover all possibilities for actions and required us to either manipulate the icons in Photoshop or create a new icon from scratch (there weren’t many lotion bottle icons in the RPG set *cough*).

Tools:
Unity
Photoshop
Blender
A terrible phone camera

Process
Preheat oven to 425 degrees. Insert brain. Leave for 72 hours (or until well done).

The code creation was frankly a pretty slapdash sort of thing. After we fleshed out our idea, Ryan dove head first into the gameplay. The first thing that was done was the general gui for interacting with the environment (clicking on stuff, popping up the actions interface, and performing actions). After the gui was done, next came hooking up all the gameplay, and smoothing out the action interface out a bit. The system soon got very specific. There quickly became things that had to be done a certain way, or named a certain way for things to work right. This was one difficulty with the super-rapid prototyping. There wasn’t much time to go back and change things if they weren’t structured well enough to start.

One thing that was very helpful was keeping a rolling document throughout the process that contained things like the specific steps needed to hook up actions, or naming conventions. In the end this became our big todo list, and it worked out pretty well for us. It got a bit messy at times, but overall it was good to have some documents to record thoughts.

As for sound, Ryan made most of the sounds (with a few done by Erica, Jon’s girlfriend) and pretty rapidly. All told, about 45 minutes was spent on music and sounds throughout the course of the competition. There was discussion about making a few tracks in garageband, but it was far behind bug fixing and assembly, and so it never came to fruition.

The world and character asset creation were both handled entirely in Blender. The level was almost all contained in one file with many objects being split into separate objects within the same scene. This process got a little messier as the room was expanded upon and filled with content (as scene navigation and object placement became especially cumbersome), but it was very easy to combine and unwrap objects throughout the scene that would be using the same texture. The reference for the house is our apartment which helped speed up the house creation.

The character creation was a blast in Blender. It took about 4-5 hours to model and animate the main character and an additional 3 and a half hours for the human that walks around the house (shitty though they both are). In a solo compo, it would be extremely difficult to have completed 3D characters and have a decent game to surround them with.

Our team split art and code down the middle (with one box having the “primary” scene); we worked in our own scenes until Sunday morning. Early Sunday morning we started hooking up all of the actions in the primary scene, assembling the majority of the game.

What Worked
Starting early! We spent about an hour talking about design before diving in. Coming up with a reasonable idea quickly and plowing forward worked out well us.

Splitting up the art and programming allowed us to both launch headlong into our respective areas without getting bogged down doing the hookups for each individual item immediately.

The humor, though somewhat crude, is part of who we both are and made it fun to implement all of the ridiculous actions. The actions gradually became more twisted the further we got along– probably due to partially fried brains. Hopefully nobody gets any ideas about spreading pink eye…

What Didn’t Work
Unity and Dropbox combined. We experienced multiple difficulties even when working in different scenes (and with the Library folder of the Unity project omitted from syncing). Partway through Friday, the frustration of losing work led to us both turning off our Dropbox syncing.

Some of the actions that the character performs were originally intended to be more complex (going from two step to three steps for completion), but the time required to add the functionality (along with the risk of introducing bugs) prevented us from extending the actions. Additionally, several textures are unlit in the version that has been submitted for judging. This was a result of waiting much too late to submit the final version– it would have been better to start making the final builds even 4-5 hours before the deadline to test the builds and catch anything that has slipped through the cracks during development.

Also, I think it would have been good to have a few different camera options to use coming into this thing. We spent a fair bit of time trying to tweak one of unity’s default controllers to do what we wanted, and in the end found ourselves spending too much time on it. If we were to choose a small bit of code to bring into the next jam, it would be some custom character controllers we are bound to write by then!

Conclusion
The final submission is something that our team is proud to have pushed out in just a couple days. Next time we will probably have a rapid prototyping toolkit full of modular, reusable code that can be used in a wide variety of projects. For now, though, we can take some time to relax and enjoy the creations of our fellow developers– better get back to that. Thanks for reading!

Play Redbeard the Borrower

Big thanks to everybody who showed up to our Ludum Dare gathering at Free Lunch Design. It was great fun to meet you and to see you make and play your games! 😀 Here’s the list of games made during the gathering:

The Island <- – – -> Dude Rescue

.

The Story of a World <- – – -> Tiny Wizard

.

Head Trauma <- – – -> Astro Break

.

Tiny Stomp <- – – -> A Super Mario Summary

.

It’s always a joy to participate in LD and I can only hope you enjoy our games as much as we enjoy yours! Trying to play as many games we can at the moment and really enjoying the experience. Congrats to all who submitted! 😀

First up is Walker by Catman which is a platformer (no, this one is different trust me!) which has physics and puzzles that keep the adrenaline running in the style of Donkey Kong Country on SNES.

The second game is conceptually simple but I like the idea and the artwork, the image speaks for itself, World in a Bottle by Serilyn:

At 2am local time #LD23 started, we were sleeping :D. However we woke up at 6.30am to the news that Tiny World was the theme. After 2 and a half hours we had an idea of what the game was about, from then on we timelapsed it.

This is the first time any of us participates in a Ludum Dare. Post-Mortem.

Andrea

After At the start I thought the game was too big. Half day in I started gaining confidence.

My view of the game after we finished working on the concept was that perhaps it was too big, I also thought maybe I just didn’t get it completely. As of  right now I think this is a cool little game that needs some balancing and finishing details, however I really like the idea. In many ways I think we were lucky to find a not trivial idea so fast.

Maybe people coming to it with fresh eyes will have some difficulty trying to figure out what’s the story, that was not the intention.  My apologies if the game doesn’t make sense.

The Good

• We submitted the game in time, with not so obvious gameplay, nice graphics, sound effects (not complete )
• We slept and ate as we needed, tho I should probably be sleeping now
• I learned loads more about game programming and had a great time at it. ie using x-flixel
• Simon did a great job with the song and so fast
• liked the way we pushed TODOs back and forth taking into account the time left.

The Bad

• Installer that we tried earlier did not work on “virgin” machines, we had now two comments about the installer
• Got stuck sunday night, I can’t even remember why, but didn’t move on or asked for help quickly enough.
• should have practised with x-flixel before hand.

Andrew

What went right.

• We had a really great framework in x-flixel, a port of flixel to XNA.
• Getting lucky with an idea early on.
• Stocking up on food before the start so we wouldn’t have to leave the house.
• Space hippies.

What went wrong.

• Picking something maybe a tiny bit too large.
• Not practicing with the framework before hand.
• Not building a few installers before hand.
• Not having access to an artist for the full 72 hours/spending too much time on temporary art.

Spaceways gameplay

This was a great few days, looking forward to the next one.

I have now played alot of different games, and they were all pretty good. Good job everyone!  I had a great time making my own game, and now its fun to see what you have made!

The games below are some of my current favourites, but there are alooooot more good games out there. I wish I had time to test all 1400 games…

Tiny Worlds
In this game you travel among planets, trying to not get lost into space. The graphics are smooth and plain, and the music is super great and well made.

Aether
This game is a pretty short platform-style-game, but I enjoyed every second of it. The gameplay is good, the graphics are just pretty and I just loved the feel of the game.

dLeIaFtEh
Im still wondering if that really is the name of this game…
The graphics are very smooth and nice, so is the gameplay The game also has this awesome mood, it made me happy.

So, make sure to check these out! I would also love to hear about games you have found that you like: comment or make another post!

Pocket Strife Entry

Session 1 [ Fri Apr 20 20:56:25 -> Sat Apr 21 02:22:08 ] 5.5 hours

Figure 1. iso-mine-craft shows it’s sexy side.

At this point I felt pretty proud of myself. I’m two hours in, and have something that #ludiumdare and #love actually like the look of. If there’s anything I learned from minecraft, is that a lot of low res crap makes one big hig-res-low-res thing that looks good. Of course, I’m totally bombing the framerate here.

Figure 2. I’m starting to realize that this was a bad idea

For the next three hours, I spend the night trying to figure out how the hell to a) make the performance smooth (e.g. only draw the tiles on screen, don’t just test if they’re on the screen) and the math to make the mouse work. I’m getting at best 46 fps (where it should be closer to 1000 in this case). I’m getting discouraged, and decide to go to bed, as I have a friend from California coming in, and a band to try out for that night. I spend the night chilling, playing guitar and smoking shisha with my girlfriend. Obviously I’m not taking this too seriously, but I did plan on using Sunday to finish the LD and make a “game” out of what I have.

Session 2 [ Sun Apr 22 ~13:30:00 -> Sun Apr 22 20:24:06 ] 7 hours

Figure 3. Now we’re getting somewhere!

I came back and slept in until 1:30ish on sunday, and started at it again. I decided to use all the shortcut tricks I knew to get the framerate back up, and used some seriously dirty hacks to get the mouse to work (had to get the location during the draw phase, and then hide the mouse to avoid suspicion!). I’m not proud of them, but it beats spending hours trying to figure out the math myself (sorry internet, you weren’t very helpful). At this point I started bashing away at the game, and things moved very quickly. I had four building types, I integrated the health bar, and you couldn’t place buildings on tiles that were too blue or white. Later, because this wasn’t dynamic enough, I wasn’t able to include the cool maps and such, like lava planet and the moon.

Hard coding only four items really came back and bit me in the ass, but I knew what I wanted for game play, so it was not worth the effort making the system dynamic. At this point, I have added the territory flag, but I still haven’t gotten the AI in yet.

Now the AI is in, and working at full stupid. Using a bit of math, and tweaking it until the computer made what I wanted it to make, life was born. The computer is faster than crap, and doesn’t really think much, but it’s there, it’s pretty, and it’s hard to beat. I like that. At this point I start integrating the lovemenu library that I have.

Let’s not forget the kitten challenge! I spend the remainder of the time testing the game, and fixing small bugs.

The game is done, and it’s time to start packaging for distribution. I take pretty screenshots, and shove them into my repo. I run my build scripts and upload the final product up to mediafire. I fill out the information on ludumdare and leave to have burritos at Moe’s. I was unimpressed by my framerate and graphics, sad that I had to include the mouse hack, but still rather proud of my product.

Total: 13.5 hours

Pocket Strife Entry

Tags: timelapse

Here is the game i have ben working on: http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=9986

If I had hair I’d be ripping it out right now. I was so happy when I finished my game, felt like a huge weight was off my shoulders. Those hours upon hour of coding finally produced something fruitful. I breathed a sigh of relief…

And then it happened. People found bugs in my game. I was disheartend, that euphoric high I had after completing my game came crashing down… I franticly searched my code to see why these bugs existed. Then I saw my mistakes… the simple rookie mistakes I had made… man I wanted to kick myself in the ass, how could I have made those stupid rookie mistakes!

So I have some advice for you all, two words. BETA TEST, BETA TEST, BETA TEST!

Test everything! I cannot stress this enough…

Seems I need to update the “What I’ll do better next time” with this tidbit of information.

– I will test everything in my game to make sure everything works the way I intended it to

-KunoNoOni

Tags: as3, compo, final, flash, Flixel, game, ld23, post-mortem, postmortem, update

Am I the only one with Ludum Dare post pages locked and no new posts showing?

Post-Mortem version, with display-setup, and few extra contents.

Version Post-Mortem, avec paramètres d’affichage, et contenus additionnels
→ (notamment le jeu en version française)

Download (RAR-archive) : Post-Mortem RAR Version

Download (ZIP-archive) : Post-Mortem ZIP Version

Tags: Adventure Game Studio, AGS

Join me on my stream at 6 pm PST (-8), as I talk about the Ludum Dare 23 while playing games to ease my stress. Share your stories with me! Let’s all relax and have a good time.

Mad Michael of Metal of NRGSoft: Tiny Octo World postmortem:

My role is both PR and anything that needs to be done, but not programming. I have to take up programming now because one is never enough. This game clearly pointed that out.  Unlike last time with our heads up in the clouds, this game was structured and doable in the matter of time set.

What went right:
-I finished the basic sprite of the main character on day one, and day two I did idle animation.
-My main menu looked very professional, with cool little bomb buttons, compared to my first main menu screen.
-Sounds and music were done very early instead of last minute.
-Day three, due to the limited time, all the refining and adding new graphics made me improve as a spriter and gain a new style of art.

What went wrong:
-Funny ending picture, but ugly ending screen background that I never found the time to fix.
-Should have split my duties more on day 2, too much work and time was slipping away.

What went ugly:
-Game was never finished because of a huge bug that prevented the release when the game was so far in the development.

-Michael

I absolutely loved my first Ludum Dare. It is a good exercise is planning, scaling, hacking, imagining and just plain having fun! Until two days ago I’d only build large enterprise software systems, and never really a game before. But I really enjoyed it, and recommend everybody to join LD24 four months from now.

The concept:

For this game I decided to stick with plain Java. It is the language I know and are familiar with. Also I decided not to use any framework whatsoever. To make it playable for as many people as possible I decided to make an applet. It could easily be made into a standalone application, or maybe an Android app…! I loved the old point-and-click games when I was younger, from Dirty Larry to The Day of the Tentacle, from Monkey Island to Gobli(iiii)ns. So that was settled, it’s going to be a point-and-click adventure!

The big pro:

Not a lot of physics and/or complicated game code.

The big con:

I’d have to brush off my paint skills because point-and-click adventures are filled with graphics and animation! I’ve fallen in love with my little animated robot (see above).

One big factor in games is music, and for this contest I took some MIDI control code I made years ago. This was turned into a procedurally generated music generator. Every time you play my game you’ll hear something new. Also, the music is constantly evolving and will never play the same thing twice. But, to make it easy on the ears, some chords do repeat and all changes are slow.

I’ve also added three types of chords, happy-chords, sad-chords and scary-chords. During the game the emotion of the character will change, and so will the music. It can also speed up and slow down.

The result:

I had a volleyball game on saterday, and visitors coming on sunday, and I had to watch the F1 and Luik-Bastenaken-Luik. So it was already a busy weekend. But I managed to squeeze in some hours. I think the game turned out pretty well. You really have to search to find all the items and get further in the game. A friend who test-played the game said he had the same good feeling the moment he found something new, making progress in the game, that he had playing games like The Day of the Tentacle. Which was a huge compliment.

Here is my result, have fun playing the game: Itty-bitty botty!

p.s. Any comments (and ratings) are appreciated! Perhaps someday I’ll create a full blown game, I’d love to do…

Here is the post mortem for $ales, my real world trading simulation game. Check it out here.

What went well:

• Discipline, the first day I woke up at 5 AM, specifically for Ludum Dare. Normally I never do this.
• I had a solid idea very quickly, even though I didn’t really like the theme at that theme.
• I knew my software, GameMaker, really well. I had no problem solving any problem at all.
• I quickly created my art, even though there was not a lot of art involved.
• I didn’t get distracted by the IRC, I just regularly checked it.
• The voice acting, it was my first time ever doing something with voice acting in a game, and I think it turned out pretty well.

What could have gone better:

• I should have coded the economy system better, so that it can be randomized, now everything is pretty much hard-coded.
• The trading menu looks a bit boring, but I didn’t know how to fix that.
• I should have come up with a better technical system to show the world map. Right now I was limited in my sprite size due to the size of the world map.

I think it was one of my better Ludum Dares. Definitely better than the last one. I am looking forward to LD24!

Side note: I’ve just noticed that apparently we’ve gotten rid of the “Community” category?  I guess it was kind of a hard thing to rate anyways, so I don’t really mind.

Link to rate/play:
http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=7285

Alright, it’s been a couple of…days? (my mind is still having trouble readjusting to the day-to-day cycle)  So, let’s start off with a quick recap of what went right, what went wrong, what could have been better, what I’d do differently, …

What went well

Doing a warm-up entry
Wow, I am so glad I had time to do TwinkleShooter as my warmup game the week before LD.  I learned a lot, and definitely saved myself a lot of time and stress by familiarizing myself with Flixel and AS3 and all of the weird little quirks and details that you need to know about.  I also got in the groove of riffing on a prominent theme/motif with my entry in One Hour Compo this past week, so that prepared me for the music too.  Speaking of which…

Music
No real surprise here, to be honest, since I’m really used to producing things quickly from all of my OHC practice.  While I would have liked to be able to spend some more time on the music, being able to bang out the entire soundtrack in roughly 3.5 hours and have it be so cohesive and catchy was definitely one of the high points of LD.  One of my main goals this time around was to make a game where I could show off my musical abilities, since One of a Kind wasn’t really particularly amenable to that.  I’ll be writing more about thoughts I had while composing in a separate post.  Btw, soundtrack download is here.

Making a Flash Game
I knew from last time that browser games are just so much easier to distribute and have others rate and play, so clearly that was the way to go here, and I didn’t regret it one bit.  C# was clearly not easily portable, judging from what happened with One of a Kind (it “works” on linux and osx, but the linux one requires weird dependencies and doesn’t work on 64-bit, and the osx download is HUUUUGE), and although I could have always done C++/SDL, that would require way too much boilerplate, and still not as easy as an in-browser game.  There’s also unity and html5, but Flash seems to make the most sense for what I want to do.

The Idea
It wasn’t an AMAZING idea, but I liked it, and it came along pretty quickly after the theme was announced.  I settled on the idea of a free-roaming space shooter game with that miniaturization mechanic, and that was good for multiple reasons, including:
-Multiple areas meant I could make 3 or 4 different level themes (remember my goal of showing off music)
-Since it’s a space shooter, I can get away with little animation
-Similarly, level design can be tile based
-The easy respawn idea didn’t come up until later, but that was a boon too because it meant that even if I made my game a little too hard, it wouldn’t be that much more frustrating.
One of the other advantages of making this kind of game was…

Not making a puzzle game
Now, I certainly don’t have anything against puzzle games or anything, but good gosh, last time around when I did One of a Kind I remember being extremely frustrated because I had no idea how to make good puzzles (or whether they were even possible) with my mechanic.  This time around things were much more straightforward, and as a result I never got “stuck”, except for coding issues.  Which brings us to…

What went…not so well

Framework issues
This definitely gave me some anxiety at points.  Flixel is great and I don’t regret using it, but…both Flixel itself and Flixel Power Tools definitely have some kinks.  Some of it is probably just my inexperience, but other things aren’t.  For example, the weird framerate jerkiness bug that’s solved by changing one of the condition tests in the Flixel source (thankfully I found that one while making TwinkleShooter).  I also wanted to do this cool zoomin transition effect, but I ended up figuring out that zooming out is basically impossible in Flixel without bending over backwards and/or killing performance, so I had to kill that.  In addition collision detection gave me all sorts of woes…I definitely spent way too long trying to figure out why you could glitch the ship through walls.  The unshrinking logic for checking whether you’re allowed to unshrink or not was also a pain and a mess.  And I would have liked to use FlxWeapon, but I don’t like its interface.  Of course, either FlxVelocity has a bug or I’m not using it properly (maybe i’m missing a radian/degree conversion somewhere), so when I tried to do shooting logic myself it still didn’t work until I rolled my own cos/sin calculations.  Which, you know, wasn’t hard, but it felt frustrating when the framework didn’t pull through, you know?

Level editing
This was something that was giving me all sorts of worries early on.  I had never used DAME before and had decided to go with that as my map editor (I’d heard it referenced before and knew you could use it for entities as well as map tiles), but understanding how to get it all working and exporting automagically to Flixel source was kind of daunting.  In addition, the editor is noticeably slow when working with large maps, -slightly- buggy, and generally just seems to be inconvenient for doing the large-scale maps that I was doing.  I feel like it’d be fine for small 32×32 levels, but my maps were like 200×200, maybe even bigger than that.  I half contemplated looking for another editor mid-LD, but eventually decided to stick with it.  In the end I actually got pretty used to it and it wasn’t that bad (huge wave of hope washed over me at that point), but that was definitely one of the more nerve-wrecking parts of this LD.

Biting off a little too much
I wasn’t really thinking super-pragmatically when I was considering my idea, to be honest.  I ended up pulling it off, and I’m definitely happy with the result, but it really, really came down to the line–I was still fixing bugs as the submission deadline loomed over me, and I had only finished programming the final boss about half an hour or an hour before that.  So I was really quite crunched for time–and that’s with only sleeping like 10 or so hours through the whole thing, I think! (granted I did take a break to go social dancing and rest my brain)  But yes, doing something with multiple levels, enemy types, non-procedurally-generated levels, upgrades, etc. may have been a bit too ambitious for an LD entry.  If I had chosen something smaller or simpler I might have been able to make it a little more cohesive and polished.  Still, it mostly worked out.  It’s just…I was in the danger zone, so to speak.  I also didn’t have quite enough time for playtesting.  Luckily my easy respawn alleviated that issue, but I’ve already received the common complaint that the ship could be a little smaller (in terms of both graphic and hitbox), which is something I could have  easily adjusted had I known that change needed to be made.

Art style
Now here’s an interesting one that I didn’t realize until pretty late in the game–maybe even after I submitted.  Quite early on I was faced with the decision of game resolution and zoom factor, and I ended up choosing 800×600 with NO zooming–but upscaled sprites to make pixeling easier (most of the sprites are upscaled 4x).  My logic was that upscaling the sprites but leaving the resolution unchanged would allow for smoother sprite movement, and probably a more visually pleasing effect.  What I didn’t realize is that it actually looks kind of sloppy, because you lose the whole pixely feel if your movement isn’t the same as your pixel sizes.  Plus, when you use rotations and smooth movement of pixely upscaled sprites, it just looks like some bad flash movie/game.  so yeah, maybe it would have worked out a lot better if I had chosen my resolution and zoom differently.  Maybe a 640×480 game with 2x zoom, for instance.
On the plus side, I was mostly happy with the art I managed to make, despite the fact that the resolution made everything look a little sloppy.  The bird and bee animations, for example, surprised me at how well they worked, since I’ve hardly ever drawn animations before.

What I’d like to do differently

This probably isn’t my last LD, so in the next one, I’ll probably aim to:

-Take on something of smaller scope
-Not rely on the use of any tools I’m not familiar with beforehand (DAME)
-Use a more pixely art style

I might also try FlashPunk instead of Flixel or something, but who knows…I think Flixel is pretty good, but maybe FlashPunk would suit my fancy more and the only way to know is to actually try it out and see the differences.

Alright, so that’s my portmortem report.  I’ll be following up with more detailed recountings and explanations of the development process soon…

Tags: postmortem

Pocket Strife Entry

What went right:

• Git helped me keep everything in order, and even supplied me with a gource! In a Jam, as opposed to compo, git would have been perfectly, but in retrospect, it’s a little superfluous for a compo. I would still do it, as it is really only a few extra minutes of my time, and gives me something to roll back on if need be.
• Being well rested makes a world of difference. I got three or four more times more done on Sunday when I was well rested than I did on Saturday in only double the time.
• Know your tech – using love (love2d.org) was pure awesome, as I knew the API and I knew Lua.
• Bring your own tech – I prepared for this LD by asking myself, what are libraries that one would normall find in games? These are the ones I used from the ones I brought with.
  • Build scripts for all OS’s (This was a blessing. When I was done, all I had to do was run two scripts, and I had the *.love, *.exe and *.app ready to rock and roll). Sure, mine only work on linux, but they output to everything!
  • Love Menu: There is nothing more wasteful than re-writing a god damn menu system. I wrote this one a long while back, and have used it multiple times. It looks good, and is fully scriptable. Build one giant view object, and let the library do the rest.
  • Bar lib – Again, another common element, this code ended up being a one-liner in my main.lua, but it saved so much time and looked so much better than just a random solid green bar.
• Timelapse yourself. It stops you from screwing around much
• Minimal scope is the best scope. Remember, you can always add more later, but you can’t release a game if it isn’t a game.
• Make sure the art you make can be made quickly, and with high quality – I have recently discovered that I can actually push a lot of awesome pixel art out, as long as I only use two bit graphics (4 colors) So I open up GIMP
• Don’t waste time generating! Making some crap from scratch when you don’t need to is probably a big waste of time! ALl you need is a few cases to make something seem random, why does it actually have to be random? I used this fractal world generator five times, http://donjon.bin.sh/world/ and used that as the map system.
• Forget performance, call it a feature, not a requirement. You won’t believe the shortcuts I took to make this happen, but in the end it goes back to knowing your tech. I wouldn’t have had any of these issues if I had know how to do isometric tiles correctly. Reducing the framerate should have come later.
• Stop bitching, and get working! Seriously, I saw so many people wasting time on IRC bitching about the theme. The themes LD gives are so vauge, you can do just about any thing you want. Oh, folks, stop naming your game “Tiny World” please.

What went wrong:

• Know your tech. Working with isometrics was a god damn horror, and caused 95% of my framerate and mouse issues. Use concepts you are used to. This is not a time to learn new tech, this is a time to produce a game you know how to make. In retrospect, I should have made this game in straight 2d tiles.
• Plan more! I should have planned for another hour or so. I found myself making the game up as I went along, and when I started noticing I was making assets and code that were out of scope, and then later removing them, I had to sit down with my notes again, and decide what the hell I was actually going to do
• Make your machine ready for you. Have your stuff built, make sure it’s up to date, and stable. I had about fifteen minutes to rebuild love 0.8.0 from tag on ubuntu 10.04 (and keep in mind, it doesn’t build if you are running 10.04, so you have to do some hackery)
• Kittens don’t let you code much. They seem to think everything in your monitor is real, and your keyboard is for sitting on.

Conclusion:

What this showed me is to participate even if you don’t have time! I did this entire game in 13.5 hours.

Pocket Strife Entry

Tags: kitten-challenge, ld23, motivation, post-mortem, postmortem

I was able to polish this game up quite a bit before the jam deadline last night. Maybe the power and internet outages that prevented me from submitting it to the compo were a blessing in disguise:

This is my first HTML5 game, but it appears to at least be working in the latest versions of Chrome, FireFox, IE, and Safari! Please let me know what browser you are using, if you run into any problems. I think that the magic abilities could use some balancing, but otherwise like the simplicity of the game. Try it here: http://sugarpillstudios.com/games/WorldofdesTiny/ and leave feedback here.

Play now

Post-mortem

Really enjoyed the theme this time round. I had a clear idea of what I wanted to make right from the outset. The game was originally intended to be a bit more of an RTS, but I ended up shoehorning in some more arcadey elements so that the whole thing was a bit more “gamey”. As a result the game ended up being kinda frustrating and stressful to play.

I’m going to be working on a updated version over the next few weeks, reworking the gameplay to focus more on building and calm fun, which will hopefully include:

• Originally I had the option to scroll between the different layers (surface, aquifer, rock, magma etc.). I’m planning to re-implement that and allow subterranean mines and magma forges!
• The ability to build gyropters and send them to explore other floating islands
• I’m going to redesign the combat element of the game, so that you can construct turrets for defence and so that the attackers are more varied and less overwhelming
• Reworked GUI and controls
• I’ll probably also get rid of the “hover over resources to collect” mechanic

TLDR
Post-compo version coming.

 
Play! Vote!

Just a quick post to let you know that we’ve added an HTML5/WebGl version of our Jam entry “My Little Dungeon”. Click through to give it a whirl: My Little Dungeon

We’ll write up some more about the whole making process when we’ve had some more sleep. Thanks for checking the game out and we’re looking forward to playing yours!

Fedor and I made this completely from scratch in three days (with little sleep):

http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=13139
We’re proud of it and couldn’t wait to show this off to you guys! Please spread around, rate and comment

I will now attempt the daring feat of sharing what this experience felt for me, so we can all benefit from it as game designers/developers/artists.

Development notes:

It was exhausting and super fun. I particularly enjoyed composing the music, and how we came up with an interesting gameplay mechanic (teleportation).
Coming at it as equals and negotiating ideas did a world of good for our game. Our main inspiration was the Touhou series of games for Fedor (I’d only seen gameplay) and Ikaruga for me (finished the game several times).

I started doing graphics on Saturday morning. I worked on a mockup photoshop file full groups of layers, to which I returned throughout development. For example, when I needed a new enemy, I would fire up the mockup, draw the enemy next to all the other sprites and then paste it into another photoshop file and animate it separately. I would then export as individual .PNGs (Photoshop’s “Render Animation to Video” was very helpful).

Dropbox of course saved our lives, and we communicated through skype’s chat. In fact we haven’t even seen each others’ faces.
I used Photoshop CS5 for all animation and graphics, and Fruity Loops with free soundfonts to write and perform the music.
Fedor used Unity and I don’t know what else ^-^

Post mortem: We gave it our absolute best. A coding set-back made the scrolling clouds unusable, so Fedor had to wing it at the last moment, which left the background a little bleh in my opinion ( I had no time to make changes to the cloud graphics and scrolling). But even so, when at the last minute he managed to fix the clouds so we at least had some, it was very exciting. The level is very very well thought-out and very fun to play. It took Fedor, what, 6 hours? to come up with the patterns that complement the teleport mechanic.  The 3 hours before deadline were, for me, mostly about helping Fedor out with any requests, like changing sprites or giving him a list with all the visual elements he had yet to implement. I made a second enemy ship graphic in 15 minutes, since Fedor made enemies with two different numbers of hit points, and I felt we needed to be able to tell them apart. This was done 2 or 3 hours before deadline, when Fedor was struggling with the stupid clouds. He added the second enemy graphic in the game 1 hour before deadline.

I also wanted finite lives implemented (9 of them, as many as the tails of the Kumiho fox-spirit), shown only everytime you are resurrected from a death, in order to keep the interface as clean as Fedor wanted it. Scoring wouldn’t have hurt either. But we didn’t have time to even negotiate it, because the ideas came too late. Even if they had come early, we wouldn’t have had time. I stayed up Sunday 12am to Tuesday 6am, and it’s the longest I’ve ever been awake.

So, overall, I couldn’t have wished for anything better, I had the fastest and best coder at my disposal, we had a crazy schedule and working hours, and implemented almost everything we set out to implement, and still had time for a little polish.

Tags: 2D, final, game, ld23, pixel, pixelart, post-mortem, postmortem, Postmortem SuccessStory, screenshot, success, success story, SuccessStory, unity

Hello! I’ve just fixed the download link on the LD page for my game for all that are interested.

For my first Ludum Dare, I made Save Your Planet!  I enjoyed making this far more than I thought I would.  Since everyone seems to be doing post-mortems, I figured I shall do the same.

What went right

• LÖVE is great!  Lua is…alright, but LÖVE is great.  I don’t think I would have gotten this done without LÖVE.
• The music too far less time to make than I thought it would.  I normally get super anal (ha!) when I sit down with my bass/guitar and record stuff.  Time constraints are handy, it seems.
• sfxr + Audacity allowed me to make the audio with a quickness.  I think I only spent 20 minutes at most on sounds.  The audio could have been better, though.
• Even though the theme wasn’t my favorite thing in the world, I was able to think of something to make and come up with a plan within my first hour.

What went wrong

• I didn’t think I was going to finish at all (I’ve never actually finished a game before), so I didn’t put more effort into it.  What can I say?  Arrested Development won’t watch itself.  This filled me with regret when I had 12 hours left and something that could actually be submitted.  I only worked on this for 20 of the 48 hours.
• Art is hard.  I’m just not very good at it (yet?).  I didn’t spend enough time working on my art skills before the start of the Ludum Dare.  Not only is the art less than optimal, it’s a bit inconsistent.
• The start of Ludum Dare fell on the same night as a Cake concert!  And I don’t have a smart phone, so I didn’t even know the theme until I got home 3 hours later.
• I didn’t get a chance to add everything I wanted; e.g., power ups, more enemies, a tutorial that isn’t just a screenshot with text on it, and an actual victory screen & music.  The lame victory screen I added is just the game over screen, except instead of “Game Over”, it says “Victory!”.  Weak sauce.
• I had a nice plan as to how I’d organize all my code.  That plan fell apart during the last 6 hours, and my code got really ugly.  I guess that’s to be expected.
• I really wish I remembered to think of a better name than “Save Your Planet!”.

I’m definitely will be doing LD #24, and encouraging others to do the same.  Have you played my game yet?  You should.

Hello everyone. This was a fantastic Ludum Dare for me and I wanted to share a postmortem for my game, NanoBot Adventures. All in all, this was a pretty good game jam for me. 

Here’s a link to my game:  http://www.ludumdare.com/compo/ludum-dare-23/?action=rate&uid=4263

The Good

Using Legos to build my NanoBot sprites worked out really well. My sons love playing with Legos so while I worked on the game, they built an army of little Lego robots. I picked my favorites, setup an impromptu white backdrop and used my cellphone camera to take pictures of them. I wanted the graphics in the Viewport to have a bit of a grainy, pixelated look to them so I took the original images and in Paint.Net I cut out the white backdrop, saved the file as an extremely low-quality JPG, reopened the file and cut out the white background so I had a transparency again and resaved it as a PNG. This process worked out so well that I will be using it again in the future.

Another good thing was my HTML5 canvas framework. I wrote it a few Ludum Dares ago for the Escape theme and it has served me well. I use JQuery for the UI pieces and it has a very basic Update/Draw game loop. I am planning on sharing it on Github in the near future once I get the basics for music/SFX put in as well. Follow me on Twitter (@mattperrin) or follow the #LD48 Twitter tag and I’ll put it up there.

Another good thing was that my local community of game dev friends (www.clevelandgamedevs.com) really came together for this event. We had a LD kickoff event at a local start-up incubator and collaborated for a few hours Friday night together before splitting off. To keep in contact with each other and show progress, we setup an IRC channel that was used all weekend long. Seeing my peers working helped keep me committed and interested too.
The Bad

I still haven’t gotten sound or music working in a LD game. I tried with this one but I couldn’t quite get it to work properly. I used Caustic on my Android phone to create a chiptune-esque drum and bass song. When I connected my phone’s headphone jack to my laptop’s microphone jack, I either got an ear-splitting loud feedback tone or a barely audible recording of the song. Caustic has a song export feature that I used to make an OGG file but when I tried to get it looping in my game it wouldn’t play. After all of those headaches, I decided to skip trying to do sound all together and focus on some UI polish.

I never got around to adding power-ups or boss fights. I had wanted the exploration of the “tiny world” to be a bit more dynamic. Visiting the Capacitor Forests, Resistor Swamps or LED Ruins was supposed to trigger dynamic events like boss battles, upgrades or NPCs with storyline clues. I ran out of time though and only the basic quest of “Find the broken CPU Chip” were completed.

The Ugly

The Draw calls I use to make the minimap are extremely inefficient. Instead of having a global frame counter and incrementing across the pixel color arrays for each TerrainGameObject I instead have individual frame counters in each TerrainGameObject that are incremented during the Update call. For the glowing circuit traces, I used the X coordinate of the tile to offset the pixel color arrays so that’s how I get the shifting glow effect. Kind of cool to look at, horribly executed by me. The reason I went this way was because as part of the boss battles I was going to have the minimap change to become more “alive” as you beat them. LEDs would start glowing again, resistors/capacitors would generate more circuit traces.

I should have added arrow key buttons to the UI instead of relying on only the keyboard arrow keys. I could have then added Touch Events to those buttons allowing for the game to be played on mobile/tablet devices as well.

Issues with sound and my family took up way more time than I intended. I used Chronolapse to make a timelapse of my work and the amount of time lost dealing with squabbling kids or just “being a Dad” are clearly shown. I’ll be posting this video sometime this week (I’ll share on Twitter) . I think I maybe only got to spend 20 hours or so on the game as a whole.

Tags: ld23, post-mortem, postmortem

Yey my second Ludum Dare Compo has finished and here is my result:

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

With Android

Timelapse:

http://www.youtube.com/watch?v=Kkqk_ej_lMU

I know … a bit late to for this Post …  but i had a lot to do

My microgame Tiny World Adventure is now available also for Windows. Enjoy!-)

Note: Ingame editor (unlocked when game is finished) is not yet available on Windows version (OS/X only) .

This microgame can be finished in few minutes. Longest time since now (played by one of my friends) is 10 minutes. 😉

Tags: Mac OS X, NE-VM, Tiny World Adventure, Virtual Machine, Windows

Ahoy there, thanks so much for joining in the 10th Anniversary Ludum Dare! I gotta say, it was an amazing experience to see all 1400+ entries being submitted to the site!

The judging is pretty much the same as always. You judge entries, people judge you.

The big change this year is that now those who judge more entries will get more people judging their entry. I recommend starting judging a few entries now and keep judging them throughout the next three weeks to ensure your entry gets a good handful of ratings. Try to judge AT LEAST 25 entries. Please note that stuffing fake ratings is 100% uncool.

Also, coolness has changed: 50 ratings gets you bronze. 75 gets you silver. 100 gets you gold. Above that, you’re just awesome Be sure to make a post about your favorite entries to highlight the best-of-the-best!

Lastly, if you attempt to play an entry, but can’t, please just leave a comment to the user stating that you can’t judge their entry and explain why. “I don’t have a Mac” or “I can’t install Java” or whatever are all fine reasons. It will help them know how to create an entry that even more people can play next time!

Cheers!
-Phil

Joe The Alien Titlescreen

Hey guys!

I’m Robert and I live in Austria. This is my first LD I have participated and it went quite well I think. I read about the LD and decided spontaneously to give it a shot. I programmed 20 hours (nearly) nonstop and I think it was worth it. I know a 2,5D platformer isn’t the easiest game you can make but I love these kind of games and I wanted to make something with 3D graphics.

Originally the game was called “JoeTheAnt”… but I failed at modelling a reasonable ant, so I decided to make an alien out of the current “ant”. Luckily I made the model very early in development so it was no problem to change it. Then I implemented the key features: Map (drawing, loading, decoration, etc.) player (running, jumping, collision, …) , the enemies (the bug and the mushroom (in code it’s considered as an enemy because originally it was considered to be moving…) and some extra goodies (intro, outro, “tutorial” system, etc.). This took around 12 hours.

Then a strange bug occured… The game crashed with no pattern. It just crashed at a random position. The debugger didn’t help and so I was only able to remove code test… because there was no pattern it was just guessing… after 5 hours of trial and error I fixed the problem (I hope I fixed it…). Then I created the seven maps and tested them and the very last step was adding some (annoying) sounds and test it again. Yeah then I had the finished game and I uploaded it 6 hours before the 48h competition ends.

Which tools?

• GLBasic for programming
• Milkshape 3D for modelling
• Paint.NET and Photoshop for sprites and textures
• sfxr for sounds
• calc.exe for minor calculations

What went right?

• The key features were no problem, Got them working in a reasonable time
• Graphics – Not the best but I did my best. And I think for 20 hours it’s okay.
• The game is finished as it is – It has a beginning, ending, 7 maps and some “extras” I wanted (tutorial system, intro, etc.)
• I had no time issues

What went wrong?

• I should have planned a little bit more (planning took around 5 minutes…)
• Sound/Music effects are awful… I have to learn to do better.
• Some minor problems (bugs, focus on important features, …)

I hope you like it and give it a good rate 😀 http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=11847

This is the Post Mortem for the game A Gigants Tale.
We finished our game yesterday and was able to submit on time!
If you want you can try it here: http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=8389

Timelapse of the development : http://youtu.be/r2fmhVxA-EU

What went well:
>>We came up with an idea fast and we thought it would fit the team in it’s own way.
>> We managed to do all the things we wanted for the games.
>> We all knew our software well and progress was made fast.
>> Coding went well.
>> Managed to finish the game in time!

What could have gone better::
>> Started earlier! Too much real world stuff going on!
>> Create more depth for the game.
>> Better communication among the group!

We think that this was an really exiting event we enjoyed our selves very much!
We are happy with the outcome of the game and we are allready looking forward to the next LD!

-DalsGames

This will be a pretty light post mortem, as I only released what amounts to a prototype. I had only some of Friday night and some of Saturday to work on the game, so I focused entirely on just getting something playable out, sans audio and niceties.

My entry page is here.

Because my game itself is pretty short and doesn’t have much in the way of mechanics, I’ll begin instead with a description of my process, how I managed to get “at least something” out in about 7-8 hours work.

0 Hour: Tiny Worlds

This wasn’t my favourite option on the list. I had mentally examined the theme choices and mapped out some game ideas before the reveal, but I didn’t have anything solid for Tiny Worlds. My first thoughts involved ants, maybe an ant tower defense. I figured the first few ideas I came up with would be the most common so I tossed them.

First Concept

Working on the angle that planets themselves would be tiny, my first real concept was a simple RTS, where you controller a massive planet harvester. It would slowly eat planets but have no defense of its own, instead building defense ships. As you eat planets with the ship, you gain score. You build defense ships to make it easier to survive planetary defenses, but use resources to make them, lowering your score. Strategy being to limit the defenses you have to just what is needed to keep a higher score, managing the risk vs score.

I still think this is pretty interesting, really. But knowing I probably wouldn’t have a lot of time on the weekend, I tossed it for something simpler.

Earth Is Dying!

Keeping the focus on planets and resources that must be balanced, I changed my focus to a simulation. Still real time, but requiring no fancy pathing or a large number of mechanics. Now you are in our solar system, and Earth is quickly running out of resources due to a massively growing population. You must evacuate as many citizens to neighbouring planets as you can before Earth is completely dead and everyone along with it. Oh, and you have, like, 3 minutes.

What Went Right

• Got my concept down in about an hour and a half
• I finished my basic game prototype (but really only that)
• The time I did have was spent pretty effectively
• Tooling: Unity is fantastic for fast iteration.
• Almost no artwork: Almost everything was just a sphere or cylinder in Unity, with a set colour. Only the Rocketship was modeled. I’d never used Sketchup before so it took me about an hour to get even that simple model together
• Actual gameplay seems like it could be interesting, if expanded
• Mercenary approach to design: Include only the very, very basic necessities, expand only when it’s clear it’s needed
• I actually released something, and seeing peoples comments is extremely rewarding, even though I’ve only a few ratings yet
• Scale of the solar system mostly maintained, visually interesting, simple and smooth controls

What Went Wrong

• Did not have the whole weekend to work. This cut out the graphic polish and audio features entirely
• Balancing is hard. I had a number of variables to tweak to keep the gameplay pace and difficulty, I’m sure it could be better
• Not much in the way of a GUI
• Needed more mechanics to be truly interesting

Release

On Sunday I finally uploaded my windows build and my source. I can build my game for OSX (or Flash, but Unity builds require no dependencies anyway), though I only link a windows copy. My source is also available, just under 400 lines of C#.

Overall, a very fun experience. I’m really looking forward to the next Ludum Dare now! I may take a look at the MiniLD’s in the meantime.

Tags: earthisdying, post-mortem, postmortem, SketchUp, unity

I took a while to get to this but here goes. I’ll keep it short since I don’t have a whole lot to say, and we’ve all got a rather large number of games to vote on.

This is now the third LD48 I’ve participated in, but only the first time I’ve been able to finish a compo entry. Usually my lack of staying power is either due to time constraints, or in the beginning poor knowledge of my tools. This time around, I was firing on all cylinders. On that note, let’s analyze what went right.

1. Theme. This worked for me. I had been mulling over the idea of an ant colony game a few months ago, and took the time to do a bit of research into the little critters. This led to the central mechanic of the game, not actually controlling the ant, but rather controlling one of the “standard bearer” ants using pheromones to lead the other ants to an objective. This was in no small part influenced by the units in Darwinia.
2. Tools. This could have gone either way, and fortunately it worked out. Reason being, about 3 weeks ago, my computer died. Harddrive started to die and fortunately I managed to rescue my important files before anything happened to them. But the thing was already a write off (kind of a franken-netbook, NVIDIA ion mobo with a dual-core Atom. Looked great in the shop, but got her home, not so much) so I reallocated some of the hardware budget this year for a Mac Mini. Trial version of FlashBuilder took care of my IDE since I couldn’t get Xcode to do it properly in time (not giving up on that one just yet) and found a nice little pixel editor in Pixen that was nice and easy to work out so no impediments there. I used Flixel, and while there are still many aspects of the the framework I don’t use, my knowledge of it is now adequate to streamline everything nicely.
3. Confidence. This is a big one. From the very beginning, I maintained that I would finish and deliver a game. I went in with the knowledge that I may have to cut features that I didn’t have time to complete, but it wouldn’t detract from the overall product. I think testament to this is the fact that I hit my first roadblock about 13 hours in, decided to go to bed, but came back after a few minutes away and figured out the problem. From that time on it was a steady journey.
4. Interaction. This could have been better, but it was not bad. I maintained a journal of sorts on my blog, complete with progress videos of what I had achieved up to that point. I think this also helped with the confidence, since it was something I could see as concrete evidence that I was progressing, plus there was a sense that other people were watching too.

There’s probably a few other plusses in there, but I’m going to venture that they fit into those main categories.

Now for what went wrong, and how the game failed to deliver a quality product.

1. Style and Polish. I’m making this purposefully vague, because for me it encompasses a number of deficiencies. I don’t like to think of myself as “not the artistic type”. The mindset implies that the inability is out of my hands and nothing will change this. <geek> Neji vs Rock Lee for the Naruto fans out there </geek> Ok, got that out of my system, but it’s true. Where I’ve failed on this front is to actually do something about it. I should be making pixel art in my spare time, I should be playing around with synthesizers and music generation software to get my skills up. I’ve done it with my programming skills (and there’s still room for improvement there, to be sure), now I need to do it with my creative side.
2. Fundamentals. The comments on my entry are pretty consistent as the to the level of Feedback in the game; basically there’s none. What is there was hastily tacked on in the last minutes before I submitted. Due to time-zone realities, I lost the last 6 hours of the compo; I live in Japan and start at 10 am saturday, but finish at 10 am monday. And a scheduling incident meant I didn’t have this monday off. So, I wrapped up at 4 am and tried to get a bit of sleep. I don’t think staying up any later would have made a difference, but it’s possible that if I had slept sunday night and did some work early monday, it *could* have been different. None of this of answers the core issue, and that is that the feedback and readout mechanisms were not included from minute one.
3. Time management. Somewhat related, but there’s enough here to make a separate point. At a couple times, I spent too long working on a non-essential bit only to have to rip it out and toss in some jury-rig to let me move on to my next objective. Most of these incidents came later as I got too tired. Having a somewhat flexible plan before sleep-dep kicks in would have worked better.
4. Too much coffee. I love coffee. I really do. You can have your red bulls and monsters and whatnot (although I do love me an Oronamin C every once in a while..), give me coffee. And I’m not talking Nabob or Nescafe or any other that, or even Starbucks triple-dopio-mochi-whapaninos, but a french-press-made-to-the-consistency-of-battery-acid brew. This had two major (negative) side effects; caffeine crash and burn is nasty, and my stomach has had a passionate loathing of me for the last two days or so. There’s no way I’ll be ruling this out of future endeavors, but pacing. Pacing.

So, there you have it. My first post-mortem for my first complete LD. If you’ve made it this far, thank you for your patience. If you’ve read all this and played the game, you are a champion. Pat yourself on the back.

I hope the LD admins don’t mind me collecting this information but it’s painful to go through individual “I’m in!” posts to collect it. I thought this might be an easier approach:

What tools did you use for LD23? (Google Forms)

I’ll start with the part that’ll interest more people….now that I’ve rated 150 entries, here are my top 7! (in no particular order)

Bottlecolonies By tcstyle : A clever little strategy/puzzle  game, the art direction is great, the sound both fitting and awesome, and the gameplay itself is solid and complete…a joy to play

Nanofactory By JustinMullin: A solid puzzle game about a nanobot assembling widgets, a little hard and cryptic at first but the puzzles are both simple and clever

ANT SURF HERO: THE SURFENING By Jigxor:  A refreshing change from the massive number of dull uninspired platformers,  aside from a few physics issues it’s really fun,  and riding on top of the ant is amusing to say the least.

Housefly By dacap: You play as a fly on a mission: to get back outside!  It’s a short but very immersive adventure game with solid controls, great visuals and sound…its hard to describe but the flight control feels “right” for a fly. Very fun.

Recluse By chambers: You play as a snail with a neckbeard in a “metroidvania” type game….but with a twist.  Easy 5/5 for innovation personally, I don’t want to ruin it by the starting room is misleading and it quickly introduces one of the most unique gameplay mechanics i’ve ever seen. (even if it is mostly a gimmick…it fits the theme very well)

Hero of Rain By 31eee384: Extremely incomplete but what there is of it is very enjoyable, the story is both fitting and interesting, the gameplay is for the most part pretty good (though touchy at parts). All around a good feel to this game.

Fusion Time! By NeiloGD: A simple but solid arcade-type game where you fuse atoms in a sun.  Theres not much too it but the explosions and strategy of timing the fusing makes it surprisingly fun to play.

Please try these out if you havent! Most still have a pretty low number of ratings and could use some more love! Also, <shameless plug> I really wouldn’t mind a few more tests on my entry as well, it’ll be linked below with the timelapse and postmortem</shameless plug>

Post-Mortem:

First off, here’s the link, try it out yourself and let me know what you think!

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

I have to say…I had more fun with this theme than I would have thought, it was a lot easier to make a game that fit the theme but was still….you know…a GAME..than it was for “alone” (LD22)

What went right:

•  My game Idea! I came up with it MUCH faster this time and IMHO it’s a much more fun game than my 22 entry
•  My cross-compilers were already set up, saving me a lot of time testing the windows build
• Using my sprite editor (listed in the tools section to the right) I was able to do what little spriting I needed very quickly with decent results, it was MUCH easier than trying to do it in GIMP (great editor….not so good for animating)
• I planned fairly well what I would have time to do,  I was complete (though had to cut a few units) and able to submit before the rush.
• Deciding early to render with opengl instead of plain SDL was a good call,  I ended up abusing it quite a bit to scale/recolor graphics & text (SDL can do it but it’s so slow it would be near unplayable..).  Having recently written a LOT of OpenGL code also it was pretty fresh in my mind and I was able to painlessly get it up and rendering.

What went…welll…not quite as right:

• Once again, LD fell on a weekend I had to be gone quite a bit, I wasn’t home on saturday till nearly 6pm, so I lost a good 18 hours of copetition time there (seriously, i had NOTHING planned that couldn’t be moved for like.. a month prior and a month after…only that one day)
• I had to take care of some stuff outside friday and was EXHAUSTED after the theme was announced, ended up losing even more time by going to bed early. (though i did finish a opengl renderer + sound system before then)
• I had a OpenGL/SDL/Angelscript based game engine I’ve been working on for quite some time that I was going to use so I could concentrate more on game code….unfortunately I had some last minute issues and there was no way I’d get a windows build of the engine working in time, so I had to change plans and just write a renderer/sound/input engine from scratch during the competition.

And of course, here is the timelapse video! (with soothing music added)

Tags: ld23, linux, opengl, post-mortem, postmortem, SDL

Play and rate

Tinyville Confidential is my submission for LD 23. It’s supposed to be a puzzle game in which you have to optimize the arrangements of houses in this small town, but with the dynamic element that the residents keep changing who they want and don’t want to live next to. Somehow this game ended up both less finished and less fun than my LD 22 game, even though I had more time to work on it. Here’s what I think went wrong, and what I learned.

Probably my biggest mistake was trying to make a complicated game (to create, not to play.) Ludum Dare is a good chance to try weird games, but only if you can actually finish them in time. For my next LD I’m going to try my hardest to pick a super-simple concept so that I can submit a complete game in 48 hours, instead of an incomplete game in 72!

I also spent a long time on the wrong things. I wasted a lot of time trying to make a complicated method for the people to walk around town, but choosing a direction randomly ended up working fine. The graphics also sucked up too much of my time, and I didn’t even get a chance to add flowers and other scenery. Instead of making each element look as good as possible, I should have made them all look pretty good and moved on.

I really learned a lesson about getting enough sleep. I stayed up most of Saturday night, since I wanted those extra 6 hours for my game. This might be a viable strategy for something that’s due in the morning, but the result in this case was that I spent all Sunday sleepy and grumpy, which made working on my game seem more like a chore than fun. So, I’m definitely getting enough sleep next during the next LD!

What went right? Well, watching the people in the game interact and reading the newspaper is pretty fun! If I do have a chance to refine the puzzle aspect (maybe give unlimited time for the puzzle part, and make it more clear where there are conflicts) and add multiple levels, etc, I think this could be a good game.

It’s kind of late, but here’s my game: PLAY IT

And here’s my time-lapse, which i just uploaded: WATCH IT 

About time I got py2exe to work. Help yourselves.

Edit: about time I got links to work too

Continuing in the glorious tradition of timelapse recording my entries, this time with a much better framerate.

I did most of the development of my entry on a laptop while at a dance workshop weekend (as a tech/helper, I had a lot of free time), so sometimes I am off doing things and the timelapse freezes on one image for a few seconds.

But if you’re interested in seeing me draw my “art”, watch away!
(I accept no liability for any eye bleeding that may occur while watching my art skills)

Entry
Post-mortem

Tags: timelapse

(faire défiler pour la version française/for french version scroll down )
I had several comments and feedbacks saying that Tinyvilization lacks comprehensive gameplay. It’s not hard but my in game instructions are pretty minimalistic : I’m sorry, it’s my bad. To make it up, here is a “how to play” instructions to help you enjoy the deep gameplay proposed by this game !
Have fun !

How to play (quick start quide)
(Don’t forget you can display User Interface Help by pressing any key)

[stextbox id=”grey”]Game rules

– A game last 2000 mounts
– Each action cost time in months to the settler/apprentice; the cost is showed on each action.
    Note : The time is consumed even if the action fails.
– Each city gives one point to the owner by the end of the game.
– The higher score win.

 Starting

1. Plan your strategy

– Click on actions in the upper right box to add them to your “Setup” command list.
– Click on “Development” box to place cursor.
– Click on actions to add them to you “Development” command list.

2. Start

– You fight by default level 1. See how it goes.
– Changes of strategy during game resolution are not allowed: they have not effect on current game.

3. Retry

– To reset field and prepare your next strategy.
– Click start again to try your new strategy.
– Repeat until you beat your opponent.
– Click on “level 2” to play against “level 2” strategy.

 To play against a friend strategy/an easier strategy /a harder strategy:

– Get the strategy code (some codes are available in the strategy guide).
– Copy/paste it in the import/export textbox.
– Click “fight strategy” at the bottom of the screen.

To keep aside you current strategy

– Click « export » button (it copies the code in the clipboard).
– In your favourite text editor: use ‘paste’ (ctrl+v) to place it.

 To retrieve an other strategy (of yours or someone else (to study it))

! Doing this overwrites your current strategy

– Get the strategy code (codes in the strategy guide, code saved in your text editor or code given by a friend).
– Copy/paste it in the import/export textbox.
– Click “use strategy” at the bottom of the screen.

 Actions specifications (from upper left to lower right)

Move forward

– The founder or apprentice move in the place it is facing.
– Action fails if someone is already there.
– Action fails if an enemy city stands there.

Turn left

– The founder or apprentice turns by 90° counter clockwise.
– Action can’t fail.

Turn right

– The founder or apprentice turns by 90° clockwise.
– Action can’t fail.

Raise a city (at this place)

– If there is no city, raise a city Level 1.
– If there is a city, increase city level by one (max 5).
– Action fails if city is level 5.
–    Note: A city is represented by a square. The bigger the square, the higher the level.

Convert a city

 – If there is an enemy city in front of the founder or apprentice, try to convert the city to become ally.
– You need as many attempts as the city level. (ie: 4 attempts for a level 4 city to convert it)
– A converted city became ally but lose one level.
– A converted city has his conversion counter reset.
– Action fails if there is not enemy city in front of the founder or apprentice.

Train an apprentice

– The founder or apprentice trains a new apprentice which will apply the exact same strategy (“setup” once then loop “development”).
– The new apprentice starts when the place is free.
    Note: Founders are apprentice are distinguished for the settling background. Their behaviour is strictly identical.
    Note: apprentices waiting the place to be free are displayed by a small circle.

[/stextbox]

[stextbox id=”alert”]Version Française[/stextbox]
J’ai eu des retours comme quoi il est difficile de jouer à Tinyvilization. Ce n’est pas si dur mais les explications que j’ai mises dans le jeu sont assez succinctes. Pour me faire pardonner, voici un guide de démarrage pour vous permettre d’apprécier le gameplay profond que propose ce jeu.
amusez-vous bien !

Comment jouer (guide de démarrage rapide)
(N’oubliez pas que vous pouvez avoir l’aide de l’interface (anglais) en appuyant sur n’importe quelle touche du clavier durant la partie)

[stextbox id=”grey”]

Règles du jeu

– Une partie dure 2000 mois
– Chaque action dure un certain temps exprimé en mois pour le colon qui l’exécute.
    Note : Le temps est consommé même si l’action échoue.
– Chaque ville donne un point à la fin de la partie.
– Le meilleur score l’emporte, vous n’êtes pas obligé de tout conquérir.

Démarrer

1. Plannifiez votre stratégie

– Cliquez sur les actions en haut à droite pour les ajouter dans la zone “Setup”.
– Cliquez sur la zone “Development” pour y placer le curseur.
– Cliquez sur les actions en haut à droite pour les ajouter dans la zone “Development”.
    Note : – Les actions “Setup” sont exécutées une fois par chaque colon.
                 – Les actions “Development” sont ensuite exécutées en boucle par chaque colon.

2. Lancer la partie

– Vous affrontez par défaut le niveau 1. Il n’est pas facile au début, observer votre évolution et la sienne.
– Les changements de stratégie en cours de route ne sont pas possibles. Vos modifications n’affectent pas la partie en cours et ne seront effectives qu’à la prochaine partie.

3. Réessayer

– Cliquez sur “reset” pour réinitialiser la grille et préparer votre nouvelle stratégie
– Cliquez sur “start” quand vous êtes prêts à réessayer.
– Répétez ce scenario jusqu’à batter votre adversaire.
– Cliquez sur “level 2” pour affronter la stratégie du niveau 2, etc.

Pour jouer contre la stratégie d’un ami, une stratégie plus dure, une stratégie plus facile :

– Récupérer le code de stratégie (des codes sont dispo dans le guide stratégique).
– Copier/Coller le code dans la zone de texte en bas à gauche de l’écran.
– Cliquer sur “fight strategy” (Affronter la stratégie) en bas de l’écran.

Pour garder de côté votre stratégie actuelle

– Cliquer sur le bouton « export ». Cela équivaut à un « copier » de votre code stratégie.
– Dans votre éditeur de texte préféré : faites « coller » (ctrl+v).

Pour charger une stratégie à vous ou à quelqu’un d’autre (pour l’étudier)

!  Note : Cette manipulation va remplacer votre stratégie actuelle et elle pourra être perdue

– Récupérer le code de stratégie (dans le guide stratégique, auprès d’un ami, ou sauvegardée dans votre éditeur de texte).
– Copier/Coller le code dans la zone de texte en bas à gauche de l’écran.
– Cliquer sur “Use  strategy” (Utiliser la stratégie) en bas de l’écran.

Détail des actions (de en haut  à gauche vers en bas à droite)

Move forward (Avancer tout droit)

– Le colon avance d’une case vers l’avant.
– Échoue s’il y a déjà quelqu’un.
– Échoue s’il y a déjà une city adverse.

Turn left (Tourner à gauche)

– Le colon tourne à 90° dans le sens inverse des aiguilles d’une montre.
– Ne peut pas échouer.

Turn right (Tourner à gauche)

– Le colon tourne à 90° dans le sens des aiguilles d’une montre
– Ne peut pas échouer

Raise a city (Construire une ville)

– S’il n’y a pas de ville, construit une ville niveau 1.
– S’il y a une ville, la fait progresser d’un niveau  (max 5).
– Échoue si la ville est déjà niveau 5.
– Note : Une ville est représentée par un carré de plus en plus gros en fonction du niveau.

Convert a city (Convertir une ville)

– S’il y a une ville adverse en face du colon, il tente de la convertir pour qu’elle devienne alliée.
– Il faut autant de tentatives que la ville à de niveaux pour réussir. (ex : il faut 4 tentatives de conversion pour rallier une ville de niveau 4).
– Une ville ralliée perd un niveau.
– Une ville ralliée voit son compteur de conversion remis à zéro.
– Échoue s’il n’y a pas de ville adverse en face du colon.

Train an apprentice (Entraîner un apprenti)

– Le colon entraîne un apprenti qui apparaitra au même emplacement et suivra la même stratégie (« setup » exécuté une fois puis « development » en boucle).
– L’apprenti apparaît quand la case est libérée par son formateur.
  Note : les termes foundateur, apprentis et colon sont différenciés dans le contexte de colonisation d’une nouvelle terre, mais ils représentent des entités identiques dans le jeu (même apparence et même comportement).
Note : un apprenti qui attend que la place se libère est représenté par un petit cercle.

[/stextbox]

My entry tr-3012 is primarily a musical instrument, a drum machine with five independent looping triggers identified by robots.

This time around I did a lot better at removing code that wasn’t necessary and dropping ideas I wouldn’t have time for. I had all of these digitized robot voices recorded that my five year old loved but which didn’t really make the game any better.

One thing I regret not having time to implement was an introductory zoom from outer space into the playing grid, to make it look like the robots were isolated and adrift in space. That would have helped fit the theme better.

The tools I used:

Processing
Piccolo2D
Piccolo2D library for Processing
Beads library for Processing
Garage Band
Animoog
Audacity
TAL-Dub-2 audio unit plugin
GIMP

I plan to add a few new features to tr-3012 later, to make it more useful as a musical instrument

– allow user-provided samples
– external MIDI sync, or at least set a tempo in BPM internally
– send MIDI and OSC events in place of/in addition to playing samples

Tags: animoog, audacity, beads, garageband, GIMP, java, post-mortem, postmortem, processing, tips

I’m getting lost in these games. I have so much work to do but all I can do it play play play! So many games, so little time!

(Cross-posted on my blog @ blog.cr0ybot.com)

It’s now two days past the end of the Ludum Dare 23 48-hour compo. I had to take two days to recuperate before attempting to write about it.

I would say that my first Ludum Dare was a success. I’m not particularly thrilled by the game I came up with; it’s not about to change the world, but that wasn’t the point for me. I did it. I made a game in 48 hours. It’s possible. It’s also really, really hard.

I almost sat LD 23 out to wait for the next one. Too many things to do over the weekend, not enough time. I also had serious doubts about my own abilities. I’ve never come up with any game idea and also executed it within 48 hours before. It’s just not possible. I’ve only made a few games by myself in the past, and they took months. But when the hour arrived, I said to myself, “What have I got to loose?” and got to work. I was only vaguely aware that the answer to that question was “sleep, nutrition, and a little bit of sanity.” But it all worked out.

Nearly all of the first 24 hours was spent simply coming up with a game idea in response to the theme, “Tiny World.” Almost immediately, my mind went to pixels, and then to the possibility of what pixels are made of. I started reading through Wikipedia articles about pixels and subpixels. I thought about creating fictional subpixels that mirror quantum physics, and quickly dismissed the idea for time’s sake. I also toyed with one or two other ideas, totally unrelated to pixels, but my brain simply wouldn’t let the subpixel idea go.

I recently watched a video of a lecture given by John Cleese on Creativity, which gave me reason to keep at it. If you haven’t seen that video, go watch it NOW. Honestly, this blog post can wait. Those 30 minutes will probably change your life, although I can’t guarantee that it will help you with a 48 hour game jam.

Done watching? Good.

Now, under such strict time restraints, Cleese’s advice begins to break down a little, because it’s hard to get into “open mode” with a deadline looming. But there is one thing that absolutely does apply: nothing you come up with is “wrong”. When you are creating just for the sake of creating, and the point is to better yourself and the community, nothing you think of is “wrong”. But once you have that idea, you must execute.

That being said, I am not a computer science graduate. I went to art school and gradually realized that the art world was not for me. Halfway through, I picked up a “Programming for Artists” course and was instantly hooked. At this point in my life, I have about 4 years of experience working in various scripting languages; I’m not sure if I could have accomplished anything without that.

I chose Flash and Flixel to develop my game with, as I’m relatively comfortable with ActionScript 3 and I’ve played around with Flixel a little. Eventually I settled on a mechanic of matching sets of subpixels together to form whole pixels. I immediately set to work, though the rest of the game could have used some more thought, such as: What happens when a stack of subpixels touches the edge of the game screen? What constitutes an end state? Why are we able to move subpixels around in the first place, considering they are built in with a specific order in real life?

However, once the idea was in place there was no time to think about anything else; If I had, I wouldn’t have anything playable. I pulled an all nighter (like most of us did, probably) working for about 12 hours straight trying to come up with solutions to code that Flixel just wasn’t built for. Next time, perhaps I will stick to something more platformer-ish. Or maybe not.

Check out my barely-functioning-but-somehow-completed-in-48-hours-how-crazy-is-that game, SUBPIXEL.

Click to play SUBPIXEL

As a side note, one of the parts of this that I’m most proud of is the code that generates a grid of subpixels corresponding to any BitmapData it’s fed. A separate function generates BitmapData from perlin noise, feeds it in, and out pops a subpixelized version, which was used as the background of the start screen pictured above. The code isn’t particularly complex or genius, but I liked the results. Check out the source code at github, specifically SPGrid.as and MenuState.as.

See you all next time!

ZUNZANDA!!!
PLAY IT HERE

This weekend was crazy. Ludum Dare 23, the 10th anniversary of the best dang game jam around, was number one on my list of priorities. I wanted to go all out for the 10th anniversary, and I did. I altered my sleep schedule so I could work during the night, which is my most productive time. I started working on the game after midnight on Friday… then I went to sleep sometime the next morning. I then stayed up ALL night on Saturday… and stayed up all the way until submission time.

Then … I crashed.

I crashed hard.

And on Monday… I was met with some terrible news. My aunt had just passed away.

Normally by this time, I’ve already played 15 – 20 LD games. But due to my sleep schedule, I couldn’t follow through. I was gonna start on Monday morning. Then I got the news about my aunt and things obviously changed. So here I am… on Tuesday morning… and I still haven’t played a single LD game. I spent some time adding a dedication to my aunt in ZUNZANDA’s credits, which I hope the judges are OK with. I then ironed out some bugs that I discovered while playtesting and getting feedback from others… but only game killing bugs. One glitch even caused the player input to stop completely, so I had to deal with that ASAP. Dropbox also borked my upload link… but I didn’t know because the site was so jammed up that I couldn’t even get to my own entry page. I said “SCREW IT!” and passed out.

But I did find a horrible bug. Well… less of a bug and more of an I’M AN IDIOT AND FORGOT TO ADD THIS VERY IMPORTANT FEATURE TO THE GAME issue. I won’t reveal what it is. Maybe you won’t notice. *cringe*

ZUNZANDA
What the hell is Zunzanda?

Well… it’s a game about a tiny world. But the twist is that the world is getting smaller by the minute… and you gotta stop it! How?

With this totally rad terrain sculpting system, of course!

Well, that was going to be the primary focus of the game, but the dynamic tiles and terrain destruction features sort of fell out of the spotlight when I realized that what I had in my head would not be possible in 48 hours. I originally wanted the player character to have two forms… one that could attack but was forced to stand on solid ground, and a form that could not attack, but could float between platforms. The terrain was originally going to change drastically over the course of a ‘stage’, but now you’ll find that it’s much more gradual.

It took me a long time to get the dynamic tile system working, but it turned out MOSTLY alright. It’s kinda fugly and it’s not incredibly seamless, but it does what I wanted it to… and HEY… for 48 hours… it’s GREAT.

So what else can this game do?

SHINY STUFF!!!

The game is broken down into waves… with each wave throwing more enemies at you. Your goal is to kill those star jellies as quickly as you can before they eat your world. The only way to kill ’em is to collect those starshines that fall from they sky. Get enough of ’em and you’ll unleash a burst of light that fries ’em dead. Then you get a bit of a break so you can ‘cash in’ your dead jellies for new terrain tiles to rebuild your world. It’s a constant battle of dodging holes while racing for those precious starshines… and staying away from those jellies while they try to gobble up your land. It gets pretty intense… even if it did end up being a bit unforgiving with ‘deaths’.

If you wanna keep reading… follow me after the jump and we’ll keep it going.

I decided that Sunday would be audio and polish day. That’s why I had to stay up all night on Saturday… because I was behind. I ended up pulling an all-nighter to finish up the wave system and get the foundation in place for the intro and the voiceovers.

Yeah, voiceovers.

I basically ripped off Bastion. If you haven’t played Bastion, then just pretend that I came up with the narration style that you find in ZUNZANDA. I was expecting the voiceovers to take the longest, but it actually went smoothly. I had a system, I stuck to it, and everything turned out better than I had imagined. I wrote a quick ‘script’, did two takes, and then started piecing it all together.

After the voiceovers, I wrote two pieces of music: One for the title/story sequences, and the other for gameplay. I’m pretty DANG happy with how they turned out.

HEY… I even had time to make some quick and dirty SFX before the deadline. I’m not too thrilled about using SFXR again, but it always comes through in a pinch. I wanted the SFX to be a bit more natural for this, but OH WELL.

So what did I learn this time?

I learned that I think I’ll skip the next Ludum Dare.
I had SO MUCH FUN but this one really drained me, and now I just wanna play some games.

I’d love to be able to just sit back and WATCH LD24, so that’s what I’m gonna do.

THANKS FOR READING!

You can play and rate ZUNZANDA right HERE

Tags: animated gif, animations, bugs, coding error, glitch, lost sleep, post comp, post-mortem, screenshot

I recorded a little video footage of my game, and added a timelapse at the end that I narrated over because I couldn’t get the game music to insert properly. I just babble on mindlessly about the game 😀

Video link

Dear LD Linux users,

now you can play King Green’s tiny failures ! You can enjoy his last days before the Queen chops his head off, of course if the maid has not chopped her head off before or their son been eaten by some loose wolf.

Yeah, now you can enjoy the delicious last days of the failed Royal Green Family on your linux (ubuntu, fedora, arch , whatever).

Isn’it a good news ?

Link there : http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=2966

I’ve thought about what i’d need to do if i were to continue development. How to optimize the performance, increase the depth of the game and other stuff you might want to know about.
If you’re interested, you can read the full post redwatergames.blogspot.com.

If you haven’t played it yet, you can do it here.
If something doesn’t work, please leave a comment with your system specs and os.

Thanks

wzl

http://www.ludumdare.com/compo/ludum-dare-22/?action=rate&uid=5751

I finished my entry in time for the jam deadline (http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=7773). While it is far from what I’d call a finished game (i.e. no sound, still some placeholder graphics & design), I did manage to squeeze in enough time to add an attainable win condition – after fixing a real doozie of a coding problem (several, actually) central to the game’s idea of being set in a world shaped like a cube.

What Went Right:

* Zeroed in on a simple game design and ran with it – Despite the urge to abandon the project due to a seemingly insurmountable coding problem, I stuck with it, solved the problem, and wrapped up the game just in time to submit for the jam. I had no problems cutting parts of the design that were obviously too ambitious for finishing in time for the deadline, while still maintaining some core element of gameyness and a distinctive look & feel.

* Submitted for the jam – Initially, I had wanted to make it in for the compo, but the extended amount of time working on the coding problem for when the player wraps around a side of the cube nixed that idea. Since I was satisfied with the simplicity of the overall game design as well as my ability to simplify it further if needed, I felt that it wouldn’t take much additional effort beyond just solving the wraparound problem to have a finished-enough game and kept going, as mentioned above. This had a hidden added bonus of allowing me to use a bit of additional content I had laying around my hard drive, which came in handy when I needed to put some text up on the GUI. I just went over to C:\Windows\Fonts, Ctrl+C’d Bauhaus 93, and dropped it into my assets folder. Problem solved. Given another five minutes or so of time, I might have even added some sound.

* 3D assets were pretty easy to make. I deliberately kept the game’s look as simple as possible, so that I wouldn’t have to attempt to do anything remotely complicated in 3DS Max, which would’ve likely ended up taking days instead of a couple of hours tops to do. All I did was create a set of cubes with chamfered edges and corners to use as level design elements. I focused in on one tool within 3DS Max and used that for all the 3D assets. With relatively little effort I got a small set of repeatable design elements that give the game a distinctive toylike look.

What Went Wrong:

* Spent entirely too much time getting just the basic gameplay working – I literally had just a couple of hours to spare for the jam when I got the basic gameplay working. This can be attributed more or less to working in 3D with anything less than an absolutely solid understanding of 3D math, which I can tell you now is a lot more than just knowing how matrix multiplication works. While the game did gain a pretty cool look for when you traverse the sides of the cube, IMHO, I had no time to implement any AI or even some simple sound effects. I tried mitigating this lack of time by making the game more maze-oriented, entirely eliminating the idea of having  to evade AI opponents; however, I had to stop about five minutes before the jam deadline to get a build up on the site for my submission, so there are a couple of sides of the cube that are not much if at all different from the placeholder designs I had originally set up.

* No sound – I could have just made some very simple placeholder sound effects in Bfxr at one point while I was banging my head against my desk trying to figure out the wraparound problem. I didn’t. And I didn’t solve the wraparound problem until it was too late to do much else. As a result, there is no sound at all in the game.

* Didn’t zero in on what I would eventually make soon enough. My original ideas were a wee bit more ambitious than a ball navigating a plastic cube labyrinth looking for dots. Some hours at the beginning were spent working on designs I would eventually throw out once I realized I could just make the entire world a single cube with a grid texture and just build on that. Had I started on this design earlier, I would have finished the coding problem earlier and had more time to fully implement the maze design, add some sound effects, and possibly even some AI chasers.

All in all, I did have fun working on this, and I did manage to solve a pretty tricky problem, which I may apply in the future. I may just touch up the game a bit and port it to Android and maybe iPhone. What’s really awesome though is that I made a (debatably) finished game in an (extended) weekend. I can’t say that’s happened very often for me, so that’s definitely a real confidence booster.

Added a Web version of my game for easier judging

Timelapse of my LD-23 entry. I think I got somewhere in the range of 25-27 hours worth of actual work in and most of that is recorded here. I’ll post a postmortem soon with more details on my games development.

Game page here:
http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=128

Please, dear ladies and gentlemen, if you plan to use WASD offer the choice to use arrows instead.

And if you cannot do that because you need both arrows and WASD, please offer the choice to remap the keys.

We are not all using QWERTY kb layouts.

Every LD, it is a remaining problem. Thanks for your understanding An AZERTY user

Play it online here

After an engineered launch on Hacker News a few hours ago, Google Analytics tells me that we have had over 9000 players and wasted over 100 hours of their collective time so far!   (Yeah, average time/visitor not so high, but hey)

We are super proud of the game.  I am super proud of the game.  I am rather in awe of Mr War’s artwork and the pace he works at.  And he uses MS Paint!  The top-down map for a text adventure gives a spatial feel that works really well.  Anyone ever played a game like it?

Text adventures really bring back warm memories.  And they are shockingly underrepresented in LD, so we tried to remedy that!  We deliberately didn’t want to fall into the point-n-click improvements trap and we wanted an overall Victorian HG-Wells / steam-punk feel to it all.

Back when we were small we used to make text adventures in Basic and later Turbo Pascal with still images in VGA 13h.  I actually can’t remember how we did it, but I imagine it took far more technical planning then.  Nowadays RAM is so cheap we just have big JSON arrays of everything in dynamic languages…

We did a dry run back in the mini 31 in January.  That showed that artwork was our strength but that we were under-resourced programmer-wise (my area) and we completely lacked musicians.

We didn’t recruit any musicians for this LD either.  Tempted?

We prepared the weeks before by acquiring permission from loved ones and deciding the kind of game we wanted to make.  We settled on a text-adventure, using HTML/JS, and the top-down spatial map idea.  I wanted the programmer UI but that didn’t need Mr War, so would have been a solo entry.  Not cool.  And I’m so glad we did the illustrated one; its by far the defining feature of the whole experience.

I didn’t actually know Javascript, so the week before I set about asking on Stack Overflow how to do things like the scrolling that I thought I was going to need.  I got not leads.  I also asked on gamedev about parsing, but the advice there was to use Inform; not what we had in mind!  I settled on super-simple string matching in the end.

This entry was low code high content.  The basic engine – in Javascript – was workable within hours, and by the end of day 1 we were more content oriented.  We panicked a little bit about the actual narrative, and roped in James at short notice to give us some lines.  By the end of day 2 we had 90% artwork done, 90% coding done, but only 60% of the puzzles complete.  You could play the game but not solve it.

Day 3 was of course a Monday – a work day.  It was also the day that my flu kicked into overdrive and I was feeling decidedly groggy.  We didn’t return to the challenge before the evening (Europe-time), just hours away from the deadline.    We managed to get the puzzles complete and get some of the glest community to do play-testing for us.  We submitted in time and went back to our families.

This went super-smoothly.  We ended up with a playable game that can give several hours of fun (if you enjoy slow-paced text adventure puzzle games without bloodshed).

Technically, it has some weak points:

The command parsing is primitive in the extreme.  Its just a list of legal commands.  (You can see them all by pressing shift-space).  I had planned text auto-completion.  Its not the meaning that you have to guess the commands.

The programmer SFW mode doesn’t have the auto-completion I imagined as central to its look&feel.  I experimented with code-like layout of text, but the shortcuts I tried to massage text into code nesting and adding faint punctuation and camelCasing etc made it completely unreadable.  Chopped.  I think with more finesse such a mode could be successful.

The NPCs don’t have the full role we imagined.  We had wanted much more emergent dialogue, and work in how they all knew each other and what a coincidence it was that they converged to retrieve the treasure.  That got cut on time grounds.  And writing dialogue lines is hard.  The NPCs were to have a role in the solution, and be a hindrance, but that never got fully developed.

And we forgot to add the vicar.

With 50+ locations, 30+ items and 7+ NPCs its quite a full enough game anyway?

My entry long ago submitted, time for a postmortem/wrapup/etc.

My original plan was for a god game in the vein of Populous. My final game was a dog running around a tiny circular world and catching frisbees. A lot can change. I spent ~13 hours, total, on the submitted game. It is written in Javascript with a custom “engine” – I pulled in keyboard handling and 60fps rendering/game loop code from a previous 48h comp but otherwise had no pre-built engine. All assets were created in Pickle and modified with Paint.NET and Gimp, depending on my needs. Music and sound effects were created in Aviary’s Roc and tweaked/trimmed in Audacity.

The Populous game ended up being a waste of the entire first evening – I spent too long making something look good (it didn’t) without considering the game, the fun, anything. I went to bed with a triangle mesh sphere that couldn’t rotate north/south and thoughts of just quitting and enjoying the weather forecasted for the next day. Instead, I got an idea that morning for a quickly implementable game and ran with it – run around as a dog, catch frisbees. I had way more ideas than I had time or desire, so I ended up with something far different than the original idea. Which was this:

You are a dog that runs around a (circular) world. You must contend with a basic simulation of running as a dog such as taking a while to turn around and worrying about slipping. There would be pits, obstacles, mud, and other things to hamper the running. A frisbee would spawn, thrown by some unknown entity and a inset hud element would show up like in a space sim; it would contain the velocity, position, spin, and tilt of the frisbee. Having to contend with the wind on top of the environmental hazards, you would attempt to catch the frisbee. Rinse and repeat.

Everything from that but the dog and concept of catching a frisbee got cut – it became about peacefully running around this little planet, getting some air off of hills, and nabbing frisbees. You can see a general progression of the game’s graphics:

The biggest change was the final level of polish. Each segment of the world had, up to that point, been colored by randomly selecting a green in a specific range of colors. Two adjacent segments could be colored randomly and would clash; I modified the coloring to pick a random segment, permute its color by a small amount, and then spread that to the two left and two right neighbors of the segment, falling off a bit at each. The camera also moved up – the ground is boring and plain beyond the hills, but the sky is interesting. Also, when in doubt, look at Mario – he is usually towards the bottom 1/3 of the screen. I also added a “shadow” world behind the main segments to create some fake depth; I initially had it parallax, but this was distracting so it rotates at the same rate as everything else.

What went right

• Polish. Polish polish polish. I spent a long time on “feel” and “style”. Having the dog get air when running off a tall hill; making the dog get a little “ahead” of the camera when running; clouds moving at slightly different speeds. In my (only) previous 48h game, I spent maybe 3/4 of the time writing engine/game rule code; the rest of the time was spent on feel and polish. Here, it was close to 50-50 if not even more time spent on polish.
• Aggressive cutting of features. This was helped by deciding to not spend 48h on the game. I think I spent 13h on it (plus a previous 6-7h on my initially thrown away idea). I took breaks, I sat in the sun. This was a boon, though it also means the game was short on game. But, if anything took more than an hour, I said whatever state it was in was done and I moved on to something else. I might revisit, but an hour was the most time to spend on any one thing. Most times it was 30 minutes or less.
• Simplicity. I didn’t use any engines; only some previously-written (and published) keyboard handling code and canvas2d setup/framerate code. My only collision detection needs were deciding which side of a line a point was on and colliding two arc segments (which is the same as two line segments, hence a single line of code). The previous 48h game, I had a full 2d collision detection engine that did mid-frame detection. It was buggy as hell and entirely unnecessary to write for the jam.
• Knowing my tools. I had previously written an HTML5/javascript/canvas2d game and done simple sprite work in Pickle + Paint.NET + Gimp. The only tool I learned during the jam was Aviary’s Roc for the music/sound effects. Saved a few hours at least by doing this.

What went wrong

• Motivation. Throwing away a night of work, going to bed late and grumpy, and waking up to 80 degrees and sun was hard. I had, in fact, sent an email to my partner saying “you won’t be a code widow this weekend, lets enjoy the weather”. Only to go for a jog, get hit by inspiration, and say “never mind”. I still spent much of the weekend not coding, so the game was short on everything.
• Lack of paper-and-pencil time. I spent barely any time thinking or writing away from the monitor. It is easy to get into a rut or logic loop and lose 30 minutes running in place. You also need to validate your ideas; when you just start coding, it is easy to spend hours working on something that would have taken 5 minutes of thinking-time to decide wasn’t fun.

Facts

• My first competition ever
• This is the furthest I have gotten in developing a game, ever
• I had planned to use Java(LWJGL + Slick2D + MarteEngine) for webstart capabilities but the my dev environment didn’t survive my meddling with version updates on Friday. I ended up switching to GameMaker:HTML5 2 hours before the start of the competition
• I had less than 10 hours of experience with GameMaker spread over 6 years prior to the start of LD23; ~6 hours 6 years ago, and 2 hours the last two hours before the start of the competition
• I just started using Inkscape 1 week prior
• I’ve been on the fringe of gamedev for many years, but have never really done much more than quick prototyping/PoCs
• The increasing popularity of time-lapses of game-jams are what drew me to participate in LD23.

What Worked

• Surprising, switching engines 2 hours before the compo started was the best thing I could have done.
• I was able to pick up and get comfortable with GameMaker quickly. What I didn’t know was easily googleable(word?) with only a few rare exceptions
• I loved the work-flow of GameMaker. Being able to put concepts together in the project tree and to visually build game logic was a nice way to prototype idea. The transition from taking those drag and drop items and moving them into local and global game scripts worked very well for me.
• Inkscape is a fantastic tool, even with it’s bugs.
• s/bfxr SORT of worked, although it getting newer generation sounds was a bit tough. It’s still a fantastic tool and great for 8/16bit sounds.
• WolframTunes (even though this isn’t really composition and moreso luck).
• Using the game environment for scrore feedback (lights on the flag bases) rather than puting in GUI overlays.
• Using OneNote-type tools to track concepts and helpful web links with notes (I used Evernote for this, but OneNote via skydrive is nice too).
• Staying social during the competition (I kept on top of twitter, IM, the LD site, my own site, and Reddit; all with focus on GameDev and LD23).
• Letting the theme drive the project. I did no brainstorming at all before the competition and allowed concept drive my creativity once it was released.
• Music without vocals. I listened to a lot of Clint Mansell, General Fuzz, and John Williams(classical guitarist) throughout the competition. I didn’t try to stay awake beyond reason; had I done so, I would have been listening to Infected Mushroom really late.
• Submitting the game in a buggy/incomplete state. The feedback on even broken games will make you a better dev.
• Drawing tablet. Even if it’s a cheap tiny pad, your developer art will be faster and look better than mouse art.
• Lots of PGTips Tea; ~20 cups.
• Having a very supportive and understanding significant other

What Sucked

• Finding bugs/nuances in GameMaker, but not knowing the engine enough to know it was a bug.
• Breaking my AI in the last few hours of development.
• Not being able to have the whole basic concept working in time for submission
• Not realizing I had another hour of development available because I thought the game had to be submitted by the end of the 48 hours and not just that development had to stop.
• Being so fatigued by the end that I had stopped saving my GameMaker project about 3-4 hours before the end; so I do not have a saved state of the project for the final game.
• Not having time to put in GUI’s

Lessons Learned

• Make sure your dev environment is ready before competion and LEAVE IT ALONE
• Know your engine/language so well that you can have a fully functioning basic game in the first 24 hours of the competition so that you can spend the 2nd half on art, polish, and
• Have enough discipline to see a problem through, but not so much that you spend TOO much time on it.
• Take regular breaks and stretch

Submition Page – My Blog

Hello,

I read a few other post mortems already. Why post mortem by the way? Is my game dead? Is it just to have more Latin in this competition?

So, this is my game. If possible play it first, so you have a better understanding of what I’m writing here: http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=12423 . Comments are welcome!

What was great:

• participated for the first time, and discovered a great community
• actually finished the project
• decent gameplay
• nice title/ending screen
• somehow came up with music (http://www.earslap.com/projectslab/otomata – a loop of 36 seconds. And I made two tracks out of that) and graphics (restricting yourself is the key to success)
• didn’t need sound effects, because, you know, it’s set in space

What was bad:

• while the main content of the game was complete, I really could have needed some more time for polish
• the player should have had more information about the game and more of a tutorial. Nearly every commenter said getting into the game is very hard. And it is. I noticed this, and only had time to add “F1 for manual” to the title screen.
• The save-/load-system sucks.
• I also planned to increase replay value by adding achievements, as “I HATE THIS PLANET – Build two Uranium Fires on one planet, escape from another one”
• the game is named after it’s protagonist, but it’s not really about him. You only know that he tried to shoot the vice president. I wanted to add dialogue between the Police guy and Gale in the title screen.  If you waited long enough, they should have had conversations (Police guy: “So, why did you even shoot the vice president? Everybody would go for the president.” Gale: “Yes, but I voted for that guy. I might be an assassin, but I’m not a hypocrite” etc.). Also, the Police guy leaves him/her (Samus syndrome) to die and tells him/her “This is what you deserve for shooting the vice president”. Gale would have a pool of answers for every startup : “I’m glad I’m here, because this is the first time I’m free” or “I didn’t shoot him, I missed”.

So, this is what I wish I could have added to the game. But if you take some time, chances are that you will really like my game anyway. And I prefer to have one that loves it and two that don’t like it to having three who think it’s average.

Looking forward to the next LD,

free napalm

Check out this timelapse for Invasion Of The Trivials made in Unity!

I did it in the style of The Humble Indie Bundle’s Broadside Express Timelapse!

Play the game here!

Tags: compo, game, ld23, music, robot, timelapse, unity, unity3d, update, video

Back again with my first post mortem !

If you don’t know what I’ve done, here your chance :

PLAY THE GAME

Let’s get a bit of background, I’m not a coder but I’m an “artist”. But a vfx artist, so I’m more a technician, and I’m bad at drawing. I’m making Ludum Dare because I still like to code on my spare time and it’s a good opportunity to train myself and in the field of games which is something I love since I’m 7/8 (I’m 24 by the way). That’s it, just some stuff so you’ll know a bit about me for what comes next.

For now, let’s get a quick review of my week end (all hours are European/France time)

Saturday :

– 9:00 : After a good night, time to know what theme is on. LD started 6 hours ago (3:00 in the night in France)

– 10:00 : Still reviewing photos, game reviews, trying to get an idea but I’m a bit nervous as I can’t seems to find ANY-THING

– 10:30 : Got an idea about a company that would recruits Gods to help little planets, could be cool, freedom would be given to the player to watch different reaction happens on the planet

– 12:00 : Had to take some time out, it gave me a bit of opportunity to think more about my concept.

– 16:00 : Going through the first classes of my code, I worked on a first prototype with one planet. I did a first mockup for graphics, and had a great boost from that as I was able to make something that I really liked with just few clicks and tricks on Photoshop. I’ll be focusing on making one functional level, which would ideally be the hardest of the game with all the features.

– 18:00 : Lost some times trying to make some procedural was a complete waste of time that could have been avoided with just a few more thinking time.

– 01:00 : I have a basic prototype, the planet have 3 Tribes that you can feed using Farms, you take food here and give it to a Tribe. Tribes don’t interact with each other and I’m really disappointed that it’s not here. But I’m tired, I wanted to have a working prototype so let’s just say something can happen with this basic game mechanic and we’ll see tomorrow.

Sunday :

– 9:00 : Back to work, the mission is clear, I have to make basic menus, first levels, so let’s do it !

– 13:00 : I now have a title screen, a level selection menu, and two working levels with introduction text/panel, tutorial, and objectives. I now know I won’t be able to put more features here so I’ll be focused on the feeding part of the game design.

– 15:00 : Two more levels, a total of 4, and I want 8 of them, time to work harder.

– 18:00 : Still on more level to do, the last one, so let’s take a break and make some sounds and music. A bit of work has been done in the level selection menu, planets are now displayed instead of just rectangles.

– 19:00 : Music is ok and coded, sounds need to be integrated, I made a logo for the title screen and enhanced it also.

– 20:00 : Sounds are here, last level is ok, let’s add some polish.

– 21:00 : Still polishing, title screen is ok, and also took some time to add an important feature, a progress bar on the levels, because it’s too easy to forget the goals.

– 22:00 : My best friend arrived on Skype and is actively beta testing the game, awesome help but he found a bug that prevents people to go through level 7 and I can’t understand what’s happening.

– 23:00 : Bug finally cleared, still polishing some stuff, finishing the end screen.

– 00:00 : Gods Inc. is finished ! Time to wrap stuff, create the entry, and LD is over.

Now, we can take some lessons about this:

What worked:

– Concept: My first LD 6 months ago was just a basic platformer, nothing really original here and it was pretty far to be really interesting regarding the theme. I had a hard time to find something and I took the first good idea that came in, it was a risk but I felt it was good. In the end it was more fun and encouraging for me.

– Code skill: I never actually finished any game or any project, which is a shame, but I tried a lot of stuff and gained a lot of knowledge in AS3/Flashpunk. I was more confident and was afraid of nothing, it’s great to put code stuff on the side and be able to think more about the game itself that the tool.

– Time planning: Having something playable on the Saturday night (just a bit before 24h into LD)  is for me a good goad. It wasn’t what I really expected at this time but it was a working prototype with a simple mechanic that could be turned into a game for the entire next day.

–  Graphics: The concept itself made graphics easier and thanks to my good abilities on Photoshop I was able to create any planet I wanted in no time with a lot of variations. I also used one background image for all the levels and just a line of code let me have random variation each new level launched with different colors. Everything was made in time and started early so it went smoothly through the weekend.

What didn’t work:

– Concept refinement / Ambition: I was okay with the concept, but maybe too much. I lost time and opportunities because I let joy overwhelm me. Too much features to code, it results in a drop of confidence at some point, about my coding skills, my speed, and the final game.

– Code planning: Levels where hard coded, with Tribes and Farms placed by code on the levels. No structures or external files to read levels seemed okay to me at first, but in the end it was a mess. I lost TOO much time implementing the victory conditions that were just if statements. And I had to rewrite this with my progress bar class because the information wasn’t readable. Next time if it happens again, I’ll clarify technical requirements a bit.

What to learn:

– Think small: Having ambition is cool, having a good idea is cool, but in the end you won’t lose time thinking more. My whole game revolve around the feeding tribes mechanics, but it can feel boring after some levels (4/5 out of 8 it seems), because it wasn’t my only trick in the game at first. If I said from the start let’s concentrate on one idea it would have been better. Instead of multiplying mechanics I would have tried variations and twists around the feeding stuff making it more interesting in the whole game. I still feel that it was a necessary error, it feels natural to me now, but it wasn’t in the process, it was something I needed to experience. Even the whole scenario idea got completely lost in the process, just no time to do it.

– Put some structure: I never wrote technical stuff as I didn’t consider myself as a real programmer. With this LD things were more serious, and I need to act with more preparation. First for the levels, they were handmade because it wasn’t tilemaps, it might not happen again, depending on the theme, but if it does, I’ll at least write some proper class to implement victory conditions, text assets etc all inside. Victory conditions are not just variables but there’s always a way to work something to make it better to integrate and communicate with all the code. And secondly for the classes, I never extend basic classes, it’s something I need to work on. Multiple classes existed here while being quite similar, it’s a waste of time, this is a method I don’t really use but I could use it.

In the end I have a game that I like anyway, and I feel I could take it to a new level, making a kind of 1.5 version. Or even try to create the real idea I had in mind, that would let the player experience the whole planet concept in a full freedom play with interacting tribes etc.

Surely LD was something big to me this weekend, I learnt a lot, and I already feels that it could be even better next time.

Thanks for reading, and see you next time !

Hello there. My name is Arhan Bakan. I’m a senior CS student at Hacettepe University, Turkey. This is the postmortem of my first entry in Ludum Dare competition. I had a lot of fun in the competition, so it definitely won’t be the last one for me.

The Good Stuff

• Before I started working on my entry, I was confident that it was impossible for me to finish a game in 48 hours. “Just gonna try the Jam if I fail the Competition.”, I kept saying to myself. In the end, however, I finished the game with one hour left on the clock. Sure, there are some places where I can say “I wish…”, but I feel like it’s a fun game overall and I managed to learn a lot from the process.
• Base game concept (a shrinking maze) came to my mind within the first few hours, and it turned out to be a simple and effective idea. Also, I set my goals for 48 hours pretty accurately.
• Sleeping. Lots of sleeping. 13 hours out of 48 were basically spent sleeping. I don’t understand how people manage to stay up all day and night to work on a game, but I just can’t do it. It’s way better to sleep well and think with a clear mind. Eating habits based on fruits and vegetables also work like a miracle when all you do is sit on your butt and code all day long.
• Learning from other people’s mistakes. I read some tips on how to survive a game jam before the weekend. And it all helped a lot. Reading good advice is always helpful.

The Bad Stuff

• Should’ve known the engine better. I worked on Unity3D. It’s the only game engine I’m familiar with, however, I’m not familiar with it enough. I spent nearly 3 hours on the character controller and after the dust settled, it was only a few lines of code. This competition made me a lot more experienced with the engine, but I still have a lot to work on.
• Lack of music. I couldn’t find a fitting content generator for music, and I was not prepared to compose music on my own. Next time, I hope this won’t be an issue as I’ll come back having finished my homework. 😉
• Lack of interesting gameplay. For most of the users (and friends) who played it , the game has a good concept, decent graphics but not enough gameplay to keep the user interested enough to finish it. It’s also a bit tough for most of them, and this takes away from the fun, too. Most of this problem was due to time constraints, so I’ll try to do better next time.

Thanks for reading through my postmortem. I’ll definitely be back for the next Ludum Dare if I have time for it. It was a great experience.

If you’re interested, be my guest, play and rate my game if you can.

PLAY —–>          WORLD GONE WRONG          <—– PLAY

Tags: postmortem