{"author_name":"tSwitch","cat":"LD #26","comments":[],"epoch":1367253600,"likes":3,"metadata":{"p_key":"43218","p_author":"tSwitch","p_authorkey":"505877","p_urlkey":"78854","p_title":"MBlok Postmortem","p_cat":"LD #26","p_event":"LD26","p_time":"1367253600","p_likes":"3","p_comments":"0","p_status":"UPD5","us_key":"505877","us_name":"tSwitch","us_username":"tSwitch","event_start":"1366934400","event_key":"16","event_name":"LD26"},"text":"

\"banner\"<\/a><\/p>\n

 <\/p>\n

Click here to PLAY and RATE MBlok<\/a><\/p>\n

At the beginning of the project I set myself a goal, like I did in the three Ludum Dares I have participated in prior. \u00a0In my first, my goal was to finish. \u00a0I was disappointed with what I made, as I focused so hard on finishing my game, that I stripped away polish and ended up with something that wasn’t very fun. \u00a0In my second, my goal was to make something simple. \u00a0I ended up with Stargazer<\/a> and was very happy with the result. \u00a0In my third, my goal was to do something I hadn’t done before. \u00a0I chose perlin noise generation<\/a>, and randomly generated my terrain for A Villain is YOU!<\/a> \u00a0Again, I was rather happy with the result.<\/p>\n

This time, my goal was to make my game polished and fun above all else.<\/p>\n

I chose HaxePunk<\/a> for my platform of choice, as I wanted to be able to easily compile for multiple platforms. \u00a0I would have gone with Stencyl<\/a>, as I had for two of my previous entries, however the longer I use Stencyl, the more I feel limited by it. \u00a0It is a wonderful platform, but it lacks meaningful class structure, and the interface makes it slow for me to develop in.<\/p>\n

That said, I love the concept of haXe, and the syntax is familiar, and so I chose HaxePunk over Haxe Flixel<\/a>. \u00a0Why? \u00a0It’s quite simple really. \u00a0Haxe Flixel’s API listing page is broken<\/a>, and HaxePunk’s isn’t<\/a>.<\/p>\n

That said, I had a few moments of frustration with HaxePunk early on, but overall I quite like the library and would work with it more in the future.<\/p>\n

So, let’s tackle this whole scenario in chronological order.<\/p>\n

First, the theme. \u00a0Minimalism. \u00a0I wasn’t too hyped about it, but it wasn’t Alternate Physics, so I was happy ( though in retrospect I could have made the exact same game and it would have fit for Alternate Physics as well ). \u00a0 \u00a0I brainstormed for about an hour and settled on two ideas. \u00a0First, a one button game where you played a planet at the center of a radar system, and you hit the button at the right timings to fire on enemies that are revealed by the rotating radar blip. \u00a0Second, a game where you click to remove blocks, and gravity changes to rearrange the mess of blocks into new and interesting patterns.<\/p>\n

I chose the second, as it seemed like much more fun to make.<\/p>\n

Originally, the goal of the game was to reduce the blocks from multiple colors, to a single color. \u00a0I also wanted to make blocks fall down off the screen when they were no longer supported. \u00a0This never made it past the planning phase, however, as I couldn’t come up with a good ( read: clear ) set of rules for when a block would fall. \u00a0So development continued, assuming that the block had a bottom, and everything fell according to the gravity.<\/p>\n

I then encountered my first frustration with HaxePunk: there is no true camera.<\/p>\n

I originally wanted to rotate the block when gravity switched. \u00a0The stage would have been magically dynamic and interesting to look at. \u00a0Rather than rotating every single block and their positions around the center of the screen, I had planned on simply rotating the camera 90 degrees. \u00a0Unfortunately, the camera I found in the API was just a reference point for where it should be, and I could find no way to apply a rotation to it. \u00a0There were mentions of rotations elsewhere in the API, however there were no resources or examples showing their usage, and my tinkering with angle properties amounted to nothing.<\/p>\n

If there was a proper camera, I could not find it.<\/p>\n

Instead, I worked around this restriction, and came up with the square stars in the background. \u00a0They fall like a normal field of stars, with their speed proportional to their size so as to add depth, and they fall according to whichever direction gravity is currently set to. \u00a0I’m rather happy with this workaround, as it retained a measure of the dynamic feeling I wanted for the gravity, and was also incredibly simple, much like rotating a camera should be.<\/p>\n

Around the 4:30pm-5:00pm on Saturday, my game was shaping up and graphically pretty, and I was working on adding actual levels. \u00a0However at this point in time, I had changed the goal from one color only ( which was far too easy ) to one BLOCK only. \u00a0Gravity was moving automatically at set intervals. \u00a0I wasn’t happy though, as the game didn’t feel fun. \u00a0It was a mechanic with nothing to drive it. \u00a0There was no challenge, very little thought, and the level design was unclear.<\/p>\n

So I whiteboarded for a couple minutes. \u00a0My train of thought went something like this: \u00a0Minimalism as a mechanic. \u00a0Reducing the complex to the simple. \u00a0Combos are good, gravity is good, the block is dynamic, the mechanic is simple. \u00a0What makes it challenging, what makes it a puzzle? \u00a0What if I let the player control the gravity? \u00a0Could work, adding control can add strategy. \u00a0One block is pointless, one color is pointless, the former is too easy, the latter has no pitfalls or strategic feeling… \u00a0What about no blocks? \u00a0Easy to do…oh. \u00a0OH. \u00a0As few moves as possible! \u00a0Maybe as little time too! \u00a0Minimalism isn’t the mechanic, it’s the strategy!<\/em><\/p>\n

I had it. \u00a0I knew it would be fun, and all I had to do was make good levels.<\/p>\n

I added level select, a good level config system, five levels that I sorta threw together and calculated pars for based on running through them a couple times myself. \u00a0I have terrible problem with making games too hard, so I raised the pars a little, and almost doubled the time limits. \u00a0I probably shouldn’t have, as it resulted in the game lacking in challenge.<\/p>\n

I’m also terrible at making puzzle levels quickly, and having them be fun.<\/p>\n

Around midnight, I had five levels, a level select screen, and a results screen, and it all flowed well. \u00a0So I decided I deserved to sleep more than four hours, and took a good long break.<\/p>\n

Woke up Sunday at noon, and started on the title screen and music. \u00a0I’m terrible at music, but it seems to have come out decent at least.<\/p>\n

Then I ran into my second issue. \u00a0In cpp targets, I can only have one mp3 play at a time. \u00a0I had originally planned on only using mp3’s for sound, so I wouldn’t have to conditionally compile my sound code. \u00a0I had to use OGG files for cpp targets, which to be fair are far better, but it was a tad bit annoying. \u00a0Sound also doesn’t loop, and seems to cut out on Windows. \u00a0I’ll deal with it later though.<\/p>\n

Then I had a fun little nightmare trying to build for windows, when my haxe install broke apart. \u00a0But in the end it worked more or less.<\/p>\n

So, I finished and submitted my game, and I’m rather happy with the result. \u00a0For the third time, I feel like I’ve accomplished my goal. \u00a0My game is fun, if easy, and polished.<\/p>\n

Lastly, I looked into itch.io<\/a>, which is essentially bandcamp<\/a> but for indie games. \u00a0I think it’s pretty awesome and I’m going to keep using it in the future to distribute games. \u00a0I’ll be posting updates to it, and possibly updating this blog when my post-compo version is done.<\/p>\n

Oh, and I also did a timelapse for the first time.<\/p>\n