Posts Tagged ‘haXe’

Refuge – Unfinished

Posted by
Monday, December 12th, 2016 6:06 pm


Well, we ran out of time so it’s unfinished, but I had a lot of fun. I don’t really know what I’m supposed to say here, but you can try it out for yourself over here. We might finish this at some point and turn it into a proper game.

Holy wars

Saturday, August 27th, 2016 2:39 pm

Map of the world in parallel universe

The most ancient technology of controlling humankind is religion.
So we are making the game about you being a prophet on the recently discovered parallel universe.

It will be a multiplayer game with spectators. Everyone can watch and when feels confident enough to be a prophet can join the game and write his own holy book.

Stay tuned.

Still working on my LD34 entry

Posted by (twitter: @EdoardoLopes)
Tuesday, April 19th, 2016 11:22 am

Hi people!

View post on

Just wanna show the progress i made on my LD34 entry so far. It is a procedural generated action game. I’ve been working hard to make this a fun game to play.

I’m always posting stuff about it on my twitter and tumblr, check it out if you wanna follow the development of the game.

Congrats on everyone who participate on ludum dare!


I’m in

Posted by (twitter: @EdoardoLopes)
Friday, April 15th, 2016 7:36 pm

This is my base code;

I’ll be using Luxe Engine as game engine!

Digital Apathy in

Posted by (twitter: @espenb)
Friday, April 15th, 2016 4:57 pm

Digital Apathy with 2 members in this time – plink and dj_pale

Tools of the trade:

  • Gfx – Photoshop + asesprite
  • Sfx – ?
  • Music – Most likely Garageband if we have time
  • Programming language: haxe
  • Game framework: luxe engine
  • IDE – Atom

We’ve prepared some templates that we might or might not use based on haxe and luxe here:

Good luck everyone!

I’m in!

Posted by (twitter: @@nLoj_)
Thursday, April 14th, 2016 6:39 am

Hey folks! I think this will be the third(?) time I’ll be entering the LD Jam. Perhaps this time, I’ll actually finish something? Who know huh..

I’ll be programming in Haxe, using the OpenFL framework.
I’ll also try to use vector assets done in Inkscape since i suck at art.

Should be fun, right?

Sector 9 Post Mortem

Posted by
Wednesday, January 6th, 2016 9:20 pm

Hi all!

I made a game using Haxe and HaxeFlixel. I used the “two buttons” theme, play the game here:

This was my first Ludum Dare and my first game jam as well (I’ve been developing games for about 6 months). I had a lot of fun! I am really proud of being able to finish on time. Thanks a lot to everybody who participates in LD. Reading games’ source code, and seeing all the art of previous LD jams has taught me a lot!

Anyway, here’s my post-mortem:

Software Used

Haxe and Haxeflixel
Intellij IDEA + haxe plugin for development
Photoshop PyxelEdit and Tiled for graphics
Cubase + Komplete for music

What went wrong

Main theme disconnect and mood/humor issues

I found it really hard to connect initial intro story to the game itself. The plot was sad (end of humanity), but the gameplay side of the game, specially the hero running animation were more on the fun side. I had the same issue with music. The music I made was good for the initial title screens and intro, but it didn’t fit with the game itself. This forced me to ditch the main theme music which I spent on hours and throw in something quickly in 20 minutes.

Doing “mood” music composing practice sessions will help get rid of the issue.

It took me forever to get the initial art right

I wasn’t able to come up with good art on the first day. Everything I’d make I would hate, colors were completely wrong. I really fought through it until I came up with something decent. If I had to say what was the turning point on graphics, I’d say it was using references, specially for color. I found a couple of examples I liked (which I wish I had to share, same goes for the first day art), and used the color palette in PyxelEdit. Also it really got easier once I got the main background done. After that, I had a couple of really productive hours making objects for the game.

If I used references from the beginning, I could’ve spent more time designing levels.

Not enough time to play test game difficulty

On the last couple of hours I rushed game level design and I ended up with a last level that was way too hard. I know these games are supposed to be hard, but it’s just too damn hard lol! I made the last part of the game intentionally hard, so it’s really my fault. I’ll aim for easier levels on my next compo.

Also, my game is made for long play sessions. Most people who play LD games are other developers who are in a rush to try other games. So next time, I should design a game that doesn’t last more than 5-10 minutes. That way people will have the satisfaction of finishing the game, which will help increase the fun score.

What went right

 I was ready 

I didn’t have any project setup problems. I got everything up and running super fast. Haxe and haxeflixel are great!

I kept it simple

I had a number of ideas for the compo. I almost chose a much more complicated idea. Sticking to a simple idea was a great choice that allowed me to spend time on what’s the hardest for me: art.

I wasn’t distracted

Life happens to everybody, and I was lucky enough I give a lot of time to the game, and had pretty much no distractions at all.

Overall it was a great experience. Next time I’ll make sure I track my progress. Now that I am finished, I wish I had builds foe the game at different times of the compo, same thing goes for the art.

My Twitter:

Nunsaram – post-mortem? what?

Posted by
Wednesday, December 16th, 2015 2:24 am

This is our first jam, and I guess it could be called a success because we made it!

quite a late post, but still…




We (me and endwl) made a game called Nunsaram. Nunsaram is the Korean word for snowman.

We had a fun time. I learned how important goals were, and also how to package & distribute games. Endwl learned how to do good pixel art.


We actually made a gigantic u-turn around the 48 hour point. We were adding too much “new”/unplanned aspects to the game, and we had reached a limit. Slow typing speed, too many bugs too fix, too many pixels to color, and thus, low morale. Eventually we reverted to our original idea and half the code in Game.hx rendered useless.


Oh yes. i used Haxe + OpenFL on Sublime Text. no IDE. not this time.

Endwl used something, but I don’t know.

We used a Yamaha piano and Audacity and sfxr for the sound


I’m getting the timelapse (29 hours whoo!) together, so it’ll be up soon.


Next time, we’re gonna focus more on the “original goal” and save time for sound and stuff.


Happy holidays! and vote Nunsaram pls


p.s. what is a post-mortem (I’m new)


Posted by (twitter: @antonuklein)
Tuesday, December 15th, 2015 12:58 pm

Well, that was fun. I did my first Ludum Dare and now I’m slowly playing through a bunch of entries and sometimes just voting on them in batches. But let’s go over my game, Combat Hell, and let’s see what I did right and wrong.

Combat Hell followed the theme of ‘Two Button Controls’ and it an immediate decision that that would be the best way of playing it. The actual idea of it being a topdown dogfight was made actually about a day before the jam started, when I was thinking of good potential themes that I’d like to do. Other ones included ‘One Massive Enemy’, ‘Generations’, ‘Death is not the end’, ‘Death is useful’, ‘Strength in numbers’, and ‘Isolation’; most of these would work with my current concept, but some would have worked better than others. Actually, I think stuff like ‘Death is Useful’ might have made for a better game in the end.

The game idea was simple: You’re a hired mercenary by a dick, and your job is to fly around and kill enemies. That’s it, and I took the idea of gameplay from Combat’s jet sections, where you and another player would duke it out across the solid sky; now I wish I took its controls too.


The game was released initially as a Windows standalone game, and it was later ported to Newgrounds. The game has 26 votes, the standalone version has 35 downloads, and Newgrounds has 294 plays (although most of them are likely from Newgrounds). A bit lower than I expected, but at the same time, people have already noticed my little game, so I’m pleased.


Even though my execution was, uh, slightly shite, the idea of using the mouse as a directional pad and as a means of attack led to a risk-reward situation, where you could either be running away or fighting. On top of that, I had some basic different ways of attacking, although the balance absolutely broke in your favour as soon as you got even a single extra shot, especially with weapons such as the RNG shot (the ? ‘powerup’ that made you spread bullets everywhere). Honestly, I think that added to the life of the game, and I gave similar powerups to the enemies as well. Overall, that was a good choice.

Also, I’m pleasantly surprised as to how well the shop came along considering I coded its entire functionality in about 3 hours at the literal end of the jam, while also balancing the game to be a bit less random (didn’t help much though), and I had tons of issues getting the buttons and text working. If I were ever to go back to this, I’d have a 48×48 spritesheet (each of the 9 corners and middle fill), and stretch that to be the text box. That’s have worked better than the quick textbox I drew, as well as having another font instead of HaxeFlixel’s default.

Armour restores. Armour is taken away constantly and while it slowly recharges, there’s a powerup that gives you 60% of your armour back; that was such a last minute addition, I literally changed the code to throw out a -1 in the powerups, since any other value would mean you’d have to take the time and fix it, while I had about 20 minutes left.

The postrelease Flash port worked amazingly, I’m actually surprised that it ran almost as well as the standalone version, although the lack of fullscreen led to players clicking outside of the box. I wanted it to be HTML5, but I couldn’t figure out how to get rid of the right-click menu, so Flash it was.


This should totally have been a topdown plane Borderlands. Forget the powerup system (well except for the purple ones, those are nice), enemies should have dropped weapons with some random stat modifiers and you should have been able to select which weapon to use when flying out; if you don’t like a certain weapon, you could have scrapped it and forged either a reroll to your current one (so you could have some better modifiers, or even just changing the numerical values), or you could have made a brand new one. Persistent XP would have helped with this. If I ever get the chance to expand it, I could have a weapon slot, a hull slot, and an armour slot (since you need all three), and make the game be faster pace as a result.

The code became a mess over the last hour, trying to get it to work okay. Here’s a useful hint, don’t read it. It’s a mess, especially since the indentations broke and in the end, I’m not sure what I was coding. I mean, it worked, but still.

The movement controls, while neat, are horrible when trying to get to a corner or even going in a straight line, as the way I coded it in made the plane just fly around like it’s Pluto. Boo.

Music is just grating, I just transcoded it in an hour to a tracker file and then threw the resulting ogg into the game. At least I added in a mute button. Everything’s wrong with it, sometimes I think it shouldn’t have even been in the game. I wanted to have a military-like drumming with a strong lead, but… yeah.

I also ran this on a Llano AMD laptop processor with a clock speed of a whole… 1.4GHz. I had slowdown; now I’m not sure whether it was my code that was unoptimized or my computer was struggling to run HaxeFlixel, but it ran bad when it had over 100 entities on screen, counting the bullets. Probably my enemy plane code was unnecessarily complex, I never profiled it. Hilariously enough, I couldn’t do any work for the first few hours since both of my copies of Photoshop died, so I had to quickly get a copy of CS2 running, and FlashDevelop wouldn’t do autofill at all, so I reinstalled it and HaxeFlixel and Haxe and OpenFL so many times… it was a mess.

The shopkeep is too much of a dick because you need $1000 to unlock the sadist mode (please don’t play it), but that’s my fault. I could have fixed it really easily, but I was limited on time and energy at this point.


Overall, it’s a solid little game that could have used way more polish and a few extra days to clean up the whole thing. This took me 28 hours to code, counting the time I tried even getting anything on screen because my IDE wasn’t as fully tested as I’d’ve liked, and it was a great learning experience.

This was coded at Winnipeg’s Ludum Dare game jam, where I saw a bunch of awesome folk. Huge thanks to Dylan, Graeme and everyone at Owlchemy, ACI, and New Media Manitoba for hosting this event, this jam was awesome.


Posted by
Sunday, December 13th, 2015 10:12 pm

This was a productive weekend, even if there are still lots of things that I would tweak or add. I’ll leave the details for the post-mortem, but I’m quite happy with the result, I can actually play the web version on my phone! I know this sounds really stupid, but I was surprised at how well it worked considering that I wasn’t thinking of mobile platforms at all

Behold “Fun with magnets!”

i’m in

Posted by (twitter: @EdoardoLopes)
Friday, December 11th, 2015 8:54 pm

I’ll use:

Haxe as progamming language

Luxe Engine as Game Engine

Aseprite for graphics

Sunvox for music

Here’s my base code, with some boilerplate code for collision, camera, tilemap, window resize etc…

Declaration of base code!

Posted by (twitter: @blubberquark)
Friday, December 11th, 2015 12:55 pm

I have written some base code to import Yarn conversation files into HaxeFlixel and called it FlxYarn.

look at it here:

Are you tired of writing your dialogues in HaxeFlixel games as big nested if-statements inside of monstrous loops? Then FlxYarn might be right for you!

two talking heads and speech bubbles

I have built a Yarn parser, loader, NPC dialog engine and speech bubble UI for HaxeFlixel. I finished just in time in time for Ludum Dare. Now we can split up the work on a story-driven game into code(Haxe), levels(Tiled) and dialogue(Yarn). Each NPC has his own state machine.

Conversation nodes can contain multiple speech bubbles and dialog options. Nodes can contain Haxe code for scripting, which will be executed with the HScript interpreter. You can share variables from your Yarn state with the game code.

screenshot of conversation node syntax

The Yarn dialogue editor was built by Alec Holowka and heavily inspired by Twine. The syntax you see above is half my own design, half based on Yarn and HScript. The <<run $X>> macro runs haxe statements. The <<print $X>> macro evaluates Haxe expressions and pastes the result into the conversation state. Links to other nodes have the same syntax as in Yarn and Twine.


yarn conversation state graph

Get Yarn Here:

Try out the cobbled-together nonsense Demo conversation between the neo-baroque technocrat and the spaghetti wizard (requires Flash):

LD34: I’m in there like swim-wear

Posted by (twitter: @IamJacic)
Thursday, December 10th, 2015 12:35 am

Well, I’m in for yet another Ludum Dare My tools this time around will be the same as last time (and many events before):

Language: Haxe

Engine/Framework: HaxePunk

Graphics: GIMP

Sound: sfxr/autotracker

Energy: Coffee

Remember to vote for “Build your weapon” for the theme!

Let’s make this the greatest game jam of our lives!


Posted by (twitter: @AurelDev)
Saturday, December 5th, 2015 12:57 pm

Here we go again.

16th time entering (21st including mini LDs), 7th time submitting (hopefully!) and it’s time for some changes once again. As much as I disliked the trend of Flash dying, I guess I’ll get over it – might try to go for HTML / JS this time, if I get my libraries running for JS. So:

  • language and compiler: haxe
  • IDE: a terminal and TextMate
  • graphics: Photoshop, a Wacom cintiq tablet
  • audio: custom libraries?
  • fuel: pistachios, sushi

And a wallpaper teaser:


So, good luck everyone!

Melody Muncher Post-Mortem

Posted by (twitter: @ddrkirbyisq)
Saturday, September 12th, 2015 11:15 pm

Hi there!  DDRKirby(ISQ) here with my =10th= LD entry (wow!), Melody Muncher!


Link to play and rate:

This one was a blast to make, and I ended up working for 2 weeks to make the Post Compo version (out now!), adding a new mechanic, animated backgrounds for each level, more songs, 3 separate difficulties, and more!

When the theme was announced this time as “You Are the Monster” I was actually quite disappointed, just due to the fact that it was so similar to “You Are the Villain”!  I mean come on guys, really?  But now that I think of it, You Are the Villain was EIGHT LDs ago, so I guess I can’t fault people too much for it.  I wonder if anyone decided to redo the same game concept that they did for LD25?  It would be an interesting challenge, just to see how far your game jam skills have come over the past years…

Anyways, despite my initial dislike for the theme, my idea and game came together really smoothly this time; I can’t even remember running into any hiccups at all!  As always, let’s go over what went well and what didn’t go well.


What went well:

Avoiding other commitments during LD weekend
Almost every other LD I’ve done, I’ve had =something= else to attend to over the course of the jam, usually on Friday night.  Usually I tell myself that it’s fine and that I can just try to brainstorm in my head while that happens, but to be honest, that never quite works out and it’s basically like I start off behind by 4 hours already.  This time I decided that I really was just going to dedicate the whole weekend to LD and besides some driving here and there and dealing with meals (gotta eat!), I was just heads down working the whole time, which was GREAT!  An exhausting weekend, for sure, but I don’t think there’s any way around that.  For Sunday, after breakfast and running a quick errand in the morning, I pretty much worked straight through the entire day until the deadline…I stopped twice for the bathroom, once for refilling water, and once for a massive yawn/stretch…that’s it.  Hahaha, you other LDers will know what I’m talking about…Sunday is usually that day when it’s like “omg I have 5 hours left and I still have to add in 2 more enemy types, also my game has no menu, title, or tutorial and I haven’t tested the difficulty at all AHHHHHH”.


Game concept and execution
As mentioned earlier, everything came together really smoothly for Melody Muncher, without a hitch, really!  I spent Friday night doing my usual brainstorming routine, and considered plenty of other possibilities, but the idea of having the piranha plant munching guys as a rhythm game occurred to me pretty early on, and it clearly had the most potential while also playing to my strengths, so I went for it.  Huge success!

Level data layout
One of the reasons I was able to cram in six (!) full songs to the 48hr version of Melody Muncher was because I made sure the levels were really easy to program in.  Unfortunately this was NOT the case for my previous game of this genre, Ripple Runner.

Here’s what a level definition looks like in Ripple Runner:

// Section 1
addPlatform(startTime + -10.0 / bps, startTime + 36.0 / bps, -40, timingWindow, level);
addPlatform(startTime + -10.0 / bps, startTime + 36.0 / bps, 40, timingWindow, level);
addPlatform(startTime + 37.0 / bps, startTime + 44.0 / bps, -40, timingWindow, level);
addPlatform(startTime + 37.0 / bps, startTime + 44.0 / bps, 40, timingWindow, level);
addPlatform(startTime + 45.0 / bps, startTime + 52.0 / bps, -40, timingWindow, level);
addPlatform(startTime + 45.0 / bps, startTime + 52.0 / bps, 40, timingWindow, level);
addPlatform(startTime + 53.0 / bps, startTime + 60.0 / bps, -40, timingWindow, level);
addPlatform(startTime + 53.0 / bps, startTime + 60.0 / bps, 40, timingWindow, level);
addPlatform(startTime + 61.0 / bps, startTime + 62.0 / bps, -45, timingWindow, level);
addPlatform(startTime + 61.0 / bps, startTime + 62.0 / bps, 45, timingWindow, level);
addPlatform(startTime + 63.0 / bps, startTime + 80.0 / bps, -40, timingWindow, level, true);
addPlatform(startTime + 63.0 / bps, startTime + 80.0 / bps, 40, timingWindow, level, true); Checkpoint(startTime + 64.0 / bps, -40));
// Section 2
 addPlatform(startTime + 80.0 / bps, startTime + 100.0 / bps, -40, timingWindow, level);
 addPlatform(startTime + 80.0 / bps, startTime + 108.0 / bps, 40, timingWindow, level);
 addPlatform(startTime + 108.0 / bps, startTime + 116.0 / bps, -40, timingWindow, level);
 addPlatform(startTime + 116.0 / bps, startTime + 120.0 / bps, 40, timingWindow, level);
 addPlatform(startTime + 120.0 / bps, startTime + 124.0 / bps, -40, timingWindow, level);
 addPlatform(startTime + 124.0 / bps, startTime + 126.0 / bps, 40, timingWindow, level);
 addPlatform(startTime + 126.0 / bps, startTime + 128.0 / bps, -40, timingWindow, level, true);

And so on and so forth.  And that’s only the =first half= of the EASIEST level.  Yuck!  Unfortunately I was super duper hacky while coding up Ripple Runner so the way that I constructed the levels was actually just by placing each platform individually.  This involved tons of hacks, especially trying to deal with assymmetrical timing windows which varied according to which kind of obstacle you were using (spikes, rippling, jumping), and a bug that prevented me from creating single platforms that were too long….etc etc.

Thankfully I didn’t repeat the same mistake this time.  Here’s what a level looks like in Melody Muncher:

result.SfxName = "sfx/level3";
 result.BeatDivision = 2;
 result.BeatPixelLength = 80;
 result.Left = 
 "........ ........ ........ ........" +
"1.....1. 1....... 1....... 1...1..." + "1....... 1....... 1.....2. 1...1..." +
 "1.1..... 1...1.1. 1....... ........" + "1...1.1. 1.1..... 1....... ........" +
 "1.1..... 1...1.1. ........" + "1...1.1. 1.1..... ........" +
 "1....... 1....... 1.....1. 1...1..." + "1.....2. 1....... 1....... 1...1..." +
 result.Right =
 "........ ........ ........ ........" +
"1....... 1....... 1.....1. 1...1..." + "1.....2. 1....... 1....... 1...1..." +
 "1...1.1. 1.1..... 1....... ........" + "1.1..... 1...1.1. 1....... ........" +
 "1...1.1. 1.1..... ........" + "1.1..... 1...1.1. ........" +
 "1.....1. 1....... 1....... 1...1..." + "1....... 1....... 1.....2. 1...1..." +

Much better!  Here I’m using “1” to indicate a green enemy, “2” for a red enemy, and “3” for blue enemies (which don’t appear in this particular level).  I ended up using “[” and “]” to denote the yellow centipede enemies in the post-compo version.  The periods just indicate points where there are no enemies, and spaces get automatically ignored.  It’s still perhaps not 100% ideal as I still had to build up separate strings for the left and right sides of the screen, but overall inputting notes for songs went pretty quickly.

Coding it the Right Way
So, again, for Ripple Runner I used a bunch of stupid hacky coding, and as a result, even though your X position in Ripple Runner is locked to the position of the song (good!), your jump height and y position is not (bad!)–it’s actually just normal platformer gravity.  This led to some pretty clumsy manual hacking about to get the gravity to be correct for each level (it needs to be adjusted for each BPM setting!), and in general just led to sad times within the code.  The end result still ended up just fine, but…

When it came to program Melody Muncher, I had learned my lesson, so I made sure to do everything right.  The position of all of the enemies is dictated solely by the position of the music, and there are NO collision boxes or movement physics or anything!  Each enemy knows what beat it should be hit on, and the enemies on either side are kept in an Array, sorted by order of arrival.  When you press left or right, we run through the first part of the Array looking for enemies whose beat is within the defined timing window–no collisions or any other nonsense needed!  Very clean, very sensible, and the code was much better and simpler as a result.


Post-Compo Version
This might not technically count as something that “went well for LD”, but this was the most fun I’ve ever had working on a Post-Compo version of a game I’ve made.  Probably because of the above two factors, and also because I knew I had something with a lot of potential.  Making new songs and mechanics was a blast, and even though it took a lot of work to add all of the new features in the Post-Compo version, I’m super happy with how it turned out, and I believe this is my most polished game ever as a result.


What didn’t go so well:

Input Delay and Lag Calibration
Okay…so this was mostly a stupid mistake.  So one of the mechanics in the game is that after a few levels, enemies can come at you simultaneously from both sides, so you have to press Left and Right at the same time to do a split munch.  Simple enough, right?

Well, on the coding side, I implemented this by having a separate animation — one where Ms. Melody has two heads that are each attacking.  (As it turns out, while working on the Post-Compo version I had to redo this and just implement each head separately to allow for the yellow long centipede enemies to work)  I then also decided that because people probably weren’t always going to hit left and right at exactly the same time, what I would do is this:

When you first hit left or right, the plant transitions into a “getting ready to attack” state (with a different animation frame) and waits for a frame or two, during which you have the opportunity to input the other direction.  Once the frame or two is up, the attack actually happens.  So this was good because even if you hit left on frame #1 and right on frame #2, you still get the split munch on both sides.

The problem is that by doing this, I essentially delayed every input (as well as the resulting “munch” sound) by something like 17 or 33ms.  Now, that may not seem like much, but in a rhythm game where your actions need to be really tightly synced, you can really notice, and people did.  Add that to the fact that my default lag calibration for Flash builds was slightly off (I had to shift it by maybe ~50ms compared to native builds) and people definitely felt that their inputs were delayed.  Now, part of this was that I simply didn’t have enough time to program in a robust and user-friendly lag calibration setting (it’s much better in the post-compo version!), but most of this was just my own fault for adding additional input delay unnecessarily.

The good news is that the post-compo version fixes this entirely, and if you compare the two the post-compo version should feel MUCH better.

Missing was too punishing
In the original 48hr version of the game, if you try to attack when no enemy is on the corresponding side, Ms. Melody does this ugly faceplant animation which leaves you stunned for a half beat or so.  This was designed intentionally as a means of punishing you for trying to attack when there was no enemy, as well as to eliminate the cheesy strategy of just trying to munch on both sides on every single eighth-note beat.  If you didn’t have the recovery animation, you’d just be able to do that and get a perfect score, which was obviously no good.  I had been trying to think of various ways to solve that issue, and after trying it, this seemed like a clean solution, as well as making it very unrewarding to miss notes, which is what I wanted — it should feel good when you hit enemies, and bad when you miss enemies.

Well, the problem is that players don’t like feeling bad.  One of the complaints that I got was that the recovery time for missing was too long and it led to people feeling like the game was “unfair” (ugh, loaded term).  Now, if you’re used to rhythm games, you probably didn’t mind this as much, but if you’re not a rhythm gamer, what happens is that you miss one enemy, then because of that your input for the second enemy doesn’t register (since you’re still in recovery), which throws you off and then you end up missing again ……, in the end that’s a situation that just doesn’t really feel good.  So lesson learned — reward your players for succeeding, but don’t punish them for failing.

The solution in the post-compo version was to eliminate the recovery delay and just add in a proper scoring system that adds points to your score based on your current chain, a la Guitar Hero.  Now I no longer need the recovery delay because if you try to use the strategy where you attack both sides on every eighth note, you’ll keep on breaking your chain over and over again, leading to a poor score.  Problem solved!  But unfortunately, I just didn’t have time to get the more fancy scoring system and everything done in the 48hr version.

No Shovel Knight
Okay, so this wasn’t really that big of a deal, but when I was drawing up the graphic for the red enemies I knew I wanted it to be something big, beefy, and blocky, so I went with an armored knight.  Since it was a knight, I decided to give it a sword.  I even referenced some Shovel Knight images as I was drawing it up….but for SOME reason I missed the golden opportunity to just have my Red Knights carry shovels and be “shovel knights”.  Which would have made perfect sense (they’re trying to dig up Ms. Melody), AND would have been a great callout to a great game.  Biggest missed opportunity everrrrrr =(

48 Hours!!!!
Alright, I guess this isn’t really something that “went wrong”, but it still amazes me every time how quickly the 48 hours goes by, despite you wanting to cram in more and more features.  “If only I had 1 extra hour!!!”  This was apparent this time around as well; the submitted version of my 48hr entry was missing some key components that I really really wanted to get in, but I just. did. not. have. enough. time.

Specifically, better lag calibration was one item high-up on the wishlist that I didn’t end up getting to squeeze in until later.  It wouldn’t have taken long, either!

And, changing backgrounds was another real big item.  I had a hue shifting effect that I used in Ripple Runner which worked fabulously, and I really wanted to do the same thing in Melody Muncher, because without it the backgrounds feel very static, especially when the music is very energetic and has these big builds and climaxes.  Of course, it turns out that because I’m now working in Haxe and Haxepunk, I can’t just use punk.fx (flashpunk) to do an easy hue shift; in fact I still don’t know of any good way to do hue shifting in Haxe/Haxepunk without digging into low-level RGB code yourself. =(  The silver lining on that cloud is that because I wasn’t able to do easy hue shifting, I ended up making much more intricate and involved animated background effects for the post-compo version, so it all works out. :)



And that wraps up another post-mortem!  Results will be in very soon–good luck to everybody and remember, the real prizes are your games, not your ratings!  Be sure to take your scores with some salt; sometimes you get scores that don’t quite make that much sense.

Thanks for taking the time to read about Melody Muncher!  Hope you enjoyed it as much as I did! :)

Postmortem: Slavery Simulator 2015

Posted by (twitter: @SebBernery)
Saturday, August 29th, 2015 10:34 am

Here is my postmortem for the 33th edition of LudumDare. Theme was “You are the monster”. You can read it on the vikindie blog.


My game is a basic tycoon game where you have to organize the “triangular trade” : get soldiers in Europe to capture slaves in Africa and produce new world’s goods to send them to Europe.

Slavery Simulator 2015

Final game

Idea finding

When doing LudumDare, I try to be original in the theme interpretation. I’m a little disappointed because my game doesn’t reflect what I planned initially to match the theme. I was thinking about moral choices for the player (“Pay 100 for a medic or 10 slaves died”, …) and I wanted to have an authority in the game trying to fight slavery, with some navy tracking your ships, and laws passing like Habeas Corpus. The goal was to create frustration for the player so he could say “Oh, fuck, humans right bill passed”. The idea was that “YOU are the monster” don’t designate the game character but the player himself.
I love tycoon games and was very happy to create one for LudumDare (I usually create character centered games).


I used HaxeFlixel. It’s my 4th ludum dare game using that fantastic game engine. For the first time, I used it fluently (I praticed a lot last months). That was awesome.

The HTML5 export had never worked for me, so I planned to create a flash game. I live in France, so the end of the jam is at 3AM. Midnight, I said to myself “Hey, it could be a good idea to test if the game works with flash !”. Spoil: it didn’t. It was VERY slow and buttons was all the same color (the button’s color is an important thing, I will speak about it later). I spend some minutes to optimize the game but it was still too slow and buggy. So I tried the HTML5 export. I didn’t belived. It worked. That was awesome (let’s be honest, I don’t like flash).

I still use a proven and reliable IDE : vim, tmux and my personnal configuration ;-). If you are interested, here is my vimrc.


I used Krita… and tried to do something. I spent one hour to draw the map (saturday night, 1AM, before bed). Probably something like one hour more to create all buildings and the boat. No animation, no different images when buildings upgrade, … That pretty sucks and lead to a static game. But I consider that graphics are not very important in a tycoon game, and I hate those business simulation games where graphics go AGAINST the game (think about Railroad Tycoon 3 where the 3D hype leads to unreadable informations).

Yes, this is a Mapmonde.

Yes, this is a Mapmonde. This was my game before assets creation.


It was the last thing I did. It was probably midnight past thirty, I plugged a MIDI keyboard, opened LMMS, then Pixitracker, tried to do something audible … Nothing came. So I used Abundant music, it generates music procedurally. In less than one hour I had one music that correctly fits my games. Really happy about it, the game without music would be boring. The main problem, there is only one music, no sound effects and the music don’t transparently loop (you can hear the transition).
Next step, learn how to tweak the generated midi to humanly customize it.


Honestly, I was very lucky, my game system pretty works. I created the concepts and tested them individually but I only tested to play a complete game once. I changed things after that and never tested again before submit.
After submit I saw some issues :
When harbour storage is full, it displays hundred same messages every seconds. Logger window become useless and it may hides informations (like events).
The soldier price is not updated when you upgrade barracks, so I suppose many persons didn’t understood why upgrade barracks. In fact, the soldier price raise each time you buy one. When you upgrade barracks, you divide by 4 the soldier price.
When a boat is in USA, it loads tobacco first, then sugar if space left. Unfortunately, you can have big reserve of sugar in America but you can’t sell it. As you don’t sell it, price raise. But you can’t sell it, so it’s very frustrating. (And the sugar price raise too fast).

My saturday afternoon fuel : carrots and sun.

My saturday afternoon fuel : carrots and sun.


LudumDare games are usually played in something like less than five minutes and you have one minute to convince the player to continue his game session.
The best I could do would be an interactive tutorial, or at least, a visual help. I absolutly did nothing like that. The only help was a special screen with boring text.
To let people understand the game, I made color changing button depending of actions availables. With that, even if you don’t understand anything to the game, you just have to click green buttons and something good will happens.
The only exception is the boat parts which is always green but is not always a good choice to make.
My theory is that if the player randomly play by clicking on available actions, he will progessively understand what happens and the meaning of the actions (and of the game). After some time of random play, he will be able to do more intelligent actions because he saw what happened with his choices.
At the begining of the game development, the buttons which can’t be used (not enough gold, …) was hidden. This solution seems bad for me because the player is not aware of all actions available in the game and what to do to unlock them.

Theorically, there is a loose condition : if you don’t amass 5000 Gold until Jan 1700. There is an ending with a fucking awesome sentence, but nobody will see it because you can’t really loose. During my tests developements, I was able to do bad investments which leads to a situation where you can’t do anything (not enough money).
I didn’t want to frustrate the player which don’t know the game by letting him loose in the ten first seconds without telling him before 20 minutes of play. So I changed some part : now, all essentials first investments are done automatically : there is a village, a plantation and a slave. The first soldier is free. Even by doing whatever stupid, you will be able to slowly earn money to make better investments.


I’m very happy with this game. I hope you will enjoy playing it as much as me developing it. I wan’t to participate to october challenge, maybe I will reuse Slavery Simulator and continue the development, it depends on the users feedback, ideas to enhance the concept (already got some) and my motivation. Follow me on Twitter if it may interest you.

Here is my compo page : Slave Simulator 2015 . To play the game, it’s here.
Ps: don’t forget to look at Am I the monster?, game made by a friend who invited me in his appartment to do LudumDare and prepared me good tasting coffee.

[cache: storing page]