Posted by
May 19th, 2013 12:21 pm

Fractured Post Mortem


What Went Well

Overall, this game was much, much better than any of my previous endeavors.  People complimented my previous games (either sincerely or at least politely), but this time there have been people asking me to continue on with this game and make it a proper release.

Theme – I really liked this theme.  When I saw it during initial theme voting it was the one I had hoped would win the vote and had some good ideas and the vague idea for a game stewing in my head a few days before hand.

Controls – This is where I failed the most in my last two games.  I made games with too many things the player could do and I used awkward buttons for these controls that just frustrated people.  It also made my games way too difficult.  With minimalism as the theme it made sense to me to make the controls minimalistic and eliminate my weak point.  While the game has three buttons for controls, you only actually need left and right to complete the game.  Not once did anyone complain or get confused dby these controls, so I would consider that a definite win for me.  Going forward I’m going to have to keep myself on a tight leash to make sure I keep my controls simple in future games.

Scope – As stated with controls, I tended to let players do too much in previous games.  This was another problem that I have in putting too many different things in a game, especially one so short; as a result many things were half baked, and while worked, could be done much better.  This time I decided that I needed to reign myself back in and do something simple but polished.  As a result, I had a very small list of features I wanted to implement the game, and had a completely working engine and initial levels within 8 hours of development time.  Thus by Saturday morning, my entire time was spent making the look, sound, or play better and could stop at nearly any time with a playable game.  This let me get far deeper in story and subtle little things in the game that really caught people’s attention, and on building a complete game with a proper ending.

Walk Cycle

Graphics – This was probably where I made the best decision on.  Initial the game was not supposed to look the way it does.  It was supposed to look a lot different, and if I pursued that route, the game probably would not have been as good as it came out.  My initial intention was to rotoscope the player, drawing over video recordings of myself performing all the actions in the game and having the game play done as a silhouette, it would have worked, but it would have had no charm.

After four hours struggling with the rotoscoped animations, I decided to scrap the whole thing and just try drawing something.  After a very quick doodle, I had a cute little character to work with; he was boxy, simple, but charming.  I quickly put together a few animations of walking, sitting down, falling, crying, until I had a character that with no facial expressions could actually show show emotion.  From those few frames, I put together the entire plot of the game and graphic style.  All in all the main character and his color shifted friend have 68 frames of animation which is a lot more than the 15 and 40 frames of the main characters of the previous games I worked on, and those characters had a lot more actions.  The result was a character that was much more endearing to the player.

The lesson learned here is to not be afraid to throw out something and start over if you you know it’s not going to work.  Let it go and concentrate on what will work.

Music – Music is another area that I am typically bad at.  The music in my previous game was terrible, absolutely terrible.  It was a 12 second loop that probably drove a few people batty.  In retrospect I should have just left it out.  This time I devoted more time to the music.  I knew I needed a longer music piece, and decided to spend all my allotted time on one good song.

To be honest, I’m not sure how the music got to a point where it actually sounded good.  I sat at a piano and banged at the keys until something sounded right.  Got a chord progression then started to fill in a melody, by what I can only describe as a breadth first search of notes.  In the end though, the music matched the game really well and people liked it enough that one of the other competitors, SonnyBone, went so far as to remix the music, which you can hear here.

Fractured Tutorial

Tutorials – The first six levels of the game teach all the mechanics of the game using only one word (“Space”) to tell the user how to reset a level.  I used simple levels, visual clues, and even other character’s actions to lead the player into learning how everything works in the game without having to tell them.  I learned a lot from Egoraptor’s breakdown of Megaman which I highly suggest you watch, though I will note he is a bit vulgar. My first game had a “here’s how to play” screen at the beginning; my second had tutorial text in game. This game did it much better, though I did mess up in one small way. One of the tutorial stages teaches how to reset a level by having a button that if pressed makes the level impossible to solve without a reset. I assumed players would walk to the wall that closed up, and had logic that would show instructions when you reached it; however, what I found is that as soon as the player hit the button, they would try to reopen the door by pressing the button again rather than walk forward. They would eventually get it, but it disrupted the flow of the game until they started just walking around the level looking for a solution.

Playtesting – If nothing else, I suggest you do this while developing your game, and if you want to continue working on the game get people to play the game afterwards and watch them play. During the 48 hours, my brother volunteered to test the game. I sent him several in progress releases often and early in the contest so that I could get feedback on what worked, and what didn’t. Afterwards, I signed up with nearly every person who was streaming their reviews so that I could see how people played the game. Actually watching people play, get frustrated, and have the aha moments taught me so much about game and level design and really helped my overall growth. I hope next competition to be in a position to do the same service to other developers but I was getting ready to move as part of a new job and didn’t have a consistent time to sit down and set up streaming and settle down for long play sessions.

What Went Bad

Before I get into the bad list, I want to note that the items that are bad in this game are far more specific and less significant than my previous games.  My last LD game wasn’t bad, but had some significant issues, so much so that my previous game’s post mortem was actually a comic making fun of the game.  While people did note issues in this competition’s game, they also noted that they played the game to the end, which is a fantastic thing to here.

Level visibility – One complaint is that the player could not see the entire level in one shot which caused them to miss things and have difficulty determining what was going on when hitting certain buttons.  In a puzzle game, the player really needs to see the whole puzzle at one time to make it possible to solve the puzzle without just guessing.  While I don’t think that being able to see the whole level at once is always necessary, the ability to scroll around or zoom out would have helped players quite a bit.

Fractured Buttons

Even the in game character had to squint to see some of the buttons.

Difficult to See Buttons – Compared to other issues this was minor, or at least fewer people complained bout this issue; however while watching people play the game I did notice that people got hung up in one or two places where a button was in shadow and players skipped over it and get frustrated.  The lesson learned here is that I need to make sure the environment does not obscure the actual gameplay elements of a level.

Difficulty Curve – The game starts off with a few simple levels to demonstrate the game’s mechanics, then throws the player into some rather difficult levels.  Two days is a very short amount of time determine a good difficulty curve, but it would have helped to create a few simpler levels that showed a simple puzzle with fewer pieces then build up the harder levels as a composite of these simpler puzzles.

Feedback – This is by far the biggest issue.  I alluded to the issue above with the visibility issue, but the real issue here is that in far too many places the player did not get immediate feedback to let them know the consequences of their actions.  The player would press a button and nothing visible on the screen would change.  The player was then forced to look around the level and find out the one thing that was different that they could interact with.  I think the best way to address this is that when the affected element of an action is off screen, the camera would pan or zoom to it to let the player know what is going on.  That simple of a change probably would have removed most of the frustration of the game do to the game engine (but left the good frustration you have in a devious puzzle).


I am extremely happy with the final results of this game.  There are definitely some rough edges and places to improve upon, and I fully intend on continuing the the development of this game right now (I’m debating platforms right now, so if you have any preferences, I’d like to know).  If you haven’t had a chance to play my game, I ask you to take a look, even after the competition is done and leave a comment with constructive criticism so that I can learn even more.

Play fractured here.

Fractured Title

One Response to “”

  1. SonnyBone says:

    Since you developed with XNA, have you thought about releasing this for Xbox Live Indie Games? I think this game would do really well on that platform with enough visibility, and you could also try for Steam via Greenlight.

    A level editor would be really awesome.

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]