Posts Tagged ‘HaXeFlixel’

Enter Roach Escape

Posted by
Tuesday, December 13th, 2016 6:46 pm

I finally managed to get some sleep last night (Note to future me: always take the Monday after a Ludum Dare off), so before I write the postmortem and consider working on a post-compo version, here’s a shameless plug for Roach Escape, my submission for LD37.

Play it and rate it here!

Play it and rate it here!


As many people have reported difficulties understanding the first steps, I’m also going to share a Youtube link to a a playthrough of the first level to help clarify the first steps:


Posted by (twitter: @glisk_)
Monday, August 29th, 2016 5:15 pm

Hey folks! We made it! Here’s our game for the jam: The ZIGGURARK!



As an Explorer controlling half-cut, genetically recombined animals you have to wander through the dungeon of Tezcacoatlus, the Assembler God.

He’s a badass guy who has The Tool, an ancient relic capable of cutting animals in half creating hybrids. You take control of one hybrid and your goal is to get to the end of the eight levels in order to save your own life.

Hybrids has the good and bad sides of the animals they are made of: the body of a gorilla is extremely powerful, but its legs are slow.

…but what if you have the body of a gorilla running with the legs of a rabbit? You go FAST.

Move around with the arrow keys and fight with WASD, a-là Binding of Isaac. There are wooden crates throughout the levels: if you find one and you break it, you can recombine half of your hybrid with a new animal.

Because, you know, if you’re struggling with a turtle-rabbit hybrid maybe you need a stronger half… :-)



We are a team of two and we coded the game in HaxeFlixel, with art made in Pyxel Edit. It was our first game together (and absolute first with Haxe) and, even if it’s not as nearly as polished as we wanted, we had tons of fun making it. We made it in about 36 hours of work.

Entry page

Play it in your browser (OSX/Windows builds in the entry page!)

We hope you like it!

I really look forward to playing your games…


The Ziggurark: half-cut animals – First day

Posted by (twitter: @glisk_)
Saturday, August 27th, 2016 6:43 pm

Hey folks! This time I’m running for the Jam with Syrhmak, a good friend of mine who joined me as a badass artist.

We’re working on ZIGGURARK, a dungeon crawler with half-cut, genetically recombined animals living in a pre-Columbian Ark ruled by the mighty Tezcacoatlus.



How cool does that sound?!

You, the Explorer, after discovering the ZIGGURARK in the heart of the jungle, stumble upon an ancient tool used for recombining DNA and creating twisted biological hybrids.

Using the weapon, you’ll have to take your hybrid through the perils hiding in the dark rooms of the ZIGGURARK…



Code: HaxeFlixel

Art: Pyxel Edit

We’re almost halfway through! We already have 30 hilarious animal combinations (and we’re planning to add more), the intro splash screen and some basic levels. Basic game mechanics are in place as well!

Lots of fun so far… Good luck everyone! Keep up the good work!


Getting schwi…eeer…shifty – Postmortem

Posted by
Tuesday, April 19th, 2016 7:31 pm


Play it and rate it here! :)

This was a peculiar weekend and, as always, very fun and rewarding. After spending most of Friday on a train which arrived with an hour and a half delay due to most unfortunate reasons, I overslept and had a late start on Saturday. Then, even if I had a clear idea of what I wanted, I ran into some early problems because I’d forgotten about some really basic stuff related to the way Flixel handles positions. Luckily I managed to overcome all that and the end result this time has been more than satisfactory.

The idea came relatively easily. My first inspiration was Altered Beast, but that would have probably been overkill in terms of asset creation, so I discarded that and went for another classical genre with very clear references. Back on LD30 I had wanted to make a shoot-em-up where the “ship” actions in one world would affect interconnected ones, but unfortunately I run into some technical problems and couldn’t participate in the end. Ever since I’ve been wanting to resurrect that project or implement something similar, and the opportunity presented itself this time.


(From left to right, Ikaruga, Waves and Geometry Wars)

My references were immediate, too: the main one would be Ikaruga and its colour switching mechanic as key, but I also checked other two shmups I’ve always liked: Geometry wars and Waves. The connection to the theme is obvious (switch shapes for fun, profit and devastation), and decided to go full abstract/geometric instead of my original approach, where you would be some kind of a microscopic drone with Transformer-like abilities and your task would be to defeat viruses and bacteria. It’s a good way to achieve some pleasant visuals without having to spend a lot drawing.

What went well:

  • Controls. Having gameplay just feel right were a must, and this time I think I more or less made it :) I would have liked to add some acceleration to motion and so on, but making that feel right could have been tricky and time consuming, so I aimed for the basics first (orientating the sprites and aiming in particular).
  • Scope: By resorting to a well known genre with simple yet effective mechanics I managed to keep the game scope under control. Of course there are lots of things that didn’t make it, but the current result feels complete.
  • Development speed: As a consequence of the previous bullet point, having a restricted and clear scope and feature set I managed to keep a constant and fast development pace. That’s a huge bonus for motivation.
  • Visuals and effects: At the moment the game is getting some nice comments (thanks!) about the graphic style. They can still be improved, but it is true that they can make a huge impact on the perception of the game.

Now, the ugly:

  • Slightly chaotic process: I wanted to make up for the late start, so I just started coding as soon as I pinned down the basics of the game and completely forgot about planning for several hours on Saturday evening, when I finally decided to create my usual Trello board to keep the tasks and my progress controlled. This wasn’t bad per se, but I also made a risky gamble with version control, and I completely neglected it until it was actually time to submit. Then I created and pushed the sources to Github. I was very lucky, as I didn’t run into any problems or had to roll any feature back, but the next time I should at least be more careful with that just in case.
  • Not directly related to the competition or the game, but…THAT ARTICLE (you probably know what I’m talking about, I’m not going to give it any more publicity). I read it while on the supper break and got incredibly angry.

…and what went wrong:

  • Music and unbalanced volume, and glitchy mute option. The thing I regret the most on this edition is, no doubt, the music. I wanted to make some fast-paced tune with a psychedelic vibe, but I got stuck and, when I realised that there was only one or two hours left before the deadline, I chose to leave music as I had it and moved to UI coding. I need to practice a lot more on composing the game music. Besides, the effects volume was irregular, and muting them was glitchy.
  • Difficulty progression (or lack thereof): The game can feel very hard to some people, but for those who do master it, it gets monotonous. The truth is there was no difficulty balance at all. I managed to hack a “hard mode” in the last ten minutes before the deadline for those who managed to play for more than three minutes, but that’s still not enough. Another option would have been to have more things to do, but of course that would have been more time consuming. At the moment this is probably my main goal for the post-compo version.
  • Remembering Flixel: I hadn’t touched Haxe+Flixel since the last LD, and I regretted that this week. First I had decided to upgrade the pipeline to the last version. This wasn’t particularly problematic during the Ludum itself, but I had some old projects I wanted to check for references and they broke. Additionally, I always forget how anchors, pivots and positioning work on Flixel until I’ve spent a while re-checking it.
  • Performance, esp. HTML5: I wanted to release the main build as HTML5, but it wasn’t consistently performant. At the moment you can experience hiccups on any platformer when you shoot many ships or use the blaster, but playing on Firefox or Edge was veeery slow most of the time compared to Chrome, for instance. Interestingly enough, on another project I’m currently working on on Unity, the WebGL build runs into memory issues on Chrome but not on Firefox or Edge.

Next steps:

I’ve already made some changes to a Post-Compo version (you can also find it on the submission page), but I want to add many other features that couldn’t make it into the main submission. This is a list with some of the most important ones.

  • Different control schemes and gamepad support – DONE
  • Difficulty and player progression – STARTED, still a lot left to do.
  • Decent music, and fix that darned mute.
  • More content: Bullet patterns, enemy types and behaviours, pick ups,…
  • Better movement.
  • Better visual feedback: Put the previous/next hints right on the ship, clearer indications of when you increase your score multiplier or when the blaster becomes available.
  • Better graphics: This fits more as polish, but I would like to change the graphics for almost all elements of the game, make the lines of the ships clearer, replace some UI texts with icons or bars and perhaps add some nice and trippy background effects (like in the video below, but waaay more subtle). And many more particles! ;P
  • Better performance. Of course, to support all that and not burn people’s computers I need to optimize a lot, starting as soon as possible, as I already had some problems in certain moments of gameplay.
  • Tracking scores/times locally on a save file or, even better, keep an online leaderboard system somewhere.

LD Entry: SpinStar

Posted by (twitter: @gamepopper)
Monday, April 18th, 2016 4:18 pm

This is my finished compo entry, best way I’d describe it is what would happen if you cross Ikaruga with Super Hexagon, you’d get a difficult, fast paced bullet hell where you must switch colours to absorb matching bullets or dodge anything else.

To match with the theme, the boss shapeshifts and the player can shapeshift into one of two kind of ships a fast-yet-large or small-yet-slow.

I originally had both a HTML5 and Windows version, however there seems to be a problem with HaxeFlixel’s HTML builds being extremely slow even on high performing machines, even though this never happens on either Windows or Flash builds.

Vote for the game here or go play the game directly here.



Posted by
Sunday, April 17th, 2016 11:39 pm

Play it and rate it here

I spent around 30h working on the game and in hindsight I think that I could have really used a few of those other hours to improve the audio and, more importantly, finish/redo the music track.
Except for that, (and even then I still think it’s better to have something audible…as long as you can also mute it), I’m quite happy with the end result: Enemies aren’t so terrible as in past entries (there’s still room for improvement) and I’ve improved a bit at adding visual feedback.

If I give a few more hours tomorrow for a post-compo I might add gamepad support, debug that stupid mute glitch (I’m not sure if it’s due to Haxeflixel itself or if, more likely, it’s on this side of the computer), and create a decent music track. Of course, my TODO list on Trello has several interesting gameplay ideas and improvements that could be worth to check in order to expand the game, but I may leave that for a postmortem.

Well done and good luck to everyone! I’ve already seen some very interesting entries 😀

Sunday Dinner Progress

Posted by (twitter: @gamepopper)
Sunday, April 17th, 2016 12:15 pm

A quick progress update as I cook dinner:

View post on

  • Graphics! I’m using Piskel and Photoshop. I think there’s a bit of an late-70s arcade feel.
  • Added a third bullet, the white bullet cannot be absorbed by either colour phase so it should be avoided at all costs.
  • Few more bullet behaviours added in for difficulty.
  • Save data added, game will save the longest time for each difficulty.

View post on

Now the name on this title screen isn’t the final name, I’ve been struggling to come up with a good name so I’ve been asking around. I’ve now got four names I like and I’m letting the twitter folk choose the best one, so if you want to pick a name vote now before time runs out!

Saturday Evening Progress Report

Posted by (twitter: @gamepopper)
Saturday, April 16th, 2016 12:47 pm

So I’ve currently been working for 7-8 hours, so my current progress:

  • Came up with idea at around 3am, a bullet hell where you must last as long as possible by avoiding or absorbing bullets like in Ikaruga. The shape shifting theme will be when the boss changes appearance for each behaviour type. The player will also shape shift when changing colours as well.

My 3am notes…

  • Got my HaxeFlixel project up and running, good thing I updated and checked the template the day before. I’m still amazed at how much has changed and improved in HaxeFlixel over the year. It feels like a brand new framework every year!

Testing the colour switching and custom particle/emitter behaviour.

  • I’ve got player movement, enemy bullet patterns, the colour switching and some basic UI working. I’m on good progress to getting the core gameplay done by the end of today.

Custom bullet pattern testing.

Hope you like what you see, I’m gonna have dinner now, then more core gameplay stuff!

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:

Fun with post mortems!

Posted by
Friday, December 25th, 2015 7:34 am

It’s been more than a week now since LD34 finished, and finally I have some free time to write the post mortem for my compo entry, “Fun with magnets!”

When I learned about the themes this time I didn’t give much thought to the idea of creating a game that used both of them. For “growing”, I’d mostly considered farming or greedy corporations expanding out of control ideas, which were risky because of the potential to be out of scope for two days, and incorporating the two button-based mechanics would have been challenging.
Attraction/repulsion mechanics, on the other hand, had crossed my mind during the pre-ludum brainstorming I do before the theme announcement to prepare, and I felt that mixing the idea with the two button controls had some potential and was feasible. In hindsight, there are easy ways to incorporate “growing” there as well, but I preferred to go for a simpler approach instead.

I’ve seen lots of awesome entries this time (seriously, this LD34 has an insane proportion of cool games!) proving me wrong about mixing both, but I’m satisfied enough with my entry for once to not regret it.

If you decide to stop reading here, have a merry Christmas/Winter Solstice/Whatever rocks your boat! ;DD

Play it and rate it here

What went right

  • Tight idea. Sticking to a clear idea and vision this time helped me a lot towards having a more or less complete “vertical slice” of a game.
  • Reasonably adjusted level design: One of my key objectives this time was to close core feature coding soon enough so that I had time to define some semi-decent level design. This time I think I managed to do that to some degree.
  • Colour palette: I went for a set colour theme from the start and I believe the game graphics really benefited from it, as it gave the whole game a more consistent look (more on that later)
  • Haxeflixel: This is my third LD entry where I’ve used the Haxe+Flixel combo and it’s nice to notice how you become more familiar with it. Even if I experienced some hiccups at the beginning flipping the Unity switch, it’s easy and powerful to use. This time I’m particularly happy with some experimentation I did with Haxe abstracts, enums and anonymous types for level loading, which is something I’d attempted some time ago on my free time for another project with little success.
  • Web version was functional on Android! A more than welcome side effect of having used HaxeFlixel was that I saw the game working perfectly on Chrome on my Nexus and other devices. In fact, controlling the game through the visual controls “feels” better there (some thresholds aside) than using the mouse.

What went wrong

  • Haxeflixel. Even if I was familiar, it had been some time since the last time and I had to fight a bit at the beginning with the basic cinematic physics support it provides. Once I solved that, my overall experience with it went back to the “What went right” category.
  • Confusing control scheme. Initially I experimented with the idea of being able to switch the movement direction as well by cycling in a similar way to the magnets, but that resulted in a clusterf*ck to control, so I capped it so that the only way to change direction was to bump against a border. Still a bit tricky, but an improvement over the initial iteration. Also, controlling in multi-touch devices or with the keyboard only is more or less simple, but on a PC you can also add some mouse to the mix. Last, I think that there are some issues with swipe detection, specially on mobile devices, which make controlling through the visual wheel not fully responsive.
  • Glitchy attraction mechanics. Even if it’s functional, the magnet behaviour is far from perfect. I need to adjust the thresholds and angles to make it more responsive than it currently is.
  • Graphics. The set colour theme helps disguise this a lot, but as I was creating art assets when I needed them, each of them was drawn using a different style, so the final result leaves a bit to be desired.
  • Neglected audio. As always, audio is left for the final hours, which is probably a mistake, as it can help a lot in terms of feedback and immersion. In this case my main concern was that I left the music track half-done to keep adding the final touches.
  • Very simple levels. There are 9 levels in the game, which can be considered as a tutorial for something larger, because the goals are really easy. The only challenge at the moment that goes beyond the glitchy mechanics resides on the wheel in the last level, and even if you can consider it as a “To be continued…” sort of cliffhanger, it really makes no sense if you consider the compo entry as a full game.

Next steps

This time I’d like to keep working on a post-compo version (but I always say the same and then I don’t, so take this with a grain of salt), for which I’d need to apply all the things I’ve learned on this edition:

  • Fix all the things!
  • Improve controls and restrict control schemes. I’ve had some really good feedback about ways to make the controls better, and at first I’d thought about completely scraping the two button restriction and turning to a lever-like system for a post-compo version, but perhaps it’s interesting to keep it and evolve it instead.
  • Make all the levels! Either levels need to be more complex or I need to make (a lot) more of it. Also, I had several ideas for additional elements that didn’t make it into the game and could be interesting to make it more fun and difficult.
  • Improve graphics. I need to make all the assets a lot more cohesive in terms of drawing style and shading. Also, visual effects.
  • Improve sound.
  • Dedicated mobile port. Instead of taking advantage of the web version, deploy a native Android one.



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!”

Day 2 starts

Posted by
Sunday, December 13th, 2015 4:53 am

This is my progress as of yesterday, when I went to bed (yes, I’m awful playing):

Today will be devoted to content: removing placeholder art, even if I’ve grown attached to those pokeballs, and defining levels. Also, I’ll probably perform some more experiments and tweaks to the controls. I’ve realised that, while keyboard controls work fine (and I hope that the same applies to gamepad), mouse-only is unfeasible. However, multitouch is also a possibility, and the game is actually playable on Android, so depending on the time I might even build for that target platform. We’ll see how it goes.

Good luck to everyone! :)

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):

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.

Late for the Show – Timelapse Video Up

Posted by (twitter: @gamepopper)
Tuesday, August 25th, 2015 3:39 pm

Now that Late for the Show is out and the Voting Period is in full swing, I’ve just finished the timelapse video for it.

I wasn’t expecting to finish something like this in 24 hours, I’m usually comfortable with 48 hours because at least I have two nights to plan things through, and it didn’t help that Lime stopped working correctly around 16 hours in and I had to quickly reinstall it through haxelib in order to get it working again.

If you haven’t already, go check out my game and vote on it. I’m currently playing as many games as I can and I’m enjoying quite a lot of them!

[cache: storing page]