LD 38 April 21–24, 2017

Rock Hammer now in Google Play

Portadachi.png

Rock Hammer is the game that me and my teammate done for this past Ludum Dare 38 and we are so proud to announced that we released in the store, so thank so much for the feedback and you can play here: https://play.google.com/store/apps/details?id=com.LittleRamen.RockHammer

bnmbnmbnm

nbmbnmbnmbnmbnm

RADMARS game jam soundtrack compilation!

rad600.png

https://adhesion.bandcamp.com/album/radjams-vol-1

Hey all! I've been doing music (and sound design, and programming) for team RADMARS since April 2012, when we started doing Ludum Dare, and we've done almost every LD jam since. As part of our 5 year anniversary of participating in Ludum Dare I decided to remaster & release a compilation of the music from all of our games - featuring tracks from smash hit megajams such as Death Death Evolution (3rd place overall, 9th place audio LD24), Micromancer (8th place overall, 15th place audio LD33) and Super Kaiju Dunk City (4th place overall, 2nd place audio LD38)!

Check it out on bandcamp here: https://adhesion.bandcamp.com/album/radjams-vol-1 it's pay-what-you-want but feel free to put in 0 for the free download, I won't tell :wink: Thanks for checking us out! :skull: :dragon_face: :muscle:

Raven Delivery Service Post-Mortem

Congrats everyone on another Ludum Dare!

This was my 15th time competing in LD, and this time around we had (for the first time!) a team of 4, including @ibyume, @vincent-castelli, @xellaya, and myself. We ended up making a 2-player co-op potion brewing game called Raven Delivery Service, with design heavily inspired by Overcooked. While our game is best enjoyed as a couch co-op game together with a friend, there is also a single-player mode that tests your multitasking abilities as you control both characters at the same time.

raven-delivery-service-animated.gif

Let's first take a look at our results!

Overall: 56 (4 average in 48 ratings) Fun: 102 (3.783 average in 48 ratings) Innovation: 243 (3.413 average in 48 ratings) Theme: 618 (2.87 average in 48 ratings) Graphics: 220 (3.935 average in 48 ratings) Audio: 15 (4.333 average in 47 ratings) Mood: 168 (3.705 average in 46 ratings)

Not half bad! It's also worth noting that the average of all 7 scores is 3.72.

Since I've been doing this for quite some time now, we can also reference my stats at ldstats.info. That site hasn't been updated to scrape from LD38 yet, but it's the best way to compare our rankings and ratings to my past entries.

The first thing you'll notice is that my past entries put up some pretty stiff competition! I've scored above 4.0 overall in 9 out of 10 of the past compos that I've entered! Despite doing pretty well this time around, the average score (3.72) is lower than any of the 10 past entries that I've done.

What does this mean? Well...not that much to be completely honest. LD ratings are a fickle thing, and any number of things could have affected them. For one thing, I didn't push as hard as I usually do to get ratings, plus LD was..."interesting" this year, which in theory doesn't affect the actual scores but does affect the amount of feedback. If anything though I think the main contributing factor could have been a lack of polish, and the presence of some general rough edges in our game. (More on this later) Actually, scratch that -- the main contributing factor was probably that a fair number of the raters probably didn't play the game in its co-op mode! We'll dive into that later as well.

It's a pleasant surprise that I was able to place so highly in audio even while only making a single song for the entire game! I have to admit that I've been slacking a bit on the audio front, as I used to make entire soundtracks, but it's cool to see that I don't necessarily have to put in a bunch of different tracks to be appreciated.

What about my personal goals? In my I'm In post this time around, I said that my personal goals for LD38 were:

- Work well with everyone on the team :) - Stay happy and healthy, and cook good food! - Make something simple, that we can expand on if we have time.

Working well with everyone on the team? Check! It was quite stressful in the beginning for me knowing that we had two people new to LD and game dev in general and I was worried about being able to ramp them up and loop them into the process. However it seems like things ended up working out and I think we ended up with pretty nice teamwork in the end.

Staying happy and healthy? Hmm...I think I did "OK" on this one but could have done better. There was definitely a period of time in the middle of the project where I was feeling quite pessimistic and didn't know whether the design was really going to work out at all. It felt like there was so much left to get done and that the game hadn't yet reached that moment where it was fun. Fortunately my other team members picked me up out of it and we were able to tackle things one thing at a time. Also, we ate well :)

Making something simple? Uhh...no, I failed on that front yet again. More about this later, as I think it deserves its section.

As always, let's go over what went well and what didn't go so well.

What went well

Trying new things, having a bigger team

Not only was our game different than anything we've made in the past, but we had a different energy and flow to the team as well thanks to our two new members! Overall there was a lot of new stuff going on and I think it was great! In addition, I think it felt nice for both myself and @xellaya that we weren't the sole ones responsible for programming and art, respectively, and that we could distribute some of the workload instead of doing 100% of everything.

screenshot_2.png

Controller support

It definitely took a bit of fenagling to get everything to work correctly (this is the first time I've worked with Unity's joystick APIs), but I ended up with working, solid multiplayer controls where you can use either gamepads and/or keyboard in whatever combination you want! We got a comment as such, too:

I think this is the first time that I’ve seen someone use Unity’s input system correctly in a jam...:cry:

The main difficulty with input handling was that I didn't want to make any assumptions about the control setups that people had. In the end, I ended up mapping controller #1 to player 2, and controller #2 to player 1, and having keyboard bindings for both players. This way you can play in any way you want:

  • Just using keyboard? Just use the separate keyboard bindings for each player.
  • Have 2 gamepads? Plug in both gamepads and you're good to go.
  • Just 1 gamepad? Use keyboard for player 1 and the gamepad will be mapped to player 2.

Of course, in the single-player mode, any and all controls are bound to the single player, so everything "just works".

Major props to @xellaya who drew the control diagrams that we show to the players to explain the controls. They're simple, effective, and work much better than anything we've done in previous games.

I should note that I was really disappointed when the webgl build didn't seem to detect my gamepads properly, especially because Unity basically makes it impossible to make a standalone build that defaults to a specific resolution (their resolution-picked dialog tries to match the aspect ratio of the user's monitor...). But it turns out this was a fluke more-or-less specific to my system (I'm running Windows Server 2012 because I'm weird), and it actually Just Works (tm) on most sensible machines. Hooray!

I still did end up providing a standalone build for anyone who has trouble with WebGL controller inputs and/or wants to remap control bindings. This version did take a slight bit of extra work to make since I had to make sure that the input configuration dialog was self-explanatory and also we supported any reasonable resolution. It's worth nothing that the wide majority of standalone Unity games that I played did not do these two things correctly =(. I know that I'm in the minority here, but just because you have a standard 16:9 widescreen monitor doesn't mean that all of your users will. Construct your game accordingly! This is a little tricky to handle correctly for pixel art games such as ours, but you can use a scripts such as this pixel perfect camera one to help.

crow.png

Lots of fun details

We had a ton of fun details in the game that were not strictly necessary, but made the game that much more awesome. Things like the actual ravens flying around and unrolling the potion requests, the bubbling of the cauldrons (as well as the super awesome gurgling sound they make!) and last but certainly not least, the beautiful tileset that @xellaya made for me to build out the levels out of.

Tiles_1.png

All of the decorations, vines, and background layers really help pull things together into a more cohesive package rather than just a flat old boring set of platforms. I love it!

Coming up with a single-player variant that worked

At a certain point in the design phase I realized that I needed to come up with a decent single-player game mode. Up until that point I knew that we were going to have two witches and that our main focus would be on cooperative play, but I needed to come up with something that you could play by yourself as well, because I figured (correctly) that a lot of LD raters wouldn't get around to playing the game with a friend.

Fortunately the design for the single-player mode was not too involved at all, and I took a cue from Overcooked in that it was more or less the same game but with one player controlling both witches. So instead of an exercise in cooperation it becomes an exercise in multitasking.

One thing that had to change in order to make this work is that the cool little minigame arrows that you have to press in order to get / upgrade the ingredients had to go away for the single-player mode, because the whole point of single-player is that while one witch is gathering an ingredient you get to move the other witch around. This was unfortunate in that the single-player mode didn't really have the "full experience" but the game wouldn't make sense otherwise.

Some people who played the game in single-player mode said that they didn't actually realize you could control both of the two different witches in the first level. Luckily, I set up the second level such that you have to switch between the witches, so that level sort of forces you to make that realization.

screenshot_3.png

Co-op design

Saving the most important (and most lengthy) for last...

Making a co-op game was great and I would definitely do it again! When we settled on our idea, I knew that I wanted to achieve the same feelings of cooperation + teamwork that you see in Overcooked, and I went forward with design and programming with multiplayer in mind first and foremost.

It was very tricky nailing down the design to create a good "rhythm" of multiplayer gameplay and I could easily write an entire separate post about it. I heavily referenced the Overcooked level designs to see what really made them tick in terms of their design. This article, was extremely elucidating and I recommend it for anyone interested in these specific game design sensibilities.

I knew from the beginning that I wanted to make our game in a platformer-style, so I already knew that the movement would be mostly horizontal with ladders taking you between different levels. The next thing I had to do was to figure out the tasks that you needed to do in the game. Mixing 3 ingredients in the cauldron to make different potions not only was more or less equivalent to the basic design in Overcooked but also made intuitive sense as well, so that was fairly easy to figure out.

The next thing I needed to do was to somehow encourage teamwork over working alone. With just the ingredient gathering stations and the cauldrons, there wasn't any incentive to really work together besides coordinating which ingredients go in which pot. I knew I wanted some element that would encourage people to take on specialized tasks, sort of like an assembly line. Overcooked often does this by letting you transfer objects between each other using tables -- so in effect, you can move ingredients between each other much faster than if you were to just carry them yourself.

My first attempt at replicating that was to make a sort of table alcove that functioned as a "pipe" that you could use to send ingredients through (but could not travel through yourself). At this point I had enough elements to design a full prototype level and start testing the actual game to see how it played.

This is what the prototype level looked like:

Screenshot 2017-05-31 22.32.20.png

There's a lot of placeholder art here, but all of the elements are there -- the two mushroom stations on the left, cauldrons on the right, potion delivery stations on the top, and the two "shelf/table" objects in the middle that you can use to transfer ingredients (which ended up being replaced by the teleporter). Playing through this prototype level was invaluable and I was able to understand a lot of the design issues much better through the process.

Around this time we were also throwing around a number of other ideas, one of which was the ability to speed up the potion brewing process by fanning the flames around the cauldron (which required you to stay at that station). I implemented that without too much difficulty and we tried it out, but I quickly realized that the gameplay boiled down to a super boring assembly line: the optimal strategy was to have player 1 constantly gather mushrooms and send them over, and player 2 put them in the cauldron, fan the flames, and deliver the potions. I had successfully given the players reasons to do specialized tasks but there was never any incentive to switch between tasks, which made the gameplay super repetitive.

From that experiment I realized that allowing you to fan the flames around the cauldron was terrible for gameplay, so I took that feature out right away. That meant that player 2 had extra time left over, so they were incentivized to switch roles and help player 1 gather mushrooms.

I was getting closer, and player 2 had a more dynamic role, but there was still a problem: the optimal strategy still had player 1 gathering mushrooms the entire time, which was the most boring job ever. I had a number of different variables that I could tweak here:

  • Amount of time taken to gather a mushroom
  • Amount of time taken for cauldron ingredients to mix
  • Player movement speed
  • Level layout

After a while I realized that the way to get player 1 to do more than one thing was to make player 2's job require help. Putting ingredients in the cauldron was straightforward and didn't take a lot of time, but by changing the level layout by increasing the distance between the cauldrons and the potion delivery spots, I increased the amount of time taken by potion delivery. That gave player 1 a reason to go over and help player 2 while they were off delivering a potion.

We didn't end up using this level design at all in the final game, but it was still a valuable learning exercise for me to learn what exactly made the game fun -- ensuring that each person was able to do something different, but also that the players didn't get too comfortable doing any one specific thing. As with Overcooked, the main way to keep things dynamic is to make sure that there are more tasks to do than there are players. This was part of the reason that I introduced the enchanting station as a mechanic.

What didn't go so well

LD stuff

The Ludum Dare event itself was..."interesting" this year. This didn't affect us directly too much, but it's still worth mentioning as a small point.

Single-player learning curve

Although the single player design was fairly easy to implement and I actually had a ton of fun playing it and coming up with optimized strategies for high scores, I think a number of players probably weren't able to manage using both witches at once, as it does require you to be pretty good at multitasking and managing different things at once. It's unfortunate but I think for those players the real essence of the game isn't really there. The single-player mode is actually quite a bit more "difficult" than the multiplayer mode I think.

On the plus side as I mentioned, the second level forces you to switch between witches in order to do anything, so I think at least that part shoul be interesting no matter what. But aside from that, I think this is just the way that the game had to be. I could have somewhat alleviated the issue if I made all of the gathering timers longer (thus giving you more time to think about multitasking), but doing so would make the game more boring for those players who are good at multitasking and enjoy the challenge.

screenshot_4.png

Design challenges

I'm pretty happy with how the game design ended up working out overall. However there were some icky design issues that I ran into while trying to come up with good gameplay and well-designed levels that I'd like to point out.

The first and main issue was just the overall movement and layout style of the game. Yes, I really wanted to see what it would be like to have Overcooked-style gameplay work with platformer-like movement. But as it turns out, if you want to have a game like Overcooked, it really does work much better as a top-down game. The platformer movement (sans jumping) that we went with worked, but having gravity means that you are essentially limited to horizontal movement without the aid of ladders. So not only is your movement mainly 1-dimensional, but you have to have all these ladders everywhere.

This means that overall the paths are much much more linear and that the spaces in general aren't very open. This quickly became a big issue in the later two levels where it became a challenge just to fit all of the different stations that I wanted into the level in the first place.

Another related issue was needing the teleporter in order to transfer ingredients across spaces effectively. While this worked (particularly in levels 2 and 3), Overcooked had a much cleaner and flexible design in that they allow you to place ingredients on tables -- which also form the walls and layout of the level itself. That didn't make sense with our platformer world, hence the need for the teleporters. But again, that ended up being yet another element that I needed to cram into the levels, which were already cluttered by all the different stations that were needed. (it didn't help that most of the stations were 2x1 blocks).

Yet another issue was with the teleporter itself -- you can put multiple items through the teleporter one after another, but they end up stacking over each other in the exact same spot and the order in which you end up picking them up on the other side is anything but obvious.

None of these issues were gamebreaking per se, and I don't think we really could have done too much about them and still made the game that we did. But they were issues that cropped up nonetheless.

Project scope, polish and amount of content

Oof, the biggie. Of course, it's not uncommon that people bite off more than they are comfortable chewing, but I do think that in the past I have definitely done better -- Melody Muncher, Rhythm Gunner, and even Nyamo's Adventure, for example, involved much smaller core ideas, and as such they ended up being more polished final products.

I think the issue is that coming up with a small concept always sounds great in practice, but anything interesting and worthwhile inevitably ends up being a really nontrivial amount of effort. At the point when we finally thought of the idea of the Overcooked-like game, we were also reaching the end of our wits on Friday night, as I kept on trying to think of new ideas but nothing was really coming to mind. Looking back on it, the connection of our game to "small world" is a bit tenuous, but I think that's fine in the end. The one other idea we had was a game about anthropomorphic pollen invading a person's nose. If we had made that game instead, everything would have turned out completely different! (haha...)

And so we settled on our idea, which ended up being a very fun one in the end. But I think the biggest issue with the idea was that it involved so many moving parts to come together before we really had the actual game on our hands. Before our game could really "take life" we needed all of these parts:

  • 2 characters moving around, and climbing ladders
  • Multiplayer controls
  • Ability to interact with different objects in the level
  • Cauldron object for mixing together potions
  • Ingredient gathering stations
  • Potion request queue system
  • Ability to deliver potions and get a new request ...

And of course even after getting all that done and having the "core game" there were still so many things left to do, like the game timer, endgame countdown, menu, instructions, level design, game balance, UI, and all of those such things. I think because of all of this it was very difficult for me to see the game coming together as a whole, even though in reality we were doing good work on all of the constituent parts. Working as the game designer it was quite concerning for me too, that I couldn't really tell whether the game was really going to be fun or not. I worried a lot that we would get too far in and then discover that the design wasn't really fun, and then it would be too late to make very many changes.

Of course another result was that we didn't have time to polish very many things and spend time on all of the details as we would if we had done a smaller idea. Fortunately we were still able to put in some very neat details like the ravens flying around and things like that, but we really wanted to do a post-game score screen that displays the potions that you were able to make, and also gives you some sort of awards for getting high scores. But there ended up being no time for that. Similarly, our tutorial screens were simple static images because we really had to rush through those. I'm glad that people were still able to understand the gameplay despite that.

In the end I don't regret taking on our idea, but I think in the future it's important to be realistic about expectations and understand that there is a certain higher level of risk when tackling such a large idea. It would probably help to outline all of the different parts that need to come together to get the core gameplay done before finalizing the idea, to see if there's any way we can strip it down, or at least to see what we're getting ourselves into.

I've written quite enough now, so this'll be the end of my write-up. Hopefully someone finds the retrospective interesting in some way. Hope to see you all next LD!

Looking for a good game designer to work with

I am currently looking for a good game designer to collaborate with on an on-going mobile game development. If you are familiar with Shooty Skies then you have a good idea of what I am looking for.  If you have good game design skills for top down shooters then drop me a line on callie@micazook.com please.

Cheers,

Callier

 

Hello Ludumdare

Just discovered this site today (3 June, 2017). I’m just feeling my way around and will begin contributing soon.

Comments

07. Jun 2017 · 00:41 UTC
Welcome! We love to see new faces around here!

Campfire for LowPoly Daily in twitter

Not as good as the first one(Shipwreck it Ralph) cause I just rushed it. Though please appreciate my effort (it still took 2 hours I think). The theme is fire https://www.youtube.com/watch?v=E48mxX3kOMc

Play my remastered version of Ludum Dare 38 Jam Entry: Destroy Blocks

As the title says, I remastered my LD38 Jam Entry.

For remastering my game, I looked at many comments from others. I listened to feedback and made adjustments to the game. I made the original controls much easier to use (WASD to move, Mouse to Look Around, Left Click to destroy blocks). I also fixed the glitch of falling off the world. I also made the game a lot less laggy (had to sacrifice the use of shadows though). Also, I made the gravity switching mechanic in my game much easier to use. I also added enemies in my game as there were a couple of requests asking for danger features to spice the game.

For the music, I could not find out a way to fix its sound (because I am bad at recording audio) so I left the music as it is. It cuts in and out then, but the music is still fine and enjoyable to listen too.

Play my remastered version of the game through these links: https://gamejolt.com/games/Destroy_Blocks/251837

https://d-studios.itch.io/destroy-blocks

Look at the Ludum Dare Game Page here: https://ldjam.com/events/ludum-dare/38/block-destroyer

Also, if interested, you can check out my other games through these links:

https://gamejolt.com/@D-Studios

https://d-studios.itch.io/

https://play.google.com/store/apps/developer?id=D-Studios&hl=en

The Z Axis Extended Edition

The extended edition of my LD38 game The Z Axis is now live on Steam Greenlight, featuring an extra 11 levels. I also updated the GameJolt page to include a post jam version of the original 9 level game with improved visuals and bug fixes.

GreenlightGif.gif

Check it out! Original LDJam.com page:

https://ldjam.com/events/ludum-dare/38/the-z-axis

Steam Greenlight page:

http://steamcommunity.com/sharedfiles/filedetails/?id=940494597

Stonehenge pieces for LowPoly Daily in Twitter

My entry for LowPoly Daily with the theme: stonehenge. Youtube process with fbx files (link included in the youtube video’s description).

https://www.youtube.com/watch?v=TEGIoZX-rIc

DISCo for LowPoly Daily in Twitter

My entry for LowPoly Daily with the theme: disco. Youtube process with fbx files (link included in the youtube video’s description).

I tried some advice and did the materials in cycles render. I am quite happy about the results but I still don't know how to export and import emission material to unity for the disco lights. So what I did for the lights is I just added some spotlights in unity to make up for it.

https://www.youtube.com/watch?v=zqkHSo7fVZk

DISCo for LowPoly Daily in Twitter

My entry for LowPoly Daily with the theme: disco. Youtube process with fbx files (link included in the youtube video’s description).

I tried some advice and did the materials in cycles render. I am quite happy about the results but I still don’t know how to export and import emission material to unity for the disco lights. So what I did for the lights is I just added some spotlights in unity to make up for it.

 

Tags: 3D, animation, blender, model, unity, youtube

SlamJam: waiting for LudumDare 39

Hello! I just want to show you the game I did for the gamejolt slamjam with theme "Fringe". Any feedback will be great to learn more for the next Ludum Dare. Learning is crucial for making better games.

http://gamejolt.com/games/6543299712/260581

I know it's not the best place to show you this, but it's a pity that the slamjam wasn't very concurred so almost noone has played my game and I work very hard for the weekend. I really hope you enjoy it!

Ludum Dare to Believe! Season 9 : EPISODE 5

Hey everyone! We are the Button Masher Bros!

We are back and ready to showcase more of your favorite Ludum Dare games!

It's the season premiere of Ludum Dare to Believe! It's S:9 Ep. 5!

(May contain strong language)

https://www.youtube.com/watch?v=EzrcD8uvgIs&lc

With so many submissions, there was absolutely no way we could play them all.

Special thanks to our friends at Reddit, twitter, and Youtube who all stepped up to give us suggestions - you guys are the BEST!

If you like the games you see, be sure to check them out on Ludumdare.com and let the developers know what you think!

Today we will be highlighting:


Title: The Adventure of Malvin

Category: Compo Entry

Creator: NOFUEL (@nofuel)


Title: More than a Pixel

Category: Jam Entry

Creator: CAREFACE (@careface))


Title: W.R.L.D. (World Reconnaissance eLite Defense)

Category: Compo Entry

Creator: TerraCottaFrog (@terracottafrog)


Finally, we'd love to hear what you think! You can comment on the episode linked above, comment in this thread, or tweet us at:

@ButtonMasherBro - Show account

@MathBlasterRitz - Chris

@SuddenlyZach - Zach

or @jwowBMB - Josh

Thanks Everyone and HAPPY LUDUM DARE!