Hushbert’s Theme
I updated Hushbert’s theme a little. It’s a relatively minor part of my game, but I dig it, and I thought I’d share this with folks. Have a listen!
If you haven’t played Hush yet, click below to give it a try!
I updated Hushbert’s theme a little. It’s a relatively minor part of my game, but I dig it, and I thought I’d share this with folks. Have a listen!
If you haven’t played Hush yet, click below to give it a try!
Now that a week has passed I think it’s time for summary. Let’s start with the right and wrong stuff.
What went right?
What went wrong?
What else?
The (positive!) ratings I received also revealed a bug in my checkpoint system. And the collisions were too unforgiving I’ll have to admit. So I fixed both and uploaded a post compo version of my entry. Just in case you want to play a (hopefully) less buggy version: go here!
Ah, it’s taken me a while to do a post mortem. This was my first solo jam, I’ve always worked with a partner for Ludum Dare so when my go-to collaborator wasn’t available (busy with another game project) I decided I’d try a go solo. We normally work under the name Hoqjed
Into the Storm… Alone – Doing this thing by yourself is a slightly different beast. There was a point mid-jam… when I had an alright amount of progress programming-wise, and I still needed to add in art and audio. I sat and thought to myself “what I finish now is all that the game will be, there’s no one to help with assets, or help with the logic, or help scrounge for audio”. I’m accustomed working solo in my personal non-jam work… but the time constraints really emphasize it in a way I’ve never really experienced before. Ultimately, I’m really proud of what I was able to do, and I’m thankful for my friends still taking time out of their busy schedules to help test the game along the way.
The Concept – I settled on the idea of riot control because I liked how it’s a bit of a grey area determining how to handle that kind of situation. I also liked the idea of trying to capture that tense atmosphere. After a little bit of research, I learned more about Active Denial System and read somewhere that these sort of things are developed to be more “social media friendly”. Whether that’s true or not I don’t know, but I found it fascinating and decided my in-game weapon would be a sort of an exaggerated version. The exaggeration came in the form of Big Brother-y emotional control over the crowd.
What went right – Well, the concept for one was surprisingly solid. I’m really happy I was able to come up with an idea that resonated with me and also could lead to interesting and free-form game mechanics. The art style came together somewhat well considering the little amount of time I spent on that portion, and I was able to find some really nice audio and edit it to create a really nice atmosphere overall. The crowd logic also turned out well. There were a lot of little nuances to their reactions… like how they can run away, take a breather off-screen and then come back even more enraged. I also liked that I kept the game open to be explored, rather than demanding players approach the situation a specific way. I leave it completely up to players to decide what to do and act less like a guiding hand and more as an onlooker. The “win”/lose messages presented to you after the scenario has ended are very cold, and don’t necessarily take a stance on the players actions. I’d like to think that this allows the person playing to reflect on their own actions more, and have a more personal experience with the game.
What went wrong – The crowd reactions and giving people feedback on what was happening. This is the downfall of the original submission, and for everything that went right this takes away a lot of the positive aspects. I really learned how important it is to not only create interesting game systems… but to give feedback for how said system reacts to input. I still continue to get comments about how difficult it can be to determine the effects of the emotional changes on the crowd. I was aware of this issue the night before submission, but I just wasn’t able to fix it in time. The feedback for how you’re expected to use the weapon could have also been improved.
Post Jam and the Shadow of Failure – I’ve created a post jam version that addresses a LOT of the issues with the crowd reactions people were experiencing. They now animate based on their strongest felt emotion (or don’t if none of the emotions are high/low enough). There are still issues with the actual balance of the game, but overall it’s a much improved experience. But for all the changes I make to the post jam version, I still continue to get comments about same problems with the original submission. I know that most people are just going to play the original, get burnt out because of its issues, and move on. But it’s rather annoying having an improved version and still getting complaints about the original’s issues. It feels like to some degree I just can’t get away from my initial failures with the game.
I’ll continue to work and improve the post jam version and maybe make another post about it when it’s more where I want it to be. Future plans include improvements all around to the art and color scheme, tank animations for damage level, more balanced crowd reactions, maybe a day/night cycle since I’ve actually already got the art in for that (it was just never implemented).
Check out the game here:
http://ludumdare.com/compo/ludum-dare-32/?action=preview&uid=26681
At least after near a week I finally wrote the post-mortem for our game.
This was our fourth LD started and the third we managed to finish. Also this time we met several participants to work together (Thank you animanegra for hosting it !!!). On our part I wrote the code, Iñigo made the graphics and David wrote the music and sound effects, we decided to go for the Jam from the start.
Timeline
The timeline was more or less this
We started on Saturday morning (in this timezone the theme is known at 3am) and decided rather fast to make a one-to-one combat game with some unconventional weapons. The classical example of non conventional weapon or at least the first that came to mind was a frying pan. So I started to program a simple one screen and two characters engine and Iñigo started to make graphics for it. He decided on the setting of oriental monks with alien. By Saturday evening we have basic animation and movement, but just one attack the hit with pan.
On Sunday we concentrate on the combat mechanics: made the effects of attacks, throwing objects, death, start and end of combat (with the referee…) and the code beging to suffer of not very well planning… (feel to hav fixed more bugs than in previous jams). On Sunday evening it looked far from being completed. So I fast wrote an AI (if you can call that [ do_random_movement ; repeat ] an AI). After a bit of rest we decided some story between scenes were needed and some increasing difficulty and progress. I wrote the 5 scenes text and decided to unlock attack types as enemies are defeated. Also added first music and sound effects that David sent.
On Monday I had to work in the morning (in my real work I mean :-)) I made the text scenes and scene progress logic in the morning before work but after that no much progress till the evening. I finally was able to got back to LD around 18:30 and the Jam closed at 3:00. I worked the rest of the evening, adding the graphics for scene backgrounds, putting a bit more I into the AI, and adjusting the combat to be defeatable and challenging… but I was afraid of making it too difficult and the time was running out… so went more towards the easy to win and submitted.
What went right
this has increased the visibility of the game
What went wrong
Anyway we are really happy having finished again a game for LD, as usually a lot has been learned and we will participate again 
Genre, Objective, and theme
For “Cereal Killer”, we chose a cereal themed tower defense game, where you aim to drown the bowls of cereal with milk before they can reach the target square at the opposite corner of the board. We were inspired by the picture of the spoon sent along with the tweet of this year’s objective, and decided a concept with cereal and milk could work quite well.
Initial Goals
At the start of Ludum Dare, we set out to implement a 2D tower defense game on a rectangular board of cells. One cell would designate the start, and one the end. Bowls of cereal would move through the course (hopefully with some sort of intelligence), and the player can place towers on cells to partially block the pack to the end, causing the bowls to change course. Turrets will be able to fire upon the bowls, killing them if they push their counter over a scaling health number.
Idealy, most of these actions would be animated, using as few freeze frame actions as possible, but this was lower priority than most of the items listed above. We would also like turrets to be upgradeable or include multiple types of turrets if possible.
Goals Met
In the end, we had a mostly functional tower defense game based on the premise of milk and cereal! Bowls of cereal spawned in waves on a timer, journeying from one side of the board to the other using A*. We were able to prevent the player from completely blocking the board using this as well, preventing the game from becoming trivially easy. We were unable to make some of our goals in the second paragraph of the initial goals section, such as animating the bowls of cereal from cell to cell, or creating meaningful upgrades to the turrets, but we were able to create a reasonable construction animation for the turrets, as well as introduce a placeholder particle effect for milk.
Asset tools
To create the assets for our game, we used primarily Photoshop CS6. To create our audio clips for the game, we used BFXR.
What took more time than expected
An item that comes to mind which contributed to some loose ends in the project was the pathing for the bowls of cereal. Because we wanted the choices of direction to revolve around north, south, east, and west cell traversals, we could not use Unity’s navigation mesh libraries, so we implemented A* on our grid of cells to determine each bowl’s next move.
Last minute breaks
Most of our game held together all the way through deployment to the web, but we did have last minute efforts to rid the code of bugs, which we were somewhat successful in doing. We didn’t quite have time to fix all of the issues with towers, and consequently the user could place as many towers as desired. This was in part due to the follow up issue, that without proper playtime testing, it’s likely putting a restriction on this arbitrarily would have almost certainly made our game unwinnable.
Improvements
We have several aspects of the game we would like to improve upon in our future work, but there are four main goals: add more towers, adjust tower lifecycle, add enemy scaling, and random map generation. As the game is, there is only a tower that shoots milk at opponents. While this presents the basics of a tower defense game, we would like to add a few more towers including concepts like area of effect towers, and movement speed adjusting towers. This will give the game more interesting solutions, and allow the player to change up their strategy to better fit the opponents. In addition to adding more, we would like to change how the tower life cycle occurs. We have not yet nailed down how we are going to improve this aspect, but these changes would require the user to replace or replenish ammunition of the towers after some period of time.
All enemies spawn at the same location, with the same health. This means that the only way we could make levels more difficult is to spawn additional enemies. This is not an ideal solution, and so we are going to work to add additional cereals with varying levels of stamina to improve the challenge of the game. In addition to making enemies stronger, we would like to change the way maps are generated. Using a randomly generated map would add an additional requirement for the user to plan their strategy against the bowls of cereal. All of these changes will come together to help make CerealKiller the game we would like it to be!
-Connor, JD, John
Introduction and design
This last theme was perfect for us. We started as usual with a brainstorming and we had a lot of crazy ideas but finally we pick one of the craziest @ReikVal ever had: a game about Lagman. Well, he is based on a real person and he is one of the team members.
For @beagleknight, being the original Lagman is a pain on the ass. He plays online games usually between 200 ms and 300 ms of ping and that weekend he was specially lagging for the occasion.
After the brainstorming we designed the game. We wanted to keep it simple so we design a simple platform game where the main character will clear the enemies on each level to complete it. The player will be in constant high ping so his movement must be totally annoying and frustrating. After seeing a lot of comments on our entry with the word “frustrating” it’s clear we achieved the result :D. In the original design of Lagman we thought about four different enemies:
We designed different levels for the entry but only included four on the release. On the original design, we designed special zones without lag. In those areas the player would be vulnerable because he cannot kill the enemies having 0 ping. We couldn’t include it on the submit, a pity :(.
What went right
We used Javascript as our programming language choice. This is not our first ludum dare so we have learned programming a game engine from the scratch is the worst idea we ever had on previous jams.
This time we used Phaser.io by @photonstorm and we fell in love very quickly. The game engine is amazing and that’s not because their features or its performance. Phaser has a huge community with a lot of examples and tutorials. That’s awesome!
What went wrong
The f*** lag. Yeah, no kidding. We started a bit late because connection problems and that’s the main reason why we created Lagman so I’m not sure if it’s bad at all :D.
Personal triumph
This is the first LD jam where the team worked outside of their confort zone. In this edition @beagleknight was in charge of the art. He is starting with his tablet and doing his first sketches in years! We think the final result was pretty good after all.
Nowdays @ReikVal is improving his guitar skills very quickly as he demonstrated in this edition as well. He was in charge of the music and he did a splendid job improvising the two main themes for our game and also the special voice for Lagman in the death doors. You can download the music and sound composed for the game here:
https://soundcloud.com/reikval/playerdie
https://soundcloud.com/reikval/lagman2
https://soundcloud.com/reikval/maintheme
Conclusion
We are going to work hard on the following LD editions and we have decided we are going to start using Phaser on our personal projects as well. We love the engine and its community and we think it’s gonna be fun!
Check out our entry here and may the lag be with you!
http://ludumdare.com/compo/ludum-dare-32/?action=preview&uid=36994
Thought I’d mention here I spent a few days to fix a few things and add a lot of new content to the game I had made for Ludum Dare 29, Close your Eyes:

Can be downloaded from one of the following sources:
RPGMakerNet: http://rpgmaker.net/games/7578/
GameJolt: http://gamejolt.com/games/adventure/close-your-eyes/58200/
Itch.io: http://aestheticgamer.itch.io/close-your-eyes
IndieDB: http://www.indiedb.com/games/close-your-eyes
Trailer:
Tags: Close Your Eyes, horror, Ludum Date 29, updated
I finally updated some stuff in my LD32 Jam entry, Maggie.
These are the updates in the Post LD versions:
– Bug fixes;
– Added music;
– Added SFX;
– Improved the physics a little;
– Bats are now killable (gotta hit’em hard!)
The core mechanics hasn’t changed with the updates, and I didn’t add anything big, just the audio but it’s not rateable anyway, so it should be okay to play the post ld version. I’ll still keep the pre LD version just in case.
A lot of people mentioned the high difficulty caused by the randomness aspect of the game. That was by design and I intend to keep that unchanged until more people have played it. I think the biggest problem was that I didn’t introduce the player properly to the mechanics, I might work on that later.
PS: Thanks for everyone for the feedback, this is my first time in the Ludum Dare and it’s awesome!
Howdy friends, it’s @TheWzzard, and it’s Post-Mortem time. My entry is for the Jam and I did it solo, handling all the code, sound effects, music, and a bit of sprite editing / recoloring!
First let me say I was very nervous going into the Jam.
I also decided beforehand that I did not want to make a game that revolved around violence, thinking my entry could stand out since FIGHTING STUFF is what many (most?) games are about. So when the theme was announced my heart sank. Weapon! Anything but that! How was I going to make a game that didn’t involve violence while keeping the theme?
Nothing came to me immediately but I knew that there was a lot of work ahead of me. I needed music, sound effects, input, an engine, and some kind of interface. So I started with the music and the rest hopefully would become apparent. I didn’t actually know what my gameplay would be like until Saturday!
Overall my experience was AWESOME! Such a rush!
The final product ended up a combo-chaining game where the player high fives lonely skeletons to make friends. It is fast, colorful, and challenging, with 13 levels and a very short combo timer. The weapon? Friendship also high fives! As you make friends they go and do some high fiving of their own, possibly making new friends who might also go and make some friends and so on and so on! Basically it’s high fives all the way down. For Friendship!
You can check out High Fiverer: The High Fivening here!

High FIverer in Motion!
Since I’ve received some very positive feedback on the music so I’m going to describe my setup, my process, and approach a little. Listen along if you like on soundcloud: High Fiverer OST
First off my music composition / production setup included:
Ableton Push
I employed a hybrid production style with rock ensemble instruments (electric guitar, bass, drum-set) alongside FM / simple waveform synthesizers. My first instrument is drum set so I really like having sampled acoustic drum sets on my tracks. Sequencing and playing them is a little trickier if you don’t want them to sound like loops or samples so having a robust sample set and using lots of variations in velocities and patterns is important.
Game music poses some unique challenges especially in a jam setting. My total running time for my three tracks is 5:25 and 2:28 of that is the menu / final screen music. This means that the remaining two tracks are going to loop a lot considering that some levels may take 20+ attempts. I consciously used uneven section lengths and high contrast between sections to try to lessen the fatigue of repeated listening. Removing internal repetition also helps along with trying to have distinct lengths for individual sections. Structural repetition can almost be worse than having a short total length. 4 bars + 4 bars + 4 bars + 4bars gets old really fast! Our minds are great at recognizing patterns so it’s much less boring if the overall structure takes a few listens to internalize.
Don’t forget that poor implementation can still ruin your finely crafted minute long loop! If events in the game aren’t tied to the music, avoid restarting it whenever possible, especially if players are going to be restarting levels or changing screens frequently. If the levels are very short don’t change / restart the music every level.
If you want to check out more of my work I have more game music available on my soundcloud and even some OGA licensed tracks that you can use (for example if your LD32 entry has no music), and I am available to do commissioned work. Thanks for reading! Stay positive!
Tags: ld32, music, post-mortem, postmortem

Big Bertha vs alien robots! got a bugfix! You might not have experienced it, but there was a small bug which could possibly have done weird things with the game speed when the framerate was lower than 60. You can check out the fixed version (To guarantee that no feature was added, you can even still check out the previous version).
Also, I did not do a post for this, but since Thursday a Windows 8 Store version of my game is now available! It’s one of the very rare Ludum Dare games on the Windows Store (The third one ever published, AFAIK). It does not use the same low-level rendering mechanism (DirectX instead of OpenGL), but the high-level code (and thus the game features) are strictly the same.
Don’t forget you need a friend to test it because it’s an exclusively 2-players cooperative game … Due to popular demand, I’ll try to implement a single-player mode 
(I also still have my “post mortem” article to write, I was traveling so I did not get the time, but I think I’ll do it soon!)
This is my second Ludum Dare, so you should immediately be suspicious due to my lack of experience. My creative background is novels, so I enjoy making games leaning heavily on the narrative. My rule of thumb for creative works is this: make something I would want to play (read, watch, experience, etc.).
Last time I participated the goal was to get out a game that had a single, well implemented mechanic. I was reasonably successful. I noticed something immediately when I was judging that shifted my goal for the next LD. I was judging games in short, 2-4 minute chunks. Two to four minutes, that was all a game had to be evaluated. Maybe other play-and-rate judges are more patient than I, but I was motivated to move quickly from game to game by my own desire to experience more games and to acquire more “coolness”.
So LD32 rolls up and I have an altered goal (though functionally quite similar) make an LD game specifically for LD consumption, short, single-use*, and polished. So with that mindset I created Dye, a short, single-use, narrative experience. Forty eight hours is still only forty eight hours, so it didn’t have the polish I wanted, but I got it out the door and onto the net.
I have no intention of expanding Dye, improving it, or altering it in anyway. It was made specifically to be consumed and enjoyed once in 2-3 minutes. After that, judges can move on to the next game knowing they hadn’t missed out on anything.
Keeping the idea of the “judging hor d’oeuvres” in mind, changed the way I structured my game, and eased the stress of putting out a “full” game. My game is full, even though it is small.

Just look at that lil red guy, I want to squeeze him.
Since there’s a couple of puzzles in my LD, I made a walkthrough. There are some spoilers (well… it’s a walkthrough… ), but if you were stuck somewhere, you had a game ebraking bug, or it was too laggy on your browser, at least, you can have a wider view of the experience. And it only cost you 6 minutes of your time 
Play/Watch and vote!
Well, It’s been a week since we submitted our game, Break A Leg, and it’s given us time to think about what we have done. It was a blast to make and I personally am proud of what we had made. That being said, I feel like a proper post-mortem is in order. Let’s do this!
The Good:
Playtest the game mechanics the first night. Most of the Ludum Dares I get lost in the details of making the game that I don’t stop to think of whether my game will actually be *fun* or not. So, playtesting the game mechanics night one made me much more confident about the direction of the game.
I had backup for programming! This one was personally huge for me, since it gave me more time to think about the structure of the code and, consequently, make better code. A larger group also let us have some backup on each area of work. The extra help on art and code made a much better project.
The Bad:
Time. I know this is a common item on the bad list, but having some extra time would have been immense. Everyone had work on Monday, so the last day of the jam really wasn’t an option. We worked as late as possible and got a lot done in the final few hours, but we didn’t have time to get the audio that we recorded into the game.
Split work areas. Since we had a larger group than expected join us at the TinkerMill, we had to move into the main area for the Dare. We had the people doing art and sound working in one area and the programming group working in another. That led to a few issues with user interfaces and misunderstandings about what the vision of the game would be. Although we mitigated confusion by planning thoroughly the first night, some details fell through the cracks.
The Ugly:
Having to move into the central area. The main area was quite a bit louder than the conference room we were initially going to use, so it affected how focused we were on the game. It wasn’t a huge deal, it just made it take longer to get done.
Not participating in the warmup weekend. I was a bit rusty on the coding side, so it took me longer to get moving on the code than it should have been.
Next Time:
Reserve the classroom. I think that this would solve the split work area issues, along with the noisier work area. This is easy enough to solve, though.
Practice! Working on games is not a short term endeavor, so not practicing the art really takes it’s toll between the Dares.
As always, it was a blast to make this game and we look forward to jamming again next time.
I wrote a detailed post mortem about my game Duck Attack at:
http://ernesto.io/duck-attack-post-mortem/
TL;DR
The making of a game about controlling a flock of ducks and saving the world. Made with phaser in javascript.
I knew all those tweets to streamers and youtubers weren’t for nothing!
Here’s Michael Daley’s video of my game, Dare To Juice. Thank you soo much!
If you want him to play your game, you probably can tweet him about it @Michaeldaleyman
Now go and subscribe to him!

Hello Hello! So after 11 straight hours of streaming your games…..I’m ready for round 2!
I will play and stream and review your games, upon request I’ll edit your game out and send you a youtube link.
http://www.twitch.tv/nidolabzfhp
Tweet me your games @octopusmelange
I just added game maker source to my game ULTIMATE BOOTER And, also i started to work on something new. Creating of megaman styled game was pretty fun, so…. I make probably another one 😀 Now, i started with rewriting basic platform engine. I added more features like one sided platforms and moving platforms.

You know, if i can make whole graphics and engine + 2 levels in three days, i probably can make whole game in one or two months! So, my next game will be noir styled megaman game! It will be called NOIRman! And hero will be called Norman Noir 😀
Anyway, check the source if you want, play my game if you want, rate my game if you want and share my game if you want.
Driven Insane is AAGH Games‘ third Ludum Dare entry. I am our artist/programmer, so I’m mostly going to be covering that angle in this postmortem post. We’re fairly happy with our concept and the finished product but naturally there were some hitches along the way. You can play and rate it here.
Day One: Getting the theme, brainstorming and starting work
We were online waiting for the theme to be unveiled, and neither of us honestly had a goal theme in mind. None of the possibilities sung to us so we were open minded and ready for any theme. When we saw, “an unconventional weapon,” we sat back and debated what would be an unconventional weapon in a game. Everyday objects? Sporting equipment? Eating utensils? Melee weapons in a ranged weapon scenario? While debating this we also discussed what genre to use, going from fighting games and RPGs to adventure games and platformers before we had our big breakthrough: a racing game where you are the hazards instead of the driver.
Brilliant, we had a basic concept, but what hazards would you be? Ramps, spikes and barricades seemed too conventional for an unconventional weapon themed game, so after some debate, Floata (AAGH Games’ musician and level designer) reaffirmed his dislike for farm animals (he was the one who suggested killing chickens in another game of ours) by suggesting that we run into a cow. I got to work mocking up placeholder art for the cow and car when he suggested a flying pig as well. Sure, why not? Here is my original placeholder art.

Early car, cow and pig designs
Before we called it a night that first evening (we began at 9 PM) I redrew the cow and made an impact animation with cow-smashing special effects. With that complete, night one came to an end.

Yes, the cow explodes into hamburgers
Day Two, Part One: Flying Pigs and Actual Game Play
Early on day two I woke up and redrew the cow, pig and car properly with my graphics tablet and put them in the game. Downsizing them cost them a little detail, I think.

Just a little size difference
Now that we had the visuals halfway ironed out, we needed the thing to actually be a game and not a tech demo (or worse). Step one to making a game out of this melange was to asign point values to the various actions and configure a score counter, but that’s not enough. As it was, you could throw down limitless cows and pigs all over the screen, and worse they didn’t do anything since the car didn’t register any damage yet.
My first order of business was to make the pigs and cows go on cool down after use so you couldn’t just spam them. Applying the cool down was no big deal – it was applying a visual indication that took longer than expected. I didn’t want to draw individual frames for the buttons during their cool down periods but I eventually had to. I drew each one in 10 frames which worked for the pig (which was on a 10 second cool down, so 1 frame per second). The pig took some finagling since it used a 5 second cool down. I am crap at math so fortunately it wasn’t too complicated and I got that in.
Next I added a car health bar and set damage values to the car hitting the cows and pigs. At this point the game was really easy because as long as you used your animal attacks when they were off cool down you were golden. What we needed was a way for the car to defend itself and some degree of strategy and skill to using your attacks. The answer came in the form of health icons.
I drew some health icons and made a randomizing system to stick the health in the car’s path at different locations each time you played. The player needed a way to stop the car from getting the health icons so the pigs were given double duty in clearing health icons away and damaging the car. The pigs were only available every five seconds though which made for relatively long periods of helplessness on the players part -never a good thing. The cure was a third animal, one who would be usable often and whose sole job is to remove the health icons. Enter the squirrel, who – by being on just a 3 second cool down -was almost always ready and when used in concert with the pig made it possible for a skilled player to keep the car from ever touching a health icon.
Day Two, Part Two: Just Blips on the Radar
My biggest complaint while testing was that you never knew how soon the road would end on you, meaning you didn’t really have an idea how much time you had before you lost until it was too late. The answer – to me, anyway – was a mini map. I wanted it to be easily transferable from one level to another, and I didn’t want to have to constantly fiddle with its configuration, but the levels were not uniform in size, nor were they even proportionally scaled – they were all very different lengths. I ended up taking the length of the mini map area (400 pixels) and finding out how many times that would go in to each maps length (say, 17 times, rounded) and telling the map’s car location icon to move starting at the map’s left X position plus the car’s X position divided by that number I found earlier (17 in this example), and it worked. Success! That was the first time I had done anything like that so I was kind of surprised that it all worked out as well as it did.
Day Three: The Final Details
By day three Floata (the game’s co-developer, remember?) came through with the music for the game so I put that in and it fit really well. My biggest concern now was getting sound effects in before time ran out. I mooed and oinked into my mic, I read lines for the squirrel to squeak, I smashed pop cans and boxes for car crashes, and the results – while not exemplary – were satisfactory to me. The last step was adding a title screen, an end-game stat screen, a tutorial screen (or three) and testing the game for balance and stability. Satisfied with what we had and time running out, we submitted it and the rest is in all of your hands.
Take some time and give Driven Insane a rating, and please leave a comment letting us know what you do and do not like about it. Thanks for reading, and good luck to everyone.
Tags: ld32, postmortem
So as well as this being our first Ludum dare we’re also very new to making video games so this jam was a brand new challenge for us! But it’s been a blast playing all the insane games that came from this dare, and its been awesome to read the comments you guys have given us for our game BLODAU.
This is a rad community and we can’t wait until the next jam!! So to show our love I’ve made ya’ll a little gif of our game’s character 
Tags: flower, gif, jam, ld32, Love, Ludum Dare, screenshot
With almost 100 games registered so far and a bundle of them already covered
I have been busy making sure that these games are being covered of course with feedback and critiques too
Check out the games and my live game play highlights here
http://noaksey.com/contact-me/game-list/
of course if you want me to cover your game please follow the link below 
Tags: Critic, Critique, LD #32, ld32, Let's Play, live, ludum dare 32, Noaksey, NoakseyV1, review, stream, twitch, youtube