About MiniBobbo


Ludum Dare 37
Ludum Dare 36
Ludum Dare 35
Ludum Dare 33
Ludum Dare 32
Ludum Dare 32 Warmup
Ludum Dare 31
MiniLD 42

MiniBobbo's Trophies

MiniBobbo's Archive

Black Box practice game finished

Posted by
Sunday, April 5th, 2015 2:22 pm

I just finished a small puzzle game for One Game a Week with the goal of preparing for Ludum Dare.  You can try it out here.  Instructions in game.  Comments and thoughts welcome!


Walk the Plank postmortem

Posted by
Monday, December 8th, 2014 9:09 pm

My game has an actual menu!

So I completed my first ever full Ludum Dare.  I’ve finished a couple miniLDs but never a completed game in just 48 hours.  Now that I’ve had a day to stop and reflect on how everything went I wanted to get my thoughts down in the time honored “what went well and what didn’t” format.

Walk the Plank is a pirate captain plank walking simulator.  The (very loose) plot is a pirate crew that plundered all day and has to make all their hostages walk the plank.  Unfortunately they waited until late in the day to line them up so in their haste some of the crew got mixed into the line.  As captain, you have to kick the hostages overboard and throw the crew back onto the ship.  Each  round lasts 10 seconds.  Fail to reach the target number or make three mistakes and the level is lost.  You can play Walk the Plank here.

What went well

Scope – The scope of the game was perfect for me.  Normally I love complicated games and writing engines, but this time I wanted to make something that was complete and polished.  The game is dead simple with only two buttons.  This simplicity freed up a ton of time to focus on other areas.  Even with the simple engine I still only finished 18 minutes before the deadline, so anything more complicated wouldn’t have been done for the compo.

Code – Don’t get me wrong.  My code is a horrible mess.  However, the bones are solid which made adding levels and content simple later on.  Levels 4-7 were added in the last 20 minutes, which is over half the content of the game.  I made a feature list early on and stuck to it.  I’m happy that there was absolutely no scope creep at all.  This is unheard of for me and played a major part in the on-time finish.

Art – The art went better than I expected.  I tried something new this time and used InkSpace to draw everything.  I loved being able to scale the game assets to every size without losing any of the quality.  Plus, I created a master template for the crew and hostages and then just build arms, feet, bodies, heads, and hats that can all be combined to create a large variety of different characters.  SVG files are super easy to modify and change to make different characters quickly, so I think overall that efficiency made up for the extra time it took to learn the tools.  The ship needed a lot more work than I was able to give it though.  Overall, the art is very functional, and I’m happy with that.

Polish – I am really happy with the amount of polish I was able to cram into the game in the second day.  Tweening is quick and easy and I think adds a lot to the overall effect.  I have states that convey information clearly (I hope).  Little things like restricting input for a second when displaying the results page so players don’t accidentally click through it add a lot and I was able to cram it in.

What went poorly

Music – I knew music was going to be painful going into this.  I actually had very few requirements going in.  I only needed a menu piece and a game piece.  Each round only lasts 10 seconds, so there didn’t even have to be a large music loop to fill the space.  I knew exactly what I wanted for the main menu and was able to create it in about 5 minutes.  The game piece I struggled with for an hour with nothing to show for it before giving up realizing I needed to spend the time elsewhere.  Instead, I just sped up the main menu music for the game.  It is an extremely short loop (only a couple seconds long) and got on my nerves quickly.  I thought about cutting it out altogether but settled on just adding a mute button.  You’re all welcome.  :)

Level design – An hour before the deadline I was looking over my rapidly shrinking must-have feature list pretty pleased with myself.  Then I realized that the last remaining item was actually just content.  Crap!  It is great that my buttons are appearing in an aesthetically pleasing manner, but the game was only 3 levels.  That is about 2 minutes of gameplay.  I quickly created new pirates and hostages (easy thanks to the art choices) and threw them into the game (easy thanks to the code skeleton).  I didn’t get to test them out very well though.  As a result, the levels go from easy to medium to easy, to medium, to freaking impossible.  Actually, the near impossible last level hid the last “what went poorly” item…

No game end – If you somehow beat the last level it loops you back to the beginning.  Not that you are ever going to beat the last level, but still.  If by some miracle someone does beat the last level I would imagine that they would be pretty disappointed that the game doesn’t even acknowledge the miracle that they performed.  Luckily nobody will ever know this, except for the fact that I just posted it for everyone to see…


This was great fun and I’m loving playing and rating other’s games.  I’m taking notes about what others have done that I really like for next time.


Walk the plank actual progress! And you can play it!

Posted by
Saturday, December 6th, 2014 11:39 pm

Walk the plank is coming along great, surprisingly.  The basic gameplay is done, there are transition states, level start and end screens and three levels.

walktheplankOne of the reasons for my remarkable progress (for me, anyway) is because the concept is simple.  You have to make the hostages walk the plank.  Unfortunately, some of your pirates got mixed up in line so you have to sort them out.  Press Right or D to throw the hostages in the drink.  Or press Left or A to throw the scruvy dog back to swab the decks.

I’m trying something new with the graphics.  I went with SVG files this time using InkScape and I’m still learning, but I enjoy it.

If you’d like to try it out you can play it right in the browser here.  I’d love some feedback on the overall feel.  There is still a ton of polish to do, as well as animations for the captain, music, sound effects, a bunch more levels, a main menu, and I suppose I should sleep sometime.



Walk the plank

Posted by
Saturday, December 6th, 2014 9:44 am


The pirates have spent all day plundering and looting, but they overlooked a vital part of the process.  Making their captives walk the plank!

There isn’t much time left in the day, so in the haste to get everything ready members of the crew were accidentally inserted into the plank-walking line.  As captain, it is your job to quickly and efficiently sort the crew and kick the landlubbers overboard.  Don’t make any mistakes!

Progress is coming along.  It took a long time for me to come up with an idea that I liked.  I’m struggling with the Entire Game on One Screen approach but I’m hoping that I can get away without any scrolling.  This game will be extremely simple from a gameplay point of view, so I’m hoping to focus on polish.  The screenshot has a lot of temporary graphics, but it is coming along nicely.

I took a lot of inspiration from the site 2D Game Art for Programmers.  You should definitely check it out if you haven’t already!

Fear the Squinja!!!

Posted by
Saturday, August 23rd, 2014 3:59 pm

squinja standing

Still proceeding randomly

Posted by
Saturday, August 23rd, 2014 2:30 pm

So I am all over the place with my project.  I’m making progress on all fronts but I’m thinking that next time I’ll have to be more organized and actually finish individual pieces before moving on to the next ones.  Part of the problem is that HaxeFlixel and Spriter are both new to me (Spriter actually brand new).


So my game is going to have a ninja squid infiltrating boats attempting to destroy the main computer to shut them down (that’s how boats work, right?).  The test level is made, some of the game logic is in place, and I recently got distracted with the opponents for our daring squid.  Here are the evil dock workers (who are, for some reason, working on boats now…  Like I said, I didn’t plan this out well) hungry for calamari and just waiting for the Squinja (squid-ninja obviously) to make his appearance.



I should probably get working on the actual character sometime…

Stupid HaxeFlixel question

Posted by
Saturday, August 23rd, 2014 7:33 am

So I’m stumped.  I’m trying to implement one way platforms in HaxeFlixel using FlxTileMap and running into problems. They work fine when I set the collision flag with map.setTileProperties(2, FlxObject.CEILING) but how do I get it so entities can drop through them (by pressing down and jump or something)?

If I simply drop the sprite down a pixel or two they drop through fine, but then they also drop through solid floors.  It’s driving me a little crazy and I know therte must be a simple solution, but whenever I Google it I get a ton of results about deploying Haxe cross-platform which is not what I’m looking for.

Any help would be… helpful.

Since the beginning of time…

Posted by
Friday, August 22nd, 2014 6:56 pm

Since the beginning of time two worlds have coexisted side by side.  The environment from each world is inherently deadly to creatures of the other world which was enough to keep the peace for a time, with small skirmishes taking place at the gaps between the worlds.  However, creatures from one world were warlike and crafty, building ships capable of breaching the gaps, enslaving and devouring creatures from the other.  For a long time the creatures from the second world were nearly powerless against the invaders, with millions taken into captivity and devoured.  The large ships are nearly unstoppable and the besieged creatures powerless against their invaders.

Things, however, are changing…  It is time for the enslaved to strike back!


HaxeFlixel InputHelper

Posted by
Wednesday, August 20th, 2014 3:51 pm

Have you ever received a comment like “I would like to play this, but I use an AZERTY keyboard layout and the controls are impossible” or “I wish that key X did this instead of Y”?  Ever spent time hard coding user inputs into a game only for it to be a pain to change it around?  Ever wasted precious time writing a way for users to change their own keys in game?  Oh, and happen to use HaxeFlixel?

If you answered yes to any of these questions, then you need InputHelper, the new simple way to map keyboard keys to game functions without the hassle, available now for HaxeFlixel for the low, low price of… nothing!

InputHelper is a small helper application for HaxeFlixel games.  It abstracts the interface between the user and the game through a series of virtual buttons that can be mapped to different functions.  Instead of checking against the keyboard, mouse, or gamepad and updating your game objects, InputHelper has you check against buttons named up, down, left, or right plus any additional buttons you define.


Wizards Trials are tougher with only one spell…

Posted by
Saturday, December 14th, 2013 7:09 am

So when the theme was announced I was excited to get started.  I try not to think about the potential themes too much before the compo starts, so when I sat down to brainstorm for the first time I had a potential list of… nothing.

So I decided to take the advice of many of the Ludum Dare veterans and sleep on it.  When I woke up this morning… still nothing.

So I’m lying in bed thinking about what I can do when I have a random thought.  It is of a wizard who is double jumping by firing a spell downwards, which propells him up.  So running with that (I was getting a little desperate) here’s the pitch…

Here's Wizzy!

Here’s Wizzy!

This is Wizzy, who is a little nervous because today is the day of his Wizard Trials and he only knows one spell.  While his peers are shooting fireballs, teleporting, summoning beings from beyond, and all that stuff, all Wizzy can do is fire a little emergy ball.  It can’t even kill anything!  How will Wizzy complete the trials with only a single, useless spell?

Maybe I’ll finish!

Posted by
Monday, December 9th, 2013 9:20 pm

I’ve participated in a couple of mini-LDs to see how a 48 hour deadline will work for me.  The answer so far is… poorly.  Here’s hoping for my first successful finish!

Language: Java

Framework: libGDX with my library SPE

Graphics: Paint.NET, Tiled, Tile Studio

Sound & Music: Musagi

Timelapse: Chronolapse

Power Grab post compo

Posted by
Friday, August 9th, 2013 1:36 pm

So I’ve been working on my Mini Ludum Dare 44 7dRTS entry Power Grab and finally have it to a level that I wanted to be for the actual competition.  I got some great feedback and incorporated most of it and feel that the gameplay itself is now pretty polished.  Here’s some of the changes:

  • The nasty random crashing bug is fixed.  It was actually a floating point arithmatic error and took forever to track down…
  • Accuracy of your attacking units is increased.  So much so that you now can actually hit individual things!
  • Win and loss conditions implemented (destroy all opponent’s power stations and lose all yours respectively)
  • Multiple playable levels
  • AI got some work and no longer randomly gets stuck.  Also, added different difficulties
  • Quick (really quick and ugly) menu system for setting up a game.
  • Animations polished
  • Camrea scrolls instead of jumping, making it much easier to understand what is happening.
  • A “fire every unit here” button

Still left to do is implement keyboard shortcuts and make the buttons appear near the selected units, but after that my basic feature list is complete.

So now that I’m nearly through my feedback list and I have a fairly polished game I’m actually wondering…

Is it any fun?

I mean, I enjoy it, but I made it so a portion (maybe a large portion) of my enjoyment comes from that.  I have ideas for additional units and gameplay options, but I’m not sure it is worth it.  Anyway, if you play it and enjoy it and can think of any additional features or cool unit ideas let me know. 

If you want to give it a shot, the post compo version (Java JAR file) is here: https://dl.dropboxusercontent.com/u/103108185/PowerGrab/PowerGrabPostCompo.jar

Compo version here for comparison: https://dl.dropboxusercontent.com/u/103108185/PowerGrab/PowerGrab.jar


Power Grab Postmortum

Posted by
Wednesday, July 31st, 2013 6:28 pm

So I’m extremely happy with the finish to MiniLD44.  My entry Power Grab is about 90% to where I wanted it when I started the whole process.  Unfortunately, the 10% that is missing is pretty key to the whole experience so I’m treating the current state as a technical test of the mechanics.  There is also a nasty, really obscure bug in the code that will crash the game when some unlikely combination of events happen.  It is something like a bullet tries to hit a unit when the parent of the unit that fired the bullet was destroyed.  I’ve only had it occur once and thought I’d fixed the code, but others are reporting the same problem so I need to do a little more digging…

You can play it here: http://www.ludumdare.com/compo/minild-44/?action=preview&uid=22584


I finished with a playable game.

I had an extremely limited feature list because I knew everything was going to be complex and I was able to implement everything in the time allowed, with the exception of the status display for the selected units…

LibGDX worked great

I used an MCV architecture to split the model, control, and view pieces of the code.  I can now make changes to the visuals and UI without rewriting any back end code.

I stepped the graphics back to a pixel look and I think the final product is better for it.


I had no framework for structuring my code.  I would forget what a method did what and accidentally call helper methods in the place of main ones, which would cause all sorts of problems.

The aforementioned bug.  I can’t duplicate the set of circumstances that cause it so I can’t troubleshoot it

There are no win or loss conditions since destroying the power stations is impossible.

I didn’t have time to make my own music, so I grabbed some from opengameart.org


The AI.  I’d never written an AI for an RTS before.  This one is actually almost completely random but actually puts up a fight, which surprised me.  It is easily exploitable, but for about 20 minutes work I’m happy with it.

The instructions are ok for explaining what to do, but not how the units interact with one another.

The UI is getting there.  It needs some work to really give the player a clear picture of what is going on.

Power Grab: Day… 4?

Posted by
Thursday, July 25th, 2013 6:18 pm

So I made some good progress today.  I redid all the art I’d made so far to make it all… worse, actually.


I went with some extremely simple pixrel art because while the other mediocre art looked better it would take me much longer to animate.  If I have to choose between smooth animation and nice graphics I’ll choose the animation every time.  The pixel graphics scale better anyways and look nicer with the “dynamic” camera.

Once I decided to go with the pixel art it was obvious I should write a simple particle system.  So now there are explosions when you decide to shoot something.

Speaking of shooting something, I also implemented the bullet code, so now all the fire that you throw at your opponent actually does something to him.  I lost a lot of time trying to find a bug in the code that caused some bullets to do absolutely nothing when they reached their destination.  Every time I debugged it worked fine, but in play it didn’t.  After beating my head against the wall for a little while I found that I had some left over code when I was playing around with bullets early on that moved them but never checked for hits.  So every bullet that happened to reach the target in the properly implemented code worked great and all the other ones failed.  So that explains the 50% success rate.

And finally, I wrote a quick builder AI who builds and repairs units all over the map to give you something to shoot at.


Up next…

Defensive structures!

Right sized power stations!

A computer opponent that will actually shoot back!

Demo here: JAR file

Instructions here: TXT

Power Grab: Day 2

Posted by
Tuesday, July 23rd, 2013 3:02 pm

So I made some more progress today.  I tend to be all over the place instead of just working on one thing until it is done…

I put together some art assets.  These are probably going to be close to the final products…


They are an empty platform, an attacking unit, a defending unit, a node, another empty platform, some floating land, and a power station, with some buttons thrown in for good measure.

Coding is going along well.  The skeleton of the game is in place.  You can select a power station and build nodes.  Those nodes draw power from the station that started them to build themselves.  You can also have the node build attacking units in the available spaces around it.  Once the node is completed it starts to transfer power to the units attached to it.  Once they are built, they draw power from the node to attack or defend.


You can also switch between attack and defend mode by pressing space.  When you are in attack mode you can select the nodes and give them a target.  The units attached to that node will then attack that spot (and the spots around it, because they aren’t perfectly accurate) until you change the order.

Next up are the defenders, transforming nodes into power stations, and the AI for the computer opponents.


EDIT – WordPress stripped out the pictures.  Weird…

EDIT2 – “Playable” Demo


Note, the islands are generated randomly, so you have a 50% chance that the spot your power station is trying to appear on isn’t there.  Just restart and hope for better luck next time.

7dRTS: Power Grab

Posted by
Monday, July 22nd, 2013 5:10 pm

Hi everyone.  I thought I’d throw my hat into the ring for the 7dRTS challenge.  I enjoy RTS games although I’m typically not good at them, but that might just come from playing against my younger brother back in high school who was very good.

The inspiration


One of my favorite games for the SNES is Metal Marines, which is an interesting take on the RTS genre.  If you’ve never played it you build up a base on an island and fire missiles and large robots (the Metal Marines from which the game gets its name) at your opponents islands trying to destroy their base.  The game alternates between building and attacking modes.  The building mode is real time where both players simultaneously place units and upgrade existing ones.  The attack mode is initiated by one player who then fires up to 4 missiles and 3 metal marines at his opponent whose automated defenses try to resist.

There are a couple of things about the game that I don’t like.  Each level can take a long time to complete.  Although it is very satisfying to watch a missile fly across the ocean to strike your opponent after a short while it becomes really monotonous (and you will fire a lot of missiles).

Design Goals

  • RTS should focus on macro management instead of micromanagement
  • All attacking and defending will be done in real time
  • Individual units will be built and managed automatically leaving the player to focus on choosing where to attack and defend.
  • Games will be play and be resolved quickly

I’m not sure that I’m going to achieve all this, but anyway, I give you…


In the future, solar power rules.  Corporations battle over floating islands that cover the Earth for solar powered supremacy!  The backstory makes no sense, but who cares!

Players will start with an island with a single power station.  This station produces a fixed amount of energy every turn.  Each station can build and pass energy to many different nodes.  In turn, these nodes build and power units that either attack or defend.  Maximizing your energy usage will be key and attacking is always more efficient than defending, so defenses must be used sparingly.  Find and destroy your opponents power stations to win!

[cache: storing page]