Join us on Twitter and IRC (#ludumdare on Afternet.org) for the Theme Announcement!
Thanks everyone for coming out! For the next 3 weeks, we’ll be Playing and Rating the games you created. You NEED ratings to get a score at the end. Play and Rate games to help others find your game. We’ll be announcing Ludum Dare 36’s August date alongside the results.
New Server: Welcome to the New (less expensive) Server! Find any problems? Report them here.
Being an enthusiastic fan of Smash Hit, one of the best mobile game experiences i’ve ever experienced till now, (and not to mention the fact that someone here also put up a post of smash hit retro demake), i decided to try my hand in breaking stuff using NAPE physics engine for AS3.
Here’s a little Dev-log of it for those who are interested (i hope to do more tutorial on it in my Blog MonsterBrainInc.)
I’ve previously developed cutting mechanism with Cut-it : Flash Version, and i decided to use it for cutting the blocks into several random pieces. But things didn’t worked out pretty well and the code just grown into un manageable size. SO i scrapped everything and started looking for voronoi stuff (I’ve seen a lot of demo tests, but was too afraid to look into it). After many links deep, links within links, i found some as3 library and one sample stuff. I took the code that just worked well for me (Thanks to the sample codes) & looks good. Next challenge was to break the stuff which involves lot of positioning, head work etc etc. Still i’m happy & proud with the result i’ve achieved. Finishing the Game was the hardest part. All kinds of blocks, disorientation, tiredness, powercut, disinterest etc were active towards finishing the game. But got through all that and finished the game. Enjoy Smashing.
It feels great to have you guys around making awesome games and sharing your experiences. Me, I’m Monster Brain (!realName), an indie game developer from india. I missed last LD, looking forward to the next. Meanwhile trying to come up with a Smash-Hit (loved the game so MUCH) demake. I’ve seen the previous blog post of another smash hit demake (it looks cool with pixelated graphics).
Here’s a little work in progress.
I’m using As3, Starling, Flashdevelop and Nape physics for the game. Shattering the glass was the hard challenge i had to face, somehow with the help of voronoi diagrams (thanks to an excellent library by alan shaw & example model by its haxe ported(from another port) guy), got it somewhat right. Hoping to make some interesting levels.
Firstly, i wanted to find an innovative idea with the theme. I didn’t want to make a classic game in which you only get one life or one ammunition.. or something that simple. However, I didn’t achieve to get something better than a poor joke that nobody laugh about ^^
But i had so much fun developping my game that i decided to make a post compo version. To call your curiosity and show you what i planned to do, take a look to some special effects screenshots ;=)
Hey all! I’ve been enjoying a lot of games from this Ludum Dare, and I hope you all have to. I participated myself in the jam, collaborating with another indie game dev known as Code_Assassin. However, through details I’ll explain below, we didn’t finish. While we did submit an entry, it wasn’t a finished game like we hoped, and after a day of thought, we requested the entry to be taken down, and the game removed from Newgrounds.
Our game originally started off with a premise of finding a mob boss out of a group of people, the levels and the clues would be random each time, but you only had one chance at killing the boss. We agreed on using Flixel as our framework due to its ease of use, my experience from using it in last year’s Ludum Dare and CA’s experience with Actionscript3, and that we could upload it to the web. We got a Git repository set up and we were hyped up and ready to go!
Kmembert (Camembert: A delicious french cheese) is a puzzle/infiltration/action game . The gameplay is quite simple: You are a cheese and you have to kill all nazi mice in one shoot. Get the cannon bullet and trick the mice in order to kill them all in a single shoot. 9 levels are playable. HAVE FUN ^^!
It was my first Ludum Dare compo. I just be informed of the event 4 days ago. My weekend was busy but I was motivated to create a simple game saturday morning with the theme “You only get one”. I already participed to the “Global Game Jam” twice, but the Ludum Dare is a different challenge.
I cumulate 17 hours of work for this game.
I found the idea in the first minutes: Get the only one bullet, trick the enemies to manage to kill them all in a single shoot.
The controls are simple and the top view allows to create less graphic assets and less code. I’m a big fan of “Metal gear solid” and I recently played “Hotline Miami”. So I unconsciously designed game mechanics with this game in my mind. I always wanted to design a game like Metal Gear Solid :). Therefore mice can run after you if they see you and you can play with the doors.
Level Design I modified the mouse behaviours 2 hours before the deadline. So I redesigned the levels accoring the modifications.
I tried to design 9 levels with interesting challenge. I think the levels are fun and you also can understand all puzzles quickly. But I had no time to playtest the levels to another players. That’s why the game needs different mice with different behaviours and more balance.
Graphics I didn’t want to use human characters, zombies, aliens or monsters. So I decided to imagine a coherent situation with uncomon characters according to the game mechanics. A humanoid cheese against nazi mice ? Why not :). I’m not a 2d artist but I tried to design simple characters and animations quickly. A pen tablet is a good tool :).
Sounds Unfortunatly I didn’t have the time to play on my guitar some cool riffs for the background music. The sound fx are just simple homemade sounds of my mouth :).
Tools I’m a Flash game developer since 2004 so I create all assets, animations and code with Flash. I used the World Construction Kit library. It’s the Box2D physic engine with a WYSIWYG layout, very usefull to design levels. I also used simple libs : TweenMax, Flint. I used “Flash Develop” and I created some assets with Photoshop and Audition.
It was a great experience! Sometimes I watched streams of few developers around the world. I also earn some skills in code with box2d and in graphic design. I found my game interesting but it needs improvements :).
Well I made it through my first LD with Monochrome as my entry!
It was tiring, and frustrating on occasion, but mainly it was pretty fun and I can’t wait to give it another try!
I just wish I had learned more before starting, because I lost a lot of time learning to do some stuff for the first time, and it made me waste time on silly mistakes and work slower overall. I couldn’t do as much as I wanted, but oh well, I definitely learned a lot (although I left my code real messy :x).
In Monochrome You Only Get One color at a time. The one-colored world you see is the world you are in, but periodically the channel changes and you have to deal with another one-colored world, so be sure to move in time to arrive at an adequate position in the following color (or you may even end up stuck in walls until the world changes)! I hope you enjoy this little platformer!
game title: Wifes
almost finished implementing game engine. Player and women interact as they have to. Still working on bad guys :). No another screenshot , because all day I was working on deep engine stuff, preparing all framework from scratch.
Some more info: your target will be to reach point goal as fast as possible by marrying and divorcing with women. There will some challenges , like enemies – random guys from nowhere – who can take your place by marrying another women and not letting you to get enough points to win. Also there will be enemies-guys , who will be able to steal your wife and as you know – you only get one wife at the time :). Tomorrow top priorities: to finish bad guy class and start working on graphics and sound.
The game idea I decided to go with is that you’re the only crew member of a ramshackle submarine. You have to dash between posts to prevent the thing from sinking. So far, it gradually fills with water, and you can operate the bilge pump to drain it. This probably makes it the only Ludum Dare game with an operatable bilge pump.
I decided to make a LD48 game too! It’s about trying to dock a spaceship into a fuel station with realistic Box2D physics for extra QWOP-iness. You have one tiny fuel tank and limited electric charge. The realistic physics make it hard to simply move and dock, but you still need to dock to the station before you run out of electric charge or fuel.
The fuel station and fuel/charge gauges aren’t implemented yet, but you can fly the spacecraft with WASD.
Hijack Humans Hastily was my compo entry for Ludum Dare #27 under the theme “10 seconds”. It was a game developed in pure ActionScript 3 (using Adobe AIR), with the OUYA as its main target but with a web version available (given the platform). Here’s a short gameplay video:
Here’s the mandatory post-mortem, with a few development snapshots scattered around the article.
First physics bodies
What went right
Reusing stuff I already knew about
In my previous Ludum Dare entries, I’ve rarely re-used many systems. I like to build my own stuff. In fact, so far I’ve refused to use full-fledged engines, and while I’ve used Unity previously, it was mostly an excuse to force myself to get acquainted with it.
Particles for thrusters
This time around, I had decided ahead of time that I would be using AS3 and a couple of frameworks for certain features (Nape for physics, Starling for GPU graphics). I had no engine, per se, but I complemented those by developing several additional libraries for game controller input, game looping, and physics level data loading (most of which are open-source and posted on my blog). I was certain I’d spend more time working on a game, rather than working on systems for a game (which, as fun as it is in itself, doesn’t make a good Ludum Dare entry).
Using image assets
The strategy worked pretty well. While I still had to use a pretty amount of time getting basic stuff working (due to my lack of knowledge of some Nape features, for example), I felt I was actually building a game earlier than on my previous entries.
Art was straightforward
I loved doing the art for the game, even though I hadn’t been drawing in a while. While a bit was dropped and unused (specially background art), I think the simple aesthetic I reached was pretty flawless even if it wasn’t brilliant.
Image assets being added
What went wrong
Getting a game idea is always the hardest part for me, specially under pressure. I spent the whole first semi-day of the compo (Friday) doing nothing other than dicking around online, or reading, just because I couldn’t figure out an idea. The idea Saturday morning – of a flying UFO capturing humans – was a mechanic I’ve been thinking of for a while, but to be honest I didn’t have the gameplay challenge or the relation to theme figured out for a while.
Making the UFO landable
Features were dropped (surprise)
While I tried having a smaller scope, some features were dropped out of the game. There’s only one level, for example, and while it’s randomized and it’s all based in easily configurable parameters (size, assets, etc), I never had the time to add actual level progression and assets for more levels. The current level used (city-ish) is a mix of my two initial levels ideas, park and city.
Adding human targets and background art
Worst of all, I couldn’t even begin to implement the enemy A.I. In the best Choplifter fashion, the second level of the games was supposed to game enemy tanks that would shoot at you. They would not do any damage, but their projectiles would throw you out of balance and make control a bit more difficult.
Making humans capturable
Not enough time for bug testing/QA
While I didn’t run into any huge problem, my entry still had some issues I had no time to test. Those include some bugs related to web playback (losing 3D context when switching between fullscreen, for example), and some OUYA pitfalls I wasn’t aware of (having the game suspended by the system puts it in an unplayable state when restored). Those are things that are likely easily fixable, but were noticed too late.
Adding building obstacles
I think this was probably my most well-rounded Ludum Dare entry so far. I’m pretty happy with how it turned out, and I spent plenty of time watching my own time-lapse video of the development process. It’s great seeing it slowly transform before your eyes.
Still, the relative smoothness of this Ludum Dare made me realize something. Ludum Dare is a lot more about the content, and I’m not sure I’m very happy with it.
Because of the limited time, it’s better to have a great idea, create a lot of content and gameplay, and test it out until you have something fun. Some of the compo and jam entries I’ve tested were really fun to play, more than just being an interesting concept that could become a game.
In my mind, I like to use Ludum Dares to explore new mechanics – mostly in the form of new code – and almost as an excuse for learning something. And to be sure, I’ve done a lot of that; all Ludum Dares have been a great experience, even the ones where I didn’t have anything very playable in the end. I learned a lot in a short period of time.
Still, having to be forced to spend more time with content and gameplay is something bums me out. Having to ignore bugs unless they’re showstopping, and having to get things to work fast (as opposed to right) is something that, over time, I’ve almost forgot how to do. Nowadays, I like to get a cool system to work as a stepping stone. In a way, it’s almost as if gameplay is secondary to that (in that it comes after that, not that it isn’t important).
Something else made me realize that. Over the past few months, I’ve been slowly developing a game prototype on my free time. It makes me really, really happy. I take my time to get some things right – be it gameplay, animation, or lower-level systems – and it’s very rewarding. I do one thing at a time. Putting a pause in developing that to do Ludum Dare #27 was good in technical terms – I ended up learning several features I plan on adding to my game, such as ray casting in Nape – but I also realized I wanted to get some things right rather than just getting them done. For example, my starling shape utility classes – to transform imported Flash Sprites and MovieClip into Starling textures – is a mess. It works, but there’s a lot of edge cases where it doesn’t work as intended, or where there’s a lot of redundant code. And I’ve used it in 3 projects already, with no actual time for refactoring them and making them elegant.
I know the usual solution for Ludum Dares it to use an engine. Some might say I should have used Flashpunk, Citrus, or any other engine. And they would be right. But the reality is that it wouldn’t have been as much fun for me. As weird as it sounds, to me, Ludum Dare is an excuse to write something from the ground up. Not just to get something done, but to appreciate the journey of development. And I’m sure that, for many people, seeing something done is what motivates them over everything else. It surely motivates me. But I’m starting to realize that I care too much about getting systems right. Maybe it’s an annoying developer thing. My own professional work is always done on tight deadlines, make no mistake, but over time I’ve learned to balance it all and use time well to get something that’s mostly right from the get go. It normally means a better, more stable project in the long run.
I’m very grateful for everything I’ve done and learned. Ludum Dare is an awesome idea. But I’m not sure what I’ll do with the next Ludum Dares. I might do them, but maybe as part of a team, or maybe without submitting anything. I may use it as an excuse to build a “demo” of a system – e.g. my game controller classes, which need a few additional features – rather than an actual game to be played. We’ll see.