We finished our first Ludum Dare game! You control a gripper arm in a factory that loops with rhythm.
It has been really intense 3 days... But we're happy with the outcome. Enjoy the game and leave some feedback!
https://ldjam.com/events/ludum-dare/47/$216771
... to show you some footage of our game.
Play it here: https://ldjam.com/events/ludum-dare/47/grabby-the-ultimate-grabbinator
We made some music videos and uploaded our soundtrack to youtube: https://www.youtube.com/playlist?list=PLeSiYSq7rYXDabA7sfoxMpGodfYmJp5O5
Check it out or play the game first: https://ldjam.com/events/ludum-dare/47/grabby-the-ultimate-grabbinator
After the nice feedback we got from you, we decided to continue working on our project for some time. We started by refining the physics, eliminating some strange wobbeling here and there. Also we implemented bouncing stuff, which is a lot of fun. We are now adding to the story to minimize the confusion of some players in the beginning and including more levels with different challenges.
If you want to play as Grabby before its inernational career as Dirk Grabbitzki, you can do so here: https://ldjam.com/events/ludum-dare/47/grabby-the-ultimate-grabbinator
We still can't quite believe it that you rated us into the top 100 for our first Ludum Dare, thank you! We had a blast developing our game and playing all of your games. Until the next time!
After the last Ludum Dare, we figured it would be better to keep it short this time, and actually finish a game instead of wanting to implement everything. In this spirit, we started late. Brainstorming was chaotic as usual, and we ended up interpreting the topic a little bit... abstractly:
With our small scope we managed to make some progress in the first day, implementing (almost) all core gameplay features, art and music.
What is left now for the second day (our last day) is bugfixing, soundeffects and more visual effects. But most importantly, we have to work on finetuning and balancing the gameplay, which lacks a bit of motivation at the moment.
For this Ludum Dare, we made a rhythm game that's heavily inspired by Crypt of the Necrodancer. It was quite a journey to figure out how to make everything follow the rhythm. But now, almost a week after the end of the jam and after fixing some nasty bugs, I finally feel like I understand what I was actually doing last weekend, and I want to share what I've learned in this little "How to Make a Rhythm Game".
I'm a programmer, not a musician, so I can't tell you how to make a beat, only how to get the beat into the game. Ask your favourite musician to give you a file with the time of every beat in the song (along with the song itself). One way to get file like that is to export the "beat" track as MIDI and then convert it to a JSON file using one of the many free online converters. Then you can load this file into your game engine. The beat of our first song is 90bpm and has a simple 4/4 rhythm, it looks like this in the code:
beat_array[0]=0
beat_array[1]=0.67
beat_array[2]=1.33
beat_array[3]=2
beat_array[4]=2.67
beat_array[5]=3.33
beat_array[6]=4
This approach lets you be super flexible with any beat your musician throws at you. Even if they make some weird polyrhythmic noise, you could easily import it into the game (playing that would be a whole different story though). Here's an example of the slightly more complex beat of our second song:
beat_array[0]=0
beat_array[1]=0.67
beat_array[2]=1.33
beat_array[3]=2
beat_array[4]=2.33
beat_array[5]=2.67
beat_array[6]=3.33
In the code, you can then compare the current position in the song with the beat array to see if a beat has occured and how long it is before the next one.
beat beat
-----0.67s--------------------1.33s-----
| |
| |
In our rhythm game, the player has to give input to the rhythm of the beat. If they manage to hit a beat, they'll move in a direction, but if they don't, they'll lose health. The issue here is, what exactly does it mean to "hit" a beat?
The player will never input at exactly the same time as the beat because they're an imprecise human and the game logic runs in frames, so it'll never detect the beat at exactly the right time. So, you need some kind of buffer time that allows for delayed input:
beat beat
-----0.67s--------------------1.33s-----
| |
| |
------+------ ------+------
input allowed input allowed
| |
| |
The key thing to consider is that this buffer time has to be applied in both directions. The player might hit a key slightly after or before a beat happens. To take this into account, we do the following each time the player gives input:
- check if the time difference to the previous or next beat is smaller than the buffer time
- if yes, check if the beat has already been hit
- if not, mark the beat as hit
- move the player
Now the player can move to the beat, and with the buffer time you also have an easy tool to scale difficulty.
The next thing to do is to get the environment, or enemies, to move to the beat as well, and make them damage the player if they collide. Movement is pretty straightforward: every time a beat occurs, all enemies move. The nice thing about this is that now the whole world can potentially vibe to the beat.
beat beat
-----0.67s---------------------1.33s-----
| |
| |
------+------ ------+------
input allowed input allowed
| |
x x
enemies moving enemies moving
| |
| |
But now it get's a bit trickier. How can you check for a collision with the player? If you do a basic collision check every frame, you're basically undoing the buffer time we added earlier. If the player wanted to move out of the way of an enemy, they would need to move away from it slightly before the beat actually happens. Likewise, if a player wanted to move to a tile where there's an enemy who'll move away next beat, they would have to move slightly after the beat happens. Ultimately, it would make the whole game feel unfair and broken.
You can solve this problem by doing the "movement" and "damaging" of enemies at different times. For example, you can check for collision once exactly between two beats. So, the enemies are moving to the beat, but damaging to the "off-beat".
beat beat
-----0.67s---------------------1.33s-----
| : |
| : |
------+------ : ------+------
input allowed : input allowed
| : |
x : x
enemies moving : enemies moving
| x |
| enemies damaging |
This might look a bit weird, because you can sometimes see the player "glitching" through enemies during the buffer time, but it actually plays way better than with enemies that move and damage at the same time.
You could also check for collisions right after the buffer time is over, but this can cause a problem that I didn't think about during the game jam: What happens when the beats are really close together or the difficulty is so low, that the buffer times of two beats overlap?
``` beat beat -----2.00s-------------2.33s----- | | | | ------+-----------------+-------- input allowed input allowed | | x x enemies moving enemies moving | |
``` If you've just set it up so that the enemies are doing damage at the end of the buffer time, you're now hurting the player during the buffer time of the next beat. This might not sound that serious, but it can actually break the game if you remove too much of the buffer time for the next beat. Just play the jam version of our game on the "basically cheating" difficulty. The enemies are damaging so late, it can feel like they have a hitbox lagging behind them. It can make the game a lot harder, because you have to hit every beat just so slightly too late.
So, the most important thing I've learned from making our rhythm game is that you can't just focus on one beat. You've always got to check the timing between the last and next beat.
If you want to try our game, and give us some feedback on how we implemented the rhythm or anything else, you can do so here: https://ldjam.com/events/ludum-dare/59/cableman-a-rhythm-game
We got a simple enemy AI working for our strategy game. Sometimes the AI doesn't make the best move it should. But of course this is intentional to make the AI more humanlike, and not at all because I can't find the bug in my 20 nested if conditions.
We just uploaded the final version of our game just in time, time to celebrate!
Check out our turn-based "chess-like" strategy game here: https://ldjam.com/events/ludum-dare/56/cyber-critter
We created a rhythm game for this jam, which was a new experience for me. You need to take into account the possibility that the player might press a button either milliseconds too late or too early, which raises all sorts of weird issues.
It also did not help that I accidentally had "Windows Sonic" activated for the first 65 hours of the jam, which made the music sound really horrible...
But the game is finished now, and I am quite happy with it. Feel free to play and rate it if you are interested in our "Necrodancer-like" :)
https://ldjam.com/events/ludum-dare/59/cableman-a-rhythm-game
They don't appear in my profile feed, only very old drafts and published posts...
The end of the voting period is approaching. Here in Europe, people are enjoying the first summer weekend of the year. However, there is still an important task to complete: vote for the games that have not yet reached 20!
To give you some inspiration, here are three games with a rather unusual approach that I think deserve more attention.
Fission Quest: A point&click adventure with live-action footage.
I HAVE NO BRAKES AND I MUST VROOM: A game that you control using your voice.
Exegenesis: A complete tabletop RPG.
Feel free to share some other interesting games that are missing votes in the comments!
First of all - thank you so much for your nice feedback and even voting us in the top 10 for Audio and Fun! This is by far the best result we ever got!
We've been pretty busy over the last two weeks because we wanted to get some things done before the results went live. We've reworked some visuals, added new features and remixed the music to create an announcement trailer that tells you we'll continue working on our game and publish it on Steam:
https://www.youtube.com/watch?v=53RpqETmaTw
We are really excited! This is our first time going for an actual Steam release. And now that we see how highly you rated our game, it motivates us even more! We had planned to share the link to our Steam page with this announcement, but it's not ready yet... our plan was a bit tight, and the review process is taking a bit longer than we thought.
If you enjoyed our game and would like to play more of it, we would appreciate it if you could stick around and add the game to your wishlist, we will post again when the page is ready next week. Also, if you have some experience or tips for publishing, we will be happy to hear them (apart from "Don't set up your Steam page 4 days before the planned announcement date." and "Double check your logo and hero for transparency.", we know that now lol).
And of course, if you haven't played our game yet, you can check it out here.
With a bit of delay, our steam page is finally public and waiting for some wishlists :D
We had hoped to get it online by the end of last week and share it here when the ratings were released. That didn't work out, but now we get to share it when the ratings disappear, I guess that's also worth something...
Thank you all again for the nice gamejam, we really had fun! Your positive feedback really motivated us to continue working on our game, we never expected to reach the top 10!
See you all in October for Ludum Dare 60, or over on Steam :)
https://www.youtube.com/watch?v=53RpqETmaTw