Here is a personal selection of games from this 28th edition:

Compo

• The Wizardry of Differentiation by Mortus
  
• Clic Only by Nicso
• Princess Kingdom by Ncannasse
• The Last Rock by Ozeotropo
• A Precious Arrow by Benjamin

Jam

• El Tigre Il Assassino by Popogames
• Match Girl by DDRKirby(ISQ)
  
• Castle Uno by SecondDimension
• YOGO RocketFist by _Rilem
• Gaea by Bach

(For a link to the game, click the image) 

Hey, it’s my second Ludum Dare, it was much harder this time around since it went to be a platformer.

First Day :

There we were, me and my “crew” searching ideas on Skype, throwing stuff around on the chat, until I had the one idea that would bind them all : 5 skills (one was removed along the way), 1 skill point and several maps to exploit the concept.
It sounded easier to do on the paper, so we rushed into CraftStudio (the gamemaker used to make the game) and started creating one map each (It was around 5-6 levels if I recall) and that was our first mistake, not focusing on one and only one map.
Our second mistake was already there too, each map had it’s own textures, and not everybody can make great textures, at the end of the day we were proud, nothing could’ve warned us of the errors we were making.

Second Day :

I woke up quite late and couldn’t start the server until X hours, I started it and we resumed the levels editing (I also implemented a platformer script I did for another game), but at around the 36 hours mark (the middle of the jam) I just looked at the maps and I figured out it was just not right at all, everything looked weird, that’s where I had figured out we had just lost those 36 hours and we were in crunch time.
So I quickly scrapped the map and focused on making one map with one set of simple texture (that I had already used in Delayed) as an aesthetic thing I added a color for each path.
I focused on scripting while the crew were making the levels, and there I needed to find a way to kill the player with the red block, it was not going to be easy.

Third Day :

My idea was to make 6 points around the player that would figure out the block ID it was in and if it was the red block it would insta-kill the player, it seemed easy but after trying for 2 hours I simply gave up and went for the “simple” idea (that was going to ultimately make the game need optimisation) which was making every red block and entity (if I recall it was around 360 entities in total but that was the only way to get the game made in time) so we did that and the end result was the possibility of death. (minus the 2 seconds freeze due to the scene reloading, I’ll explain this one later)
I quickly made sounds in BFXR and a member of my crew gave me a music, another found a name to the game.
After this I was coding each block type and after a while it was finished, with only 2 hours on the clock, it was around 1am and I had school so it was really quick, I posted it and left to bed, but I was happy because we had finished the game.

After the Third Day :

I had the game tested by some friends and they all thought it was good, but after each death the 2 seconds lag was annoying since you die a lot in the game.
So I went to fix that with an instant respawn and since every blocks were entities it was easy, but there was the need for an optimised version as some people couldn’t play it because of framerate issues, so I knew what to do, figure out a way to wipe the 360 death entities, and I took my block ID idea that I had previously and after hours of testing I had finally managed to do it and erased the 360 death entities, and it was working like a charm (it may have slightly bigger hitboxes though) so I released the optimised version and voila, I had finished the game !

In four months, there’ll be the next Ludum Dare, and this time we’ll keep it simple, see you there !

Tags: postmortem

I finally took the time to write a postmortem so here it is!

Well, this was our first Ludum Dare jam and it was quite a challenge but the result is most rewarding:

Save Octavius (click the picture to play)

We worked for two days and a half only because jam starts at 3 AM in France and we couldn’t gather the team before Saturday afternoon. The brainstorming session was much fun with everyone in the room throwing ideas as they went through. Our whiteboard was rapidly covered with sketches as we discussed the type of game we would like to do:

Eventually one member of the team came up with the idea of protecting ‘the one you can’t loose’ and there we were: the game would be a vertical shooter à la Xenon 2 and your goal would be to protect and escort a cute octopus that is being chased by an evil tycoon who intends to turn it into sushi for its next lunch!

I took screenshots of the work-in-progress regularly so you can see how it evolved during the jam. A checkerboard pattern was used for tests at first because we originally intended to compose background graphics using tiles.

Our graphic artist, Bertrand, did a marvelous job creating many sprites for the various creatures that appear in the game, giving it a very distinctive and coherent atmosphere:

And a few hours before deadline, we even managed to get a musical theme for the game, thanks to Agnès that composed a small tune using GarageBand. Cherry on the cake!

So now is the time to sum it up…

What went great:

• Teamwork! Ideas, wonderful art, support: thanks a lot everyone! Managing nearly ten people can be a little challenging at times, especially when said people have absolutely no experience designing video games, but I would do it again without hesitation!
• Haxe: this language is just fantastic for programming Flash games. I started learning it a few months ago (C++ is usually my tool of choice for creating games) and I am impressed by its possibilities and clever design. Special greetings to Deepnight and Valandre whose entries for previous LD events (here and here) where very helpful in understanding how to get the most out of Haxe when creating games.
• FlashDevelop: this simple and reliable IDE simply rocks.

What could have been done better:

• Software design: instead of coming up with a clean architecture from the very start, I tend to refine my software design gradually, thus losing time.
• AI: current AI is way too dumb. This needs to be reworked a lot. I need to read more books, test more algorithms!
• Physics: collision handling is too simplistic. I plan to use the great Nape physics library in the future.
• Sound effects: we didn’t take enough time to record or find sounds for the various events that happen during play.
• Story: again, we created a detailed story with different characters but did not have enough time to put it in the game.

See ya folks and stay tuned for a post-jam version coming soon with more graphics, sounds and a complete story!

Tags: jam, postmortem

Midnight Minigun is a top-down shooter where you fight the rising tide of Zombification in a small-town community. This was my third Ludum Dare and I only had 24h in which to create my entry … on the whole I was pretty happy with this one, I hope you like it!

Play and rate here

What went right

1. Preparation – I knew I’d only have a single day in which to create my entry, so making sure emy tools were sharp in advance was vital. I stripped down my last LD entry to base code and was ready to hit the ground running. Preparation also meant treating my family well and bringing everyone on board in a team effort – the Zombie noises were provided by my 6-month old daughter and slowed down in Audacity 😀

2. Tiny scope – dawn til dusk is not a lot of time and I wanted the game to be polished – that meant avoiding feature creep at all costs. The main feature I cut was a mechanic where humans would follow you. You could lead them to the fenced area in top-centre of the map and they would be “saved” and un-killable. It broke the flow too much so I cut it early. However the game is very simple as a result and could benefit from another feature or two… 8×8 pixel sprites was also the right move for my limited art skills!

3. Two phases: core then juice – I watched the “juice it or lose it” video linked by a previous LD48 poster and this really cemented “polish” for me. Polish is what makes a game shine and without it your game will always be dull. The biggest win is SOUND, so I grabbed the free music from Franklin Webber early on and made sure the gun sounds were bang on. Other additions to juiciness are the screen shake, darkness vignette and particles. Without these the game would be shallow and dull.

What went wrong

1. Struggles with art – I knew this game needed fun animations and readable sprites and environment. I really wanted a gorgeous colour palette to unite the elements but this proved elusive so the result is a bit of a mishmash – the dark vignette hides many evils! Creation of the environment tiles was really tough for me – I had plans for a school, shopping mall, carparks, cars etc … I just didn’t have the skills to pull that all off so the environment ends up feeling a little sparse.

2. Lack of reliable excitement curve – Ideally games should start with a hook, feature periods of tension and release, before a climactic finale (see e.g. Jesse Schell’s Art of Game Design). I think I have the first two but it is quite possible for the game to fizzle out / become a bit of a dull trudge to mop up stragglers. I would really have liked some kind of key event like a boss battle to provide an exciting conclusion…

3. Missed opportunity to add story – I kicked myself here as I really intended to get the player to drop some one-liners etc when you died/respawned. This sort of thing really lifts the experience and adds humour and character – alas, I chose to just “ship it” and regretted this afterwards. The ending is also a bit un-rewarding. Something tied into the fiction of the game would have been better, with a custom win screen with some nice art assets picturing your triumph or whatever.

Conclusion

I had such a blast making this game, and I’m pleased with the result. I really wanted to convey the feeling of mowing down hordes with a minigun (rather like the jungle scene in Predator…see below!) and people seem to dig firing that gun! It’s a simple and short experience that doesn’t outstay its welcome, and I think there is plenty of scope to add features for version two.

The comments and feedback I’ve received have been humbling, thank you Ludum Dare!

Play and rate here

Or watch Predator here:

Tags: pixel art, postmortem, success story

I have finally sorted out my thoughts as to how I went about making my ludum dare entry and what I wanted to achieve with it. If you haven’t played it yet, then check it out here, as spoilers follow.

It was my first ludum dare, and I had little hopes for it as I had other responsibilities on Sunday, and I was drawing blanks for hours after reading the theme. Finally I decided on a small and simple text based adventure involving a shipwreck, two convicts and only one of each item in a small set of supplies. Also I suck at every form of art, so the choice of a text-adventure helped :P.

My main motive behind the game was to create a sort of role playing mechanic, in which we build up our character’s personality by the actions that we take, thus changing the paths that will be available to us later on. So if we attempt to drink the water by ourselves, it shows that we are greedy and we won’t share the life jacket with the convict or stab ourselves later to let him survive, or if we say that we had murdered someone, then we can’t stab the convict later on due to guilt. I was also aiming for some minimalism in the writing in the hopes that it would increase immersion as the player could fill in the rest according to her own imagination. It also decreased the amount of writing I would have to do. Yay for less work by design :).

I chose the XNA framework to create the game in, as I did not know at that time any game engine that primarily supported text based games. Also I didn’t know html 5/javascript well enough, and wasn’t entirely comfortable with unity’s guitext, and reckoned that I could port it easily to unity for the web later since both use C#. I had initially created many scenarios with a lot of items, but after spending most of Saturday creating the story and writing just the introduction for the game and then wasting all of the Sunday on life stuff, I had to cut down to only two major scenes involving the knife, the life jacket, and some conversation. I finally completed writing and coding with around 7 hours to go which were spent on testing, bug/typo fixing, adding some fade effects, and finding the right music.

So to top it all off:

• I found the perfect musical score for the story.
• The writing wasn’t as bad as I thought it would be.
• I did manage to create some instances of the role playing mechanic I had wanted, even though the number of scenarios and items had to be cut short.
• I really liked one particular ending (in which we kill our-self to try to let the convict survive), but it’s inclusion cut out a lot of other possibilities in the story as I couldn’t find a way to fit them all in the limited scenarios that I had created.
• I decided the name of the game while submitting it.
• I had a lot of soup in the last 12 hours of the jam.
• The “Fun” rating in the ludum dare rating system should be changed to “How Engaging is the Game”, because a lot of other games that i’ve played in this jam are more about an experience that is not inherently “fun” due to the subject of the game, but they are still highly engaging. After all games can include interactive art too.
• I should have paid more attention in my web development classes in college.
• Thank you for playing my game!

I’ve taken this core idea as far as I really want to push it.

Mostly it’s a visual overhaul – almost all the graphics have been replaced with free visual alternatives. The major VFX have been redone. A few numbers have been tweaked, a few gameplay issues touched up, but largely it’s the same game.

There are still some things that aren’t ideal, but I couldn’t find an alternative and don’t have the art talent to correct it myself. Would love to replace that timer at the bottom with something less garish.

I may still hammer on the tech, but it wouldn’t be for the same game – I’d likely shift away from the “You Only Get One” theme and move toward a different experience. But the future of that is still undetermined.

You can play it by clicking here. And the original is here. Obviously, if you rate it, rate the original (you can do that here).

Cheers!

Hello there townsfolk!

I hope many of you have already played my Ludum Dare 28 entry, Pete, The Petard. Its a fun little game, featuring a dedicated Petard who does what petards are supposed to do, explode! To complete his missions, he has to destroy enemy supplies and eliminate the guards and do all of it in one go! Because you know, you only get one…

Use of petards in games (clash of clans, age of empires)

Petards are not a new thing in gaming, i am sure you have seem them in real time strategy games and a few shooters too.

The Original Idea

The first idea I thought of was a puzzle platform game where the player gets one bomb and the level has multiple enemies. The trick was that the bomb could only kill a limited number of enemies. All those who remained had to be killed by other means using the level elements or dragged together so that you could kill many enemies with one bomb.

When the development started, one thing led to another and the next thing i knew, i was blowing myself up and winning castles for my king!

Art Style

I wanted the world and the characters to look as cartoony as possible. The theme of the game was grim, so pulling it off as a fun game required a concoction of cute and silly.

I started with the characters. Pete the Petard had to be a simple guy, ordinarily dressed with nothing special about his appearance and not too smart either. What would a low paid 100% expendable soldier’s uniform look like, i think it would be entirely made of brown rug, head to toe. Helmet? Nah it’s not going to help him anyway. Pete takes his work seriously, his cheap uniform is clean and ironed. Is he bald under the cap? Oh well that.. he doesn’t want you to know.

The bomb he carries is high-spirited, so very eager to go boom!

The enemies, that is the royal Guards are better looking, with fancy uniforms and sharp weapons. While making the characters, i kept in mind to keep them symmetrical following primitive shapes.. the human mind loves basic symmetries

I did not have time to add as many details to the game world as i wanted, but i still managed to make small props like grass types, flags, decorative shields, meteor hammers etc which i added in different levels to add variety.

Level Design

Now an artist is not something i call  myself, so one of the things i was happy to be able to accomplish in this Jam was total Tile-based level design. I drew most of the tiles separately in 64*64 grids (later downsized to 32*32) and imported them as tile-sets. The Parallax backgrounds required a little more work.

Level Design using tiles and objects

Each level has been made through tile assembly and parallax backgrounds, and works pretty well for that.

Gameplay

Pete can be controlled by arrow keys for movement and jump. Based on players’ feedback i believe the controls need some fine-tuning as Pete moves too much on light keystrokes which makes it tough for him to land on tricky spots. Another complaint was that the general physics was somewhat ‘light’ and bulk of a few objects was not as it was supposed to be.

These are all polish and tuning problems that i will fix post Ludum.

A design flaw as I would call it, is that it’s tough to understand in these small levels as to which objects are in vicinity of Pete’s bomb. The exact bomb range is hard to determine and is unforgiving. One would think one is in the range of an object but as it turns out, the target would be marginally missed by a few pixels. Click the gif to understand the issue better.

This is something that needs more than just tuning. I think i will make a system where the objects in the range of Pete’s bomb have some kind of visual cue, so that the player can  have a better idea about the beginning of the chain reaction.

Future Plans

I have already started working to make this a mobile game. The plan is to make a post Ludum final release, with better graphics, audio and gameplay featuring about 50 levels, and release it on mobiles and web. I have registered my publishing unit as Clayfruit Games and if things go well, you will soon be blowing up Pete and the royal guards on your phones too

This entry was posted on Sunday, December 29th, 2013 at 4:02 am and is filed under LD #28. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

i decided to continue development of my LD game, until now the progress is good so far,  because the LD version messed up so bad, hahaha 😀 😀
it was really hard when you need to draw and code in same time, i messed up a lot before,  thanks God my friend was doing good too for the BGM, everyone knows Ludum Dare is like Time-Management Game when the player supposed to create a game within limited time,  ;D
okay for today , to make it a bit complex,  i added  :

– inventory system,
– equipment rank, the scale is from grey to red  ( normal ,fine, ancient, legend, phantasm).
– drawing and coding a lot stuffs related to equipment, mehh :/
– rebalance the talent and stats of player.
– added more effects such as blood, etc but keep the FPS low
– buff and debuff,
also about the servitor ( main character ) face, still no idea, my friend said to draw it with japanese anime style, while the other said do with a bit realism style, it’s story wise, will look up later, but for sure we gonna change the infobar with like this example

actually this is still farrrrrr away from our planning after doing LD and after realized how bad the LD version was haha *sob*
now let’s take the seat back and enjoy our time, guys !
you can play the LD version here, lul i know it’s bad but better than nothing, hope we can release the full asap, cheers !
Play

What do you think of a Post-Jam version of the game?
Should I create one?
And what would be the guidelines that I should follow?

And here I thought I was just making an innocent game about a silly floppy elf. Tooth decay was an afterthought.

Sounds fine right? Well, not exactly.

ಠ_ಠ  Here’s another tip: Don’t write tips right after LD sleep deprivation!

While the game got quite a few comments, I wonder if any true tooth collectors discovered nefarious tooth fairy’s true plan and coincidentally the secret bonus level; the biggest tooth heist ever!

“Thanks for the teeth! Here are some railguns”

BZOoooooooooowwwwwwwwwww BZOOOOOWWWWWWWWWWWWWWWWW!

After my first Ludum Dare, I got pretty frustrated with the game I came up with (You can check it out here : http://www.ludumdare.com/compo/ludum-dare-28/?action=preview&uid=31332), so I started working on something more ambitious.

Powerless! My third game ever (or second, if I don’t count the Ludum dare).  Here’s the description  :

Powerless is a platformer-RPG in which you start as a little powerless character, who must fight until he becomes a hero.

Mixing early arcade game mechanics with modern, RPG-type elements, Powerless is meant to be a competitive game where players try to reach the highest score in a given time. After choosing between a Speed, Constitution or Strenght-based build, the player will have to collect gems and kills enemies to get that score going. You only get 5 minutes. Will you be #1?

Try it here :

http://gamejolt.com/games/platformer/alpha-powerless/20232/

This entry was posted on Sunday, December 29th, 2013 at 12:27 pm and is filed under LD #28. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

We’ve finally had the time to sit down and write up our post mortem for our LD28 Jam entry so here goes!

Our entry was “Only one light”, a short little prequel short to our upcoming mobile game, Drift Bloom, in which a spirited little flame gets only one chance to restore light to a colourless world. In just 4 levels, it’s your task to light all the matches swiftly before the snow puts your flame out.

The Tools

• To make the game, we used Unity 3D with the new 2D features.
• We used Photoshop CC and Paint Tool SAI for all of the art.
• Finally, all the music was made by Thortrillion Tomsborg.

What went right?

1. Planning – We were able to plan out our idea within the first 3 hours of knowing the theme and caught up with a bit of sleep before beginning work on the game itself. We were able to get the planning pretty streamlined and planned it far faster than our previous jams (I think this was mainly because we had 48 hours and not a week).
2. Scaling down the game – When we started planning the game, we had loads of ideas and the game sounded a bit too ambitious, but we were able to scale down the game and understand the games scope. We realised then that our game would be achievable and completed in the time frame, whilst allowing time to polish the game prior to uploading the final version.
3. Getting enough sleep – We made sure that throughout the entire jam, we had enough sleep to make sure we could get this game completed. Without 8 hours of sleep each night, I don’t think “Only one light” would have been a good game at all. 
4. Assets and art – We wanted to make sure that all of the art and assets used in the game would be well polished and look good, so we decided in the initial planning stage to have as few assets as possible and focus on the look and style of the game rather than adding more and more assets.

What went wrong?

1. Unity 2D features – It was our first time working with Unity 4.3 2D features, and we figured out that we should have had some prior experimentation with it before the Jam. We were so used to other 2D frameworks in Unity 3D that it took some time adjusting to the new features.
2. Jumping mechanic – Just prior to submitting our game to the Ludum Dare entries, we noticed a severe problem with the jumping mechanic whereby the jumping was erratic (This was because of the new Unity 2D physics and Delta time). This took a good 3 hours to figure out the problem, almost deleting all of our code to find the issue, but even when we submitted it, the jumping still felt a bit awkward from time to time.
3. Sound effects – It’s one thing that bugs us to this day and it’s also what we’ve received a lot of feedback on as well but we just ran out of time and couldn’t add any sound effects to the jumping and the burning of the flames. 
4. Better level design – It was our first time making a platformer and with no time to test the game, there were some flaws with our level design, especially with matches being too far away and quite challenging.

Conclusion

We’ve had some brilliant feedback from our entry and it’s been wonderful to experience a Ludum Dare for the first time. We know that next time we will definitely make sure to refine our game and test it out before we submit it. However, our planning was really effective and we will continue our planning strategies in the future and we look forward to making more Ludum Dare games 😀

Howdy ya’ll.  I made a game for Ludum Dare a few weeks ago, and I think it’s high time I actually make a postmortem for it.

So the theme this time around was “You Only Get One.”  I came up with a few concepts before settling on this final option.  The first idea was a game where you get one chance to win the game, and if you die you run you don’t get a second chance, a la a game I played on Newgrounds a while back.  (http://www.newgrounds.com/portal/view/555181).  My next idea was a metroidvania game where you can save one princess, however there are several trapped in the castle.  Neither of these ideas went far so I decide to come up with a new idea.  I wanted something simple, since by that time it was Saturday I night and I was running out of time.

Now I started working on This world is broken in earnest.  I decided to go with a ZX Spectrum style, since I was annoyed that I didn’t have time to work on much of  game for SpeccyJam, a few weeks prior, and I had the palette on hand.  I came up with the idea of only being able to wall jump and the game started to flow out.  In the end, I finished in the nick of time, although I would have liked just another hour or more just to hammer out a few kinks.

Overall Feelings: I like this game.  I like the concept and I enjoyed making it.  I think the difficulty curve is a bit steep, although to be fair, almost all of my games have a very challenging aspect.  I seem to make a lot twitch platformers.

Art: The art was simple, but so was the game, so I thought it was pretty fitting.  Other than the color changes it really only had two sprites and a tile, but it fit the concept pretty well.  I think it all worked well in the end.

Sound:  Ugh.  UGGGH.  Okay, I didn’t end up having time to input a background track.  So, in the last few minutes I added a jump track, which seemed like a good idea at the time.  It wasn’t.  Boy, was it awful.  I corrected that in the updated version, but I think that the music and sound was definitely the worst part about this entry.

Updated Version:  I have created a post compo version, and now all levels have a title card.  A few levels have been tweaked for difficulty.  I also added a background track and got rid of the sound effects.

Links to both the compo version and the updated version are located here: http://www.ludumdare.com/compo/ludum-dare-28/?action=preview&uid=8229

Looking toward the future:  I’ve been making games regularly for the last two years or so.  This year I managed to complete the One Game a Month Challenge, and last year I made a ton of little games.  However, this upcoming year, 2014, I would like to actually make a game.  Not just a jam game, but a full fledged game.  I’ll talk a little more about this in a future post, but at the moment, I think a full game based off of this concept is what I’m going to do.  More on that later.  For now, I hope you enjoy This world is broken, and I’ll see you guys next time.

-toaster

with all these games im rating and offline exes what is stopping someone from having a bogus game on top of something more sinister ..like as im playing the game it is quietly deleting files in the background from random places it finds etc..

surely it wouldn’t be hard to write something to do that..im sure i could ..or maybe im missing something heh

was just a thought as it has just dawned on me..  i suppose its all just based on a trusting community thing?! ..some people are just evil at heart tho

i hope im not giving anyone any ideas heh ;p

HowieV

Hi! In this post, I will try to discuss the process behind developing our entry for this Ludum Dare, PUSH.

Unlike most of my postmortems, I will not break this one into days because there isn’t much to write about this game.

Originally, we didn’t even plan on joining this Ludum Dare, because we all had a lot of tests and didn’t think we’d have the time. We originally thought of the idea when we first saw the theme, but that was it – it was just an idea.

Mati & Itamar began drawing some doodles, just in case we would actually make something, and lo and behold; we did. I took a look at the graphics and realized this wouldn’t require too much work on my side (I’m the coder), as the engine would be really simple. Here are some Alpha graphics:

The general idea is set in an Indiana Jones universe, where our adventurer can only push one item per level. How would this concept play the main mechanic in a puzzle game though was what kept us busy for most of the Dare. We weren’t sure how levels would be designed, what would impose a challenge, what new elements we could introduce or how difficult the game would turn out to be.

I coded the engine and we had a soundless game with the adventurer who would teleport 16 pixels every time we pressed an arrow key. Rocks would also teleport (or get pushed) once per level. It was ugly, but it was set in stone.

Also, yes, that’s the Spelunky idol! We originally wanted the game to be an homage to Spelunky, but we later dropped the idea when we realized this could make people angry.

If you play PUSH, you’ll notice that the level design panders to utilizing that one push to piece a level together, e.g pushing a rock into a hole so that we may later tread on it. Designing the puzzles was the hardest part of working on the game. I designed most of the puzzles myself throughout the third day, while Mati and Itamar designed the first ones and the last puzzle (which is also the hardest).

We also had to change the order of some puzzles to make the game become increasingly difficult as you play. When we let our playtesters play, they told us some of the earlier levels were harder than the later ones, which is what triggered the level shift.

As we continued to work, we wanted to achieve the polish most of our games have. We think ‘eye candy’ and pacing are two of the more important things a game in a jam should have. I added some math algorithms so that items wouldn’t teleport but instead slide to their new positions (it’s really just x += (targetX – x)/2), a bouncing effect and animation to the player for when he moves, dust particles (which I think almost all of our games have) and sound effects. We also had Suezo make us some amazing music which you’ll hear looping throughout the game (the reason it’s called YOPO on Newgrounds is because the game was originally titled “You Only Push Once”).

We started going over the levels to see if we could make anything better. We added random rocks and pits, for cosmetic purposes, and also a main menu. Itamar suggested that the menu should actually be in-game, meaning it’s actually another level:

We also wanted to include some dialog, but we decided that a silent protagonist is classier. I regret not adding names to levels though. (“Humble Beginnings”, “Firebrand”, I had plenty of them!)

And now!:

What went right?

• Polish – Something that is very important to us.
• Easy to learn – The game itself is easy to understand and play, but that doesn’t make it as forgiving you’d expect!
• Music  – Once again, the lovely Jason Lord.
• NO BUGS – Ok, this might sound a little dumb, but I *HATE* having bugs in my games, and I usually have them when I make a game for a jam. Fortunately, because the engine is so simple in this one, there weren’t any. Yay!
• Double player feature – One of the features I’m more fond of. I thought of the concept of controlling two adventurers while designing levels. It required me to completely rewrite most of the engine, but I’m sure people appreciate it.
• Gradual Difficulty – The game introduces new mechanics and gets progressively harder the more the player plays, which is something nice for a puzzler.

What went wrong?

• A little too hard – Especially on the last two levels.
• No easter egg – We love hiding the Lonebot logo in our games, but we didn’t know where to put it this time.
• Workplace – Because we didn’t plan on joining this Ludum Dare, we didn’t work at the same space which made development slower. Makes me wonder what the game would’ve been if we had worked at the same place!
• Stress – Because I barely had time to work on the game, everything felt a bit rushed, so appreciating the final result was kinda hard for me.

So that’s it! I would really appreciate if you play and rate our game! ♥

Here is a bonus of gif of level 19 being solved:

Thanks for the read. Until next time!

PS gifcam is awesome. You should check it out.

PSS It’s snowing in Lonebot.net!

Tags: postmortem

If you haven’t played my vertical-shmup-with-nonviolent-options, it’s here.

Origin

After going for a more novel (read: difficult to implement) time-travel-based game mechanic in my previous LD entry, I decided early on that I wanted to do something simpler this time, but focus more on executing it well. I also had space on my mind thanks to the recent beta release of Starbound. The first idea I had that I really liked was a top-down shooter along the lines of Elite or Escape Velocity, but where those games offer you numerous upgrades for your ship, you would only get one: maybe it’s a single weapon, maybe it’s a tractor beam, maybe it’s an afterburner or cloaking device or extra shields. To keep it simple, I decided to go with a vertically scrolling shoot-em-up to allow for simple, linear level design and not a lot of story to write, allowing me to focus on the mechanics. The first generic space pirate name that came into my head: Spacebeard the Pirate. Arr.

Things that went right

I think I did a decent job making a game that accommodates the different play styles offered by the different ships. If not, at least I learned from it. Namely, that offering three different mutually-exclusive options for how to play adds a lot of time testing every single level edit.

Art: To make the player ship, I just drew one “base” ship and changed the color, cockpit position, and weapon/device attached to the wings. This approach worked wonderfully as it allowed me to give each ship a distinctive look with little time and effort. I applied the same modular approach to enemies as well and was able to create a decent variety while maintaining a constant style.

Things that were cut

I originally narrowed down the range of ship abilities to choose from to four: a weapon, tractor beam, repulsor beam, and cloaking device.

The first three made it into the final game. The cloaking device would have allowed the player to sneak past enemies for a limited time. Of course, that would require more complex enemy behaviors, which I also dropped due to time concerns in favor of a simple back-and-forth-while-shooting movement. It also would have been difficult to make a fun stealth game on top of the rest of the game (and pointless considering ~75% of players wouldn’t experience it in one playthrough), so I dropped the cloak ability. Near the end I needed an NPC and was pressed for time, so I guess you could say the cloak ship still made it after all.

Things that went wrong

The cockpit is one pixel off center on all of the player ships. Somehow I didn’t notice this until it was too late. Grr.

Theme? Apparently the people commenting on the game aren’t picking up on my idea that you only get one ability on your ship. Whatever—I didn’t care much for the theme anyway because it was too restrictive in how you could interpret it (See: all of the games where “you only get one [life/projectile/unit of time].” No matter how good many of these games actually were, 100 other people used the same exact mechanic).

Pacing. Too much of the player’s time is spent waiting for enemies to come on screen. When tweaking the scrolling speed, I tried to find a balance between giving the player enough time to deal with the enemies and obstacles on the screen and moving forward fast enough not to be boring. If I ever work on this game more or make another vertical/side-scroller, I’ll give the player control of their ship’s speed and limit weapon ranges so less happens offscreen.

Level design: in retrospect, it was a bad idea to make the levels entirely out of asteroids. This probably confused a lot of players who picked the repulsor or tractor beam and wondered why they couldn’t manipulate the ones which were part of the level boundaries, which were poorly distinguished from the movable ones.

Poorly differentiated asteroids that serve totally different purposes. Pop quiz: which of these can you push with a tractor beam?

Tags: compo, postmortem

Hi guys!

Near to the end of the Ludum Dare 28 I had updated my entry, which you can play it here http://www.ludumdare.com/compo/ludum-dare-28/?action=preview&uid=11311

Remember to play the entry sended to the comp too if you had not played before.

Also, unity-chan! Yaaayyyy…

A post-mortem will soon be made, stay with me guys!

Tags: unity2d, unity3d

I worked on Bullets are Fatal in this LD (our team’s first entry in LDs), and particularly spent a lot of time working on getting the animations to blend in with the controls and physics.

Bullets are Fatal is a fast-paced 2.5D platformer/shooter built in Unity, where our scene is 3D with 2D props and characters. I decided to give Unity’s all-new 2D functionalities a spin and, while it’s clearly moving in the right direction, it’s still very new and requires a bit of workarounds.

I’d like to share with you guys a bit of how the process went and some insights on how we developed our platformer controls and character animation. If anyone would like more details I’ll be happy to explain =)

The first part of getting the character to work was to actually make him move, for this I created an abstract class to handle Inputs, from which each type of Input derives (keyboard & mouse, gamepad, AI). On top of that, a generic Character Motor reads data from the Input class to apply physics and movement to the character. This allowed us to use the same class for the main character as well as all our enemies. The enemies process AI and feed the AI Input, which is read by the Character Motor. Likewise, the player’s inputs are fed through the hardware input readers (which process latest activity to decide which one is being used between keyboard and gamepad) and read by the another instance of the Character Motor.

This is where animation comes in. With the art assets prepared and properly imported, the next phase of work started: making the different animations reflect user input and physics. Our character was built in several separate pieces: hat, head, eyes, nose, mouth, torso, left arm, right arm and legs. Most parts have 4 variants, allowing us to mix and match to create many different combinations. We also created a shader for color replacement, so that we could make a base color somewhat like a chroma-key, and just replace that shade with whatever color we like to create more variations. Although this worked, we didn’t have time to implement a character maker, so a default light-blue clothing was the only color that our little dude ever wore.

 This is an example of the “Jump” animation for the 2nd variation of our hats.

Each body part has it’s own Animation Controller, controlled by an animator script, which reads data from the Character Motor. For this the character has a Game Object for each part, with a Sprite Renderer and an Animator. Aside from all the normal variables, they had another one called ID, which was a key for a blend tree that would switch what variant of that part was the currently selected one.

This also allowed us to implement different behaviors for each part, such as a second layer for the left arm (the one that carries the gun) allowing the “Shooting” animation to be played at any moment, blending it with whatever animation was being played by other parts.

The hardest animation to get to work is the jump. At first we had anticipation, but we quickly realized that doesn’t work well because either the character starts sliding on the floor during the anticipation or you lock him in place, which is very quirky and annoying. Having removed that, the whole Jump had to be split into what we called Jump and Fall, where the first part is during the ascending part and, once the apex of the trajectory is reached, the Fall comes in. This also allowed us to easily use the same animation for cases where the character actually falls from a platform without jumping. At last we made a quick landing animation, which plays once the character is grounded. Once again, we thought of having an anticipation to landing, but that would require predicting the trajectory, which isn’t pleasant and very prone to bugs. So we cut those frames out from the animation and kept landing, with an additional rule to the legs, where the “Run” animation overrides landing in case the character is moving horizontally.

All this, unfortunately, took longer than expected, leaving no time to actually tweak values such as running speed, jump acceleration and maximum height, sensitivity and physics behavior (such as keeping momentum or not and how fast should the character “brake”).

In post-compo version we addressed this (albeit still some issues to solve), but we learned quite a lot in the process.

Here’s a quick view of the animations in action!

With a little over a week left in the voting process, I figured I would put together a postmortem on my first ever Ludum Dare entry, You Are The One.

What went right?

• Design: I have only taken part in one game jam previous to this Ludum Dare. In that project, I dreamed far too big and tried far too much. When designing You Are The One, I knew I had to keep it simple. The game would be 2D, use basic physics and cameras that I was already experienced with, and require as few assets as possible. It would also avoid complicated mechanics until it could be played start to finish. I didn’t mind cutting features from my initial design, but I was determined to at least implement the 5-level progression and celebration screen.

• Audio: Audio was a big concern of mine initially. I had no plan for music, and I wasn’t sure how well the sound effect generator I was using, sfxr, would fit into my project. Luckily, the sound effects were perfect and matched my retro/basic art style. While wondering about music, I came across a program called GXSCC that could translate a .midi file into a chiptune sounding .wav. I’ve played guitar for many years and use TabIt to store all my tabs which, turns out, supports exporting to .midi. With this knowledge, I put together 2 small loops for the game and they came out perfect.

• Completeness: I think there’s something psychologically satisfying about finishing a game. My entry needed to be finish-able, and more than that, it needed to push the player to do more. That’s where the idea for level-specific collectibles came from. If you collect all the items, the ending congratulates you on your hard work. If you don’t, it still congratulates you but hints that there’s more to do. I wanted my entry to feel like a real, full game that just happens to be really short. I think I accomplished that to some degree.

What went wrong?

• Adherence to Theme: While there is an extensive use of “one” as a theme throughout the entry, adherence to “you only get one” is a bit flimsy. Each level has one color shade, one item to collect, and the player character is literally a “1” with feet and eyes. While clever, it would be a stretch to say these attach to the theme well. The real use of the “only getting one” comes from the player only getting one direction they may progress in. This is a bit different than just getting one direction of movement, because the player can move both left and right on some levels. While matching the theme, it’s a bit convoluted as an implementation. I wish I had spent more time riffing on “one” as a limitation instead of “one” as a concept in and of itself.

• Enemies: My initial design called for one enemy per level, and a progression of difficulty stemming from that. Level 1 enemies would be stationary obstacles, level 2 enemies would shoot at the player, level 3 enemies would move around, and level 4 enemies would both move and shoot. Finally, level 5 would combine all the previous enemies the same way it combines the previous level’s movement styles. Unfortunately, I did not find enough time to design or implement enemies and opted for pits and spikes as the primary hazards. To give you an idea of how little time I would have had for enemies, I only implemented the spikes in the last 2 hours of the competition.

• Difficulty: I like to speedrun Mario platformers, specifically Super Mario World, as a hobby. As you may imagine, this colors my design philosophy when it comes to platformers. I tend to design levels to be rushed through at full speed, and completed through a series of expertly timed jumps. This can be problematic for people with different play-styles or less patience. My game is definitely too hard in its current form, but I hope the “skip level” button will enable all players to see the full game.

What did I learn?

• Unity’s 2D tools are… okay: While starting the new project, I noticed Unity now asks if you want to use 2D or 3D defaults. Since I was new to working 2D, I got excited and went with 2D. While many of the defaults assisted my creation process big time, most of the 2D tools went unused. Without a 2D Character Controller, I would have to use a rigidbody2D in its stead… and I wasn’t really prepared for that. Additionally, I had some trouble with the standard Character Controller colliding with 2D colliders. I eventually settled on a mix of the two systems, using the standard 3D components while taking advantage of the 2D scene view and sprite importer.

• A great game begins with a great plan: I accomplished almost everything I wanted with this project, and I chalk that up to a smart, flexible design. The project began basic, and added complexity, such as the items and spikes, only once the groundwork was in place.

• Ludum Dare is tons of fun: Not much more to say than that. I had a total blast taking part in the competition, from brainstorming to wrap-up. I look forward to joining future Ludum Dares! Just need to figure out how to do those awesome time-lapse videos between now and then.

Tags: LD28, postmortem, You Are The One

Hey!

My name is Luke, and I was the one who created the jam entry ‘Simple Ships‘.

Simple Ships is a 2D game made in hard Java. You have to avoid meteors, will increasing your score. You use only one button, throughout the game: the SPACE BAR.

You use the SPACE BAR to start, then the SPACE BAR to change which way the ship goes: left or right.

Pros of the Game:

• 8bit Graphics
• Interesting Concept
• The nice Feel
• Its Simpleness
• Ties in with the theme (Only one Button)

Cons of the Game:

• VERY Resource Intensive (this is due to the fact that everything is pure Java, no libraries, and lots of unneeded code. Well, not unneeded, but ridiculously crap. but what do you expect, I started 40 hours late.)
• No Sound
• Rectangular Graphics (I wanted them smoother, but I suck at art, so…)

But, all in all, it was a very interesting and joyful experience, and look forward to doing the next one.

Happy New Year <3

Luke