Hey everyone!

This Is Danger Castle: Where every map, level, and enemy is completely procedurally generated. In classic Arcade/roguelike fashion It’s got randomization, slow progression, 50 levels, a timer, and unfortunately terrible controls!

You can click here to go to the page or click here to go straight to the game!

Due to circumstances, as usual, I don’t have much time to play and rate games, which means I have to ask for votes. If you would like me to play your game, please leave a link and i’ll do my best to play all of them!

Happy jamming all :)

4 loops in 3 minutes! My personal best is 2 loops, but I think I got really lucky that time :laughing:

Try and beat me

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

In our game you control a Time Mage who can't die, he goes back in time instead. You must defeat Drax Voder and his minions to save the fallen lands and try not to be stuck in a loop of infinite battle.

Play and rate our game Never Gonna Loose Again

RING RUSH [Compo]

"The game is simple to learn, and quite challenging" - @Dharby

"Unique take on the theme and a great game play" - @apbakeware

"Highly innovative mechanic" - @marcmagus

"Loved the suffering" - @shelvid

https://ldjam.com/events/ludum-dare/47/ring-rush

Available on HTML5, Windows and Linux

I have uploaded the webgl version of my game into itch.io. I´m still lacking some votes, so if you have some time, please have a look at it.

https://ldjam.com/events/ludum-dare/47/death-is-in-the-air

Thank you all!

Press The Button is an idle game about pressing buttons to complete tasks, get upgrades and finally get that promotion. There is no other goals, no other desires. Just press the button, #1000789

The company welcomes you: https://ldjam.com/events/ludum-dare/47/press-the-button

Summary

Among Stars and Robots is our third Ludum Dare-entry together but we have been working on games together for almost a decade now. We decided from the start that we wanted to target a WebGL build that would work on as many devices as possible, which meant we had to go low poly and simple materials only. This would also let us bang out a lot of varied content in a short time.

As usual we spent the days leading up to the start brainstorming ideas for the various themes that were up for voting in the last round, only to scrap all of them the moment the final theme was revealed. We quickly settled on the idea of programming a robot with a looping set of instructions. After dividing out some tasks we both went to bed to get to work early the next morning. If there’s one thing we’ve learned over the years is to eat, sleep and shower for a more enjoyable and productive game jam experience.

What went well?

We are very happy with the end result of this jam. The development process went smoothly without either team member feeling blocked by the other at any time. The first thing we made was a custom level editor inside of Unity. Any waiting time could then be spent brainstorming new levels or iterating on existing ones using this editor.

The biggest contributor to the end result was probably our planning process the first night where we mapped out a Minimum Viable Product and having a strongly established art style to adhere to which really helped us stay focused and keep the scope of the game down.

The code this time around was relatively simple, there are no animations other than simple tweens and no (significant) custom shader magic going on. Instead we focused on making the core mechanic interesting and the presentation really juicy. This is why we put a lot of focus on the level transitions for extra visual flair which from the feedback we got has been one of the most appreciated aspects of the game.

Trying to learn our lesson from our last attempt at Ludum Dare (Pull the Levers from LD46) where a lot of people struggled due to the lack of a tutorial, this time we tried to add better tutorialization in the form of three introduction levels and a simple animation in the first level to explain the controls, as well as an infographic on the itch page. But, as it turns out, this still wasn’t enough.

What went bad?

As mentioned above, the tutorials didn’t manage to help players all the way to success. The first problem was the detector command which is introduced in the third tutorial level. This command is significantly different from other two commands previously introduced (turn and move forward) which are both very simple to understand. Players initially tended to dismiss the detector command as something that would not be needed to complete the level. The level was then solved either by trial and error or by consulting the included infographic. In conclusion, this command definitely required much stronger in-game tutorialization.

The second problem was our difficulty curve. Once players got past the tutorial they were introduced to the hub world. The idea was that the initial position and view direction of the player would guide them to the easier levels but this didn’t work because first and foremost, we messed up the actual ordering of the levels. Second, players did not seem to care and just went to whatever level caught their interest. Many did not even realize they were in a level select world. Luckily we implemented a home button that would let players return to the level select without completing the level so if they got stuck they could try another one instead. The level select definitely needs some kind of indicator for how hard each level is so players can progress in a more logical manner without getting frustrated.

The third problem was some simple but very important UX features we failed to implement. Between levels there is a variable amount of commands allowed in the player’s loop but there is no indicator of that, so many players thought it was the same for all levels and got stuck on the ones that required more commands than normal. The other problem is that you can change the loop while it is running, but changes do not apply until you click stop and start again. Many players tried to change the loop and got confused why the robot kept repeating old commands. Both of these are easily solved and with hindsight it’s obvious that we should have prioritized it a bit more. Fixing these problems solves a lot of headache for the players.

Another mistake we made was including too many patrolling police robots in our levels. Just like the player, the police bots execute commands of their own, but there is no real way of telling which commands they execute. As a result their behavior is very hard to predict and forces the player to resort to trial and error in order to beat the level, which is not something you want in a puzzle game.

What next?

So what’s next for Among Stars and Robots and what lessons should we take with us? There’s definitely a point to be made that we need to work even more on our sense for difficulty scaling and progression. There’s a clear improvement just looking at our Ludum entries where our latest game is by far the best in terms of difficulty and tutorialization but there’s still a lot left to do.

Had we done more testing with someone outside the team before release we probably would have been able to catch those few UX problems and prioritize them so that’s definitely something we will look at in the future. As for what else lies in store in the future we will see. We are both overwhelmed with the positive response we have gotten so far and the game feels like it could turn into a really fun full game so it’s definitely on the table to make a full production game out of it.

We hope you enjoyed reading this post-mortem about some of our experiences from this jam, if you want to try our game check it out below and let us know in the comments of some of your own ups and downs from this event!

https://ldjam.com/events/ludum-dare/47/among-stars-and-robots

• Decreased player height/increased jump height so traversing level 2 is less finnicky.
• Blocked off unintentionally skippable part of level 2.
• Fixed crate collisions so now crates don't push through walls.

^^^ Click to Play ^^^

It's now been just over a week since Ludum Dare 47 began, so an ideal time to reflect on how well things are going so far. I've been taking part in game jams for seven years now, and this was my 16th Ludum Dare, although you find that every game jam you do has a challenge that you never expect, no matter how many you do (and I've done over 50 at this point).

So the game: Twist Turn Shoot Burn is an auto-run 'n gun, you run around a randomly generated path shooting red things from one of two lanes. Here's how it was made:

The Idea

As I wrote in my entry post, I wasn't a real fan of any of the themes. I was actually hoping "Technical Difficulties" would make it to the final voting round, but alas you make with what you do. My usual plan is to brainstorm ideas, with the goal to have at least one idea per theme. Ideas in this case is usually a simple phrase to describe a game's setting or mechanic.

All I had for "Stuck in a Loop" was this: Run (and shoot) inside a loop.

Yeah, not sure why but even as I slept, my attempts to think of what game I could make around this theme always reverted to this. As such I just gave up and decided how on earth I was going to get a game to work...

Day One

So to people who know my approach to game jams (all five of you...), I have a set of rules that I always follow when working on game jams regardless of length. A lot of these rules were written and refined from experience for efficient development and maintain good wellbeing.

So day one was purely focused to develop on gameplay, and the first thing I needed doing was having the player run around a basic path.

Following rule four (stick mostly with what you know), I figured I'd do a tilemap but I was worried about how to do collisions. My engine's tilemap system isn't built to handle slopes and curved paths, and I wanted the player to go around a proper loop. I was worried that I was gonna have to figure out how do write a Sonic-style platforming system. Then I was literally booting up my PC, first thing in the morning, when I realised: I didn't need to calculate collisions, I just need to calculate positions.

I made each game object stick to a specific position based on an X and Y value (between 0 and 1) what tile it's currently situated in. The X value would position it from one side to the other, and the Y value would handle gravity and securing it to the floor. I originally had it up and running by midday, however in my original approach, the player would move fine on tiles that moved straight, but would float on turns. It took an hour's walk, a hour lunch break and about two more hours for me to get it to work correctly.

It was also during that first lunch break and walk that worked out how to do obstacles. I only wrote four enemies: Same Direction, Opposite Direction, Bounce and Always Flying. I also decided to do something similar to Super Crate Box, have it so enemies would spawn the moment you defeat one. All the enemies use the same movement behaviour as the player, which funnily meant the Always Flying enemy was the hardest to implement because it wasn't straightfoward to disable gravity.

You might notice the player had the ability to jump. The original plan was to have the player shoot, jump and change places. I eventually decided to diable jumping because I found myself always changing direction more than jumping.

Day Two

The base game was pretty much done by the end of Saturday, I did want to make the levels more random but I wasn't sure how to do it, so I decided to leave it as something to implement if I had time. For Day two, it was all graphics and sounds.

This is where rule 5 ("Make Your Content Easy and Noticeable") comes in. This rule was concieved after Ludum Dare 42, where I spent somewhere around five hours on a detailed player character, despite how small it actually appeared in the game itself.

Piskell is my tool of choice for doing pixel-based sprites, as it's easy to pick up and test out frame-by-frame animation. All I can say for the player character is that I cannot confirm or deny whether the recent popularity of Among Us or Fall Guys had any roll, but I will say that the 2-bit palette of Downfall was deep in my mind when thinking of the visual design.

Visual effects are also a prerequisite for most of my games, partially because one of my game dev influences being Jeff Minter, and I'm a huge fan of his vibrant nightclub/psychedelic visual aesthetic. The main effects I use were Chromatic Abberation (distorting the red and blue colours), Bloom (make pixels glow), scanlines (TV effect) that constantly offsets, Bad TV Shader (to get the noisey distorted look) and a fisheye lense (to make it buldge out slightly).

For sound effects, I used sfxia and ChipTone. If I wanted more realistic sound effects and wanted to go with the loose jam rules I'd mix and mash stock sound effects together, but I know with this game's visual design that I was going with a retro-esque feel.

For music, LMMS. I've gotten comfortable with it as a music creation tool, although when I tried to mess around with soundfonts and VST plugins for retro inspired music. That's when I went back to Jeff Minter's games and decided to try a drum 'n bass approach. Fortunatelly I did experiment with this for an earlier Tetris recreation project, and I was able to come up with a 1 1/2 minute long loop that I was satisfied with.

Based on my social media posts, I had everything submission ready by 4:30pm. That meant pleanty of time to get the submission details ready and add in stuff. I added a new enemy at this time, and tweaked around the controls, but I didn't think there was much that I needed doing. It wasn't until two hours before the deadline that I decided to give randomly generated levels a go, you can read up on how well that went here.

Conclusion

I'd say this game went better than I thought it would, I'm always into making small arcadey games and after this pandemic had drained me from doing personal game dev projects, this one just revitalised me in many ways. That's not to say it was perfect. So time to explain some issues:

• Camera: I had spent the last hour trying to figure out how to get the camera to focus in on the randomly generated level, instead of the full screen. Unfortunately time had ran out before I could figure it out, so I had no choice but to leave the camera in its full form. The "Player" mode I thankfully decided to leave as an option, as much as I thought it was a fun camera mode, I could tell it was disorientating for some players.
• The Volume: So when I was working on the music, I had the PC and headphones on full volume, and I thought the volume was perfectly fine. Turns out my headphones aren't as strong as I thought they were, cause players on some streams were taken aback by how loud the music was. I've deamplified the music for the post jam build, but I've also had feedback suggesting not to have full volume by default.
• Menuing: Yeah, I probably could have spent those final hours adding some important stuff to the menus to make it clearer and easier to modify, especially the option to turn off the visual effects that might be an eye strain to some people. In hindsight, I also have a config class that I used in a past game that I could have easily dropped into this game, so saving options would have been a breeze.
• Linux: As much as I work on Windows, I have a soft spot for Linux and major respect to their userbase. I usually have a Linux Mint distro on hand to easily produce a native Linux build of my games, and let users decide whether to download it or not. This time around, I was curious and posted to a Linux games community (shoutout to /r/linux_gaming on Reddit!) to get actual Linux gamers to try it out. Turns out quite a few couldn't get the game to work due to a libcurses dependency, and one of the Twitch streamers that tried the game on Arch Linux (shoutout to @marcmagus) found out his gamepad ran funny with axis inputs when he played the game.

So yeah, there's a lot to deal with. Perhaps in the next update I do to the post build, I should add a long warning for players with senstive eyes and ears before I do anything else. Thanks to everyone for playing, thanks to my friend Kris for helping me with brainstorming ideas and here's hoping to a good ranking!

^^^ Click to Play ^^^

Since this afternoon, we are Top 3 On itch.io (Rogue-Like Category) with our LD47 Jam game, Many people tested it, why not you ;) (And leave a feedback)

https://ldjam.com/events/ludum-dare/47/hackn-loop

I always try to intertwine music with mechanics as much as possible in every game we make, and this case wasn’t an exception. Instead of just making functional music, I wanted to reflect the looping mechanics with that music, in order to give the player more information about the duration of the loops in an indirect way.

The main problem with this idea was every level had different recording times, so every loop would last a different amount depending on the level.

My first approach was to make a specific music for every level whose rhythm fit the loop timing but as soon as I started I realised it was too much work for a jam (there are 12 levels), and the game designer told me he was still working on getting the times right, meaning they could change at any time and I would have had to redo the music. I had to discard that idea.

Finally, I found the solution; split the melody into chords and play them as the loop repeated. In other words, everytime the player loops, the next chord of the piece plays. I had to make it very percussive and minimalist since the timings were very different, so I couldn’t use rhythm-based elements like delays.

https://youtu.be/U2eWwXaz1Es

I also splitted the first loop (i.e. the recording time) into four spaces, so I could play an equidistant four notes melody, in order to give the player a sense of the loop duration.

The music has a very slightly noticeable build up through the levels that I would have loved to develop further, but time was running out and I had to work on sound effects and record some foley, so I ended up with a simple execution of the idea.

Nonetheless, I’m more satisfied with this execution than with just a typical functional background music. If you haven’t played Re-Slash yet, or in case you already played and want to revisit the sound in our game, you can do it below. Thanks for reading!

Play Re-Slash here

If you're reading this on a Friday night, you're already half way there...
Why not check out our little puzzle platformer?

https://ldjam.com/events/ludum-dare/47/loop-frogs

https://ldjam.com/events/ludum-dare/47/loop-frogs

Hello!

I'm looking for short(ish) games that are time based, that you can try to finish as quickly as possible. It would be fun to try them out and see how quickly they can be beat!

For Ludum Dare 47, we ended up making an action roguelike called Limbo Library which we described to ourselves as Minit meets Enter the Gungeon. One of the most programming intensive parts in our development process was implementing the random dungeon generation. We ended up referencing an article about Enter the Gungeon's dungeon generation process and implemented something similar.

The basic idea we started off with was figuring out what the key room types were. We decided there would be normal enemy rooms and elite enemy rooms as the two main types. In addition, within a run players would be able to obtain 2 chests. We also wanted to introduce a permanent upgrade for players to find and rooms that gated player progress on that upgrade. This ended up being a teleportation ability called blink and so we had a blink upgrade and blink required rooms. Finally, we planned on a boss room though a lot of content was cut due to time constraints. Below is an image of how the rooms in a run are all connected.

Each run, the rooms are always connected in this exact way, guaranteeing that you would need to face at least 2 elite rooms on the way to the boss and that you would need to obtain the blink ability as well. Within each room type, we would have some number of handcrafted templates. We ended up with 9 different room templates for our regular enemy rooms and 4 different room templates for our elite enemy rooms. Here is what one of the room templates looks like in the editor:

Each room has 4 possible exits to the top, right, bottom, and left and we manually specified the coordinates of where the exits are in each room so that the dungeon generation algorithm knew how to fill in the hallways. The large blue rectangle pictured above is a collision box that causes the room to activate when a player walks into it. This raises all the doors so a player has to fight all enemies to continue onto the next room. It also tells the enemy objects to activate their attack logic.

I'll write more about how we did the actual geometry in laying out the rooms in a second blog post, but I just wanted to end with a zoomed out picture of the final result, with the room types annotated so that you can see how they correspond to the graph from earlier:

Play Now (HTML5)

When we initially released Donut Island, it had a critical bug that prevented the difficulty from scaling properly. We now released a post-jam version, and it's not as easy ;)

We also took some of the awesome feedback and implemented it into the game.

Think you can beat us in our own game? are you an MLG pro gamer?

Comment a screenshot of your score, and take your place in the hall of eternal glory on our LD page.

@Hardscore

@Odedro987

Which means, it's almost time for some Macarena (at least, that's an attempt...)

👇 It's more than ever time to shine on the dancefloor and give feedback! 👇

https://ldjam.com/events/ludum-dare/47/time-to-dance

THANK YOU KIND PEOPLE

Cheers from savvy community

G̶a̴m̵e̵ ̵l̴i̴n̴k̷ - https://ldjam.com/events/ludum-dare/47/this-house-looks-familiar

https://www.youtube.com/watch?v=oX9KVLGe3CA&ab_channel=Mulholland

https://youtu.be/2Upx39TBc1s?t=10

Here's the link!: https://ldjam.com/events/ludum-dare/47/placeholder-1

This ended up taking 4 extra days to complete! Unfortunately I didn't realise that after publishing my placeholder page I would not be able to switch to "Unfinished". Due to how "smart filter" works it's important you rate the game if you play it, but PLEASE keep in mind that this took 4 days longer than everyone else when giving a score, otherwise it would not be fair to the others who finished on time (and submitted according to the rules...).

Honestly I don't regret taking the extra time as this project deserved to be finished properly. Granted this shows poor scoping on my part, but as I have gained more experience, my ideas become more ambitious.

As much as I love Ludum Dare (my first completed game was an LD) I feel my interest in forcing myself to make tiny unpolished games has waned.

I enjoy using game jams as an opportunity to push through and finish my short story ideas and still absolutely love the community aspect to the event. Playing and rating other games and then in turn having your game played and rated too is still a fantastic buzz. But due to the tedious nature of making short stories in a game engine, finishing under the deadline seems to require much of the planned/desired content be cut.

Maybe next time I'll have to try a mechanics focused project and instead find another outlet for my short stories.

Really looking forward to finally playing people's games! Though you'll excuse me if I take a day off, I'm pretty exhausted...

We will like to give a big ol thank you to all who have played our entry Amusement Shark and we really appreciate the feedback.

We see that it takes about 3 minutes to complete the game. Can anyone finish in under 3 minutes?

Play the game here! https://ldjam.com/events/ludum-dare/47/amusement-shark