LD32 April 17–20, 2015

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!

Play Hush

Tags: hush, jam, ld32, music

Comments

26. Apr 2015 · 19:11 UTC
I liked the overall rhythm and layering of the sounds, but some of them (like the first couple solo instruments that come in) I found somewhat abrasive, especially over time hearing it. There is a little sound in the middle-ish area that sounds like a small dog bark or something. Haha, I really loved it when that sound first popped up. I left a comment through soundcloud pointing out it’s precise location.

Bubbles – a post mortem and an enhanced post compo version

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?

  • Choosing GameMaker:Studio again. I’m getting comfortable with it (though I still think a programming language without OO features is crap!) and that means I’m getting results fast!
  • Using the GameMaker community. After I came up with the game idea and the platformer game type it was pretty easy to find online tutorials that helped me implement a platformer engine pretty quick. After a few hours I had a working prototype including first pixel sprites!
  • Trying PyxelEdit. While creating my pixel bitmaps with the builtin sprite editor of GameMaker I was annoyed that it’s so hard to have a look at the other animation images of a sprite. So I remembered I’ve purchased PyxelEdit several months ago and decided to give it a go. Two intro tutorial videos later I was working really fast with the tool (keyboard shortcuts are great to learn!) and used the tool for all remaining graphics work.
  • Creating sound effects on my own. All sounds you hear were created with just a microphone and a bit of cutting and pitching with Audacity. That was really funny – first time I tried that at all!
  • Having a day off on Monday. What a relief! I knew that I could spend the whole Monday to do all household and cleanup work that was left over the weekend. Also I didn’t need to iron my shirts for the week on Sunday evening but could delay that til Monday. And I didn’t have to go to bed early – which was a real life saver if we come to the “What went wrong?” part! So I can only recommend to others and try to remember for myself to have a free day after the LD weekend!

What went wrong?

  • Music. Again. This time I had a few more hours left (I thought!) and tried to create some music. Only tool that I was a bit used to was Music Maker Jam on my Android tablet. But preset loops, some effects and changing chords just didn’t do it – nothing fit the game so I dropped music completely for my LD entry. Again. Disappointing. I will try to learn a bit of FL Studio and use that for simple game loops. Next time.
  • Bugs! Not in my code – I can find and fix those, but bugs in GameMaker. There were two annoying bugs I had to fight with. One bug was related to a negative sprite width which can’t really happen, right? A sprite width should always be positive. Unless you decide to flip the image using image_xscale in GameMaker. Flipping images is pretty common so you only need to draw the right movement, flip the image and automatically get the left movement for free. But flipping had the effect (read: bug) that the sprite width turned negative and all collision calculations failed completely when moving left…luckily the abs() function can help here. Took me an hour to find and fix that. The second bug was even worse because it only happened in the HTML5 release of my game. All worked great under Windows but in the browser version my hero fell through the “fall through platforms” all the time. He shouldn’t do that when the hero lands on such a platform from above. Due to the way the “fall through platforms” were implemented I discovered a bug in GameMaker:Studio where having no sprite but just a collision mask doesn’t work in HTML5…So I had to modify the code to set and remove both whenever I wanted to. That took me nearly two hours late on Sunday evening when I was just preparing the release package to upload it to the Ludum Dare website. Instead of finishing everything around midnight I stayed up until 2 AM Monday morning. And I had to get up again at 6 to get my boys to school and work…
  • Graphics. Hmm? I mentioned that on the “What went right?” part, didn’t I? Yes, but in fact I wanted to create graphics using Inkscape. But that didn’t work – I’m just not experienced enough with Inkscape yet to use it fast enough to achieve what I want to create. Too much fiddling around or looking things up here – so back to pixel graphics it was.

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!

Crowd Control – Post Mortem

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

PostJamVersion1

 

 

 

 

 

 

 

 

 

 

The Way of The Unconventional Weapon the Post-Mortem

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.

Captura de pantalla 2015-04-19 a las 1.19.34

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.

Captura de pantalla 2015-04-26 a las 22.18.48

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.

Captura de pantalla 2015-04-21 a las 0.53.47

What went right

  • Using cocos2d-js the game works on the web, so no stress to get a windows port after the jam :-) this has increased the visibility of the game
  • We decided fast on the type of game, that allows us to concentrate on development
  • The gathering with other participants, well at the end we were only 3-4 people for two entries, but anyway was fun and also increased my concentration to the task, I was able to dedicate more time than in other LDs where I got more easily distracted of the game

What went wrong

  • I planned less the development than in previous editions and started coding without seeing the big picture first… I think because of this I ended spending too much time debugging

Anyway we are really happy having finished again a game for LD, as usually a lot has been learned and we will participate again :)

Play here The Way of The Unconventional Weapon

Post Mortem: Serial Killer

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

Lagman – Post mortem

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:

  • Soldier: A simple enemy who shoot randomly. This is the only enemy we included in our submit.
  • Specialist: A faster enemy who uses a melee attack while jumping.
  • Admin server: He can kills you instantly upon seeing you, like he reported you for high ping.
  • Troll: A normal player who is using high latency intentionally with additional software.

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

Updated my Ludum Dare 29 game, Close Your Eyes

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:

001

 

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

Post LD Updates to Maggie!

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.

 

Play and rate it here!

 

PS: Thanks for everyone for the feedback, this is my first time in the Ludum Dare and it’s awesome!

High Fiverer: Post Mortem or How I Learned to Stop Worrying and Love the Theme

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.

  • This was my first Jam of any kind.
  • This was basically my third game ever.
  • I didn’t do any warm-up which wouldn’t have been a huge problem but…
  • The game project I’ve been working on for the past 6 months only takes input from IRC, is AI driven, and has procedural levels, so no physics, no direct input, and no level design.

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!

What is High Fiverer?

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!

High FIverer in Motion!

Tools Used

  • GameMaker: Studio
  • GIMP
  • Ableton Live
  • sfxr

Breakdown of the work (from what I can remember)

  • Friday – Most of the music and basic top-down engine, still not certain what the gameplay would be. At this point I had a character that could move in four directions and throw candy at skeletons to turn them into people. I definitely knew that making friends was going to be a part of the design but I still had no idea how it would actually work.
  • Saturday – Riding my bike home from my Saturday morning class I decided to try to make the high-fiving game I had joked about months ago. The original idea for that game was more of an Arkham style combo thing, but with my somewhat functional top-down engine I felt I could make some kind of combo chaining game. The rest of the day was spent dealing with implementing that and adding mouse controls. Basic menus and a several levels were put together as well. I believe Saturday is when I made the high five visual effect that I am so proud of.
  • Sunday – Tweaking levels, final music track, SFX, sound implementation, making more levels, and engine tweaks.
  • Monday – Tweaking everything basically. Lots of great changes to collision, motion, and visuals were done on Monday, along with lots of work on levels and menus.

The ‘Good’

  • Started with music – This gave me time to let the theme sink in and it meant that I could try to make all the other elements fit the music. This helped immensely for building my confidence and getting the ideas flowing.
  • sfxr is awesome – I could have made sound effects in Ableton Live but it would have taken way longer!
  • Confused about the deadline – Due to my horrible time-math skills I thought I had until Sunday evening to finish until I checked the website on Sunday afternoon. This actually helped because I had something I could have submitted that night but the “extra” time let me polish almost every element of the game.
  • Made a positive game – There is enough negativity floating around, High Fiverer is meant to be challenging but also super positive at the same time, and I feel that the overall design accomplishes that goal. No one is killed, shamed, injured, or put down!
  • Used existing artwork from opengameart – While I was hammering out the details of the gameplay I looked to the characters / tile-set to inspire me. This saved me time also but it had a drawback as well (see below).
  • Visual feedback – Not only did adding a lot of feedback through simple shapes help me understand the timings and ranges I was tweaking, I found that they really helped make the game pop!
  • Simple input – I went back and forth between mouse and keyboard input during the first 30 hours or so and eventually found that using mouse input would be simpler to implement and require way less time to tweak, which freed up more time for adding a third music track and adding more visual feedback.
  • Room-centric approach and inheritance – GameMaker: Studio is the only development environment I’ve used for games and for this project I finally found the correct balance between using global variables and relying on room_restart() to simplify repeating stages. I also streamlined my menu building / tweaking process by leveraging inheritance as much as possible.
  • Easing – This is my first attempt at using easing for anything and I almost started crying when I got the big-hands-converging-into-the-high-five-effect working.
  • Streaming – I streamed almost all of my work on twitch and I had a handful of viewers that really helped me stay sane!

ScreenShot!!ScreenShott!!!

The ‘Less Good’

  • Physics and collision – Since I couldn’t decide how input was going to work, the engine didn’t get iterated as much as I would have liked and with some better implementation the motion could actually be more exciting.
  • Using existing artwork – Yes this was on The Good list too but I spent a lot of time polishing the look of the game but had to opt out of the Graphics category. The visuals definitely make the game more fun but I still wish I had made everything myself.
  • Level design – Since I was tweaking how the movement and chaining worked until the very end, the levels are not as polished as I would have liked, though I am happy that the number of levels (13!) is far more than previous games I’ve made.
  • Friend movement – The movement of the friends needed another iteration or two.
  • Limited mechanics – This ties in with level design. I would have liked there to be more elements in the levels to change up the gameplay.
  • View shifts – The changes in view have come a long way but some players have found them jarring.

The ‘Needs to Be Better Next Time’

  • Weak onboarding – I tried to make the instructions as clear as possible but I ended up needing to post more info on my submission to clarify. Perhaps more text or numeric info during the game could have helped but I felt that I already had so much stuff on the screen.
  • Too much compiling – For my next project I need to implement a way to change variables while the game is running to reduce the amount of time I spend changing something and re-compiling only to change it again. This ate up a lot of time even for a very small game. An in-engine level editor would have been very helpful also.

A little bit more detail about the Music

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 Live 9 Suite w/ Ableton Push
    • I cannot recommend this software enough for composition and production, such a workhorse
    • Ableton Push is a hardware controller (pictured below) that streamlines Live MIDI workflow to the MAX
  • Ableton Session Drums (These sound great and have lots of detail!)
    • My go-to kit for these tracks was British Vintage
    • I always run these through a multi-band compressor to make them pop
  • Sampled instruments from the Live Suite
    • Electric bass and electric guitar are sample sets that come with Live Suite!
    • Same with the marimba on Keep Fiving
  • A few custom soft-synth patches
    • All synth tones are made with Ableton Operator which is excellent for FM and simple waveforms
    • These patches all have controls mapped to the Push for easy tweaking
  • A few commercial effects plugins, many Live effects and some free VST effects
    • I used NI Replika for all delay processing like on the guitars
    • All amp modeling and compression is done with Live effects
    • Master channel processing uses TLs Maximizer, Stardust, SPICE, and CrossMix

Ableton Push

Ableton Push


Almost all of the individual voices were played using the Push as input, with only a small amount of sequencing on the Push, and some arranging and editing in Live’s Arrangement View. I find that is easier to smooth out transitions between sections in Arrangement View with a mouse and keyboard. I cannot recommend Push enough for speeding up workflow if you already play your parts on a MIDI keyboard. Going from sketch to finished piece can be stupid fast and I made sure to take full advantage of adjusting clip lengths using the device which I often use the mouse and keyboard for.

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! update(s)

screenshot

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. WinStore

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

Comments

26. Apr 2015 · 23:20 UTC
Nice to hear, that someone else is interested in publishing for Windows Store. How about Windows Phone version?

The Ludum Dare meta theme: games as bitesized morsels

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.

L.O.V.E Walktrough

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!

Break A Leg Post-Mortem

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!

TitleScreen

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.

So, my game just got a video of itself!

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!

Comments

27. Apr 2015 · 07:04 UTC
Ha! That’s Great!
Michaeldaley
27. Apr 2015 · 14:51 UTC
Absolutely, thank you for the shout out. And yes, get at me on twitter and I will certainly record for almost any game asked of me. (Just needs to be compatible with my LP style and has to have a downloadable link, very few browser games from LD work with fraps). So get at me guys, and thank you Melange for the kind words :-)

Let’s Play

silentop_lets-play_10723-600x600-b-p-313131

 

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

ld_logo

lets-play-supercrafts-mrhass

LargeEat player_running

Source added !

Yo fellow darers!

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 Postmortem

Driven Insane logoDriven 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

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 those are hamburgers

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

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

Thanks Ludum people

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

love

Tags: flower, gif, jam, ld32, Love, Ludum Dare, screenshot

Noaksey’s Playlist and the Highlights so far

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

ld-32-wallpaper-2560x1440NK

Tags: Critic, Critique, LD #32, ld32, Let's Play, live, ludum dare 32, Noaksey, NoakseyV1, review, stream, twitch, youtube