Other Games

My second Ludum Dare has come to an end, and it's time to reflect on the process & the results. I had a delightful time playing a lot of great games - my stats say I tried out about 88 of them! - and added some new favourites on my itch.io. Here are some of the best ones I played:

1. The CUTEST one: https://ldjam.com/events/ludum-dare/54/packed-to-the-gills

2. The best take on and old classic I ever saw, and best AUDIO for me: https://ldjam.com/events/ludum-dare/54/cyber-serpent

3. A pixel adventure for a COZY experience: https://ldjam.com/events/ludum-dare/54/homeward

4. Really fun little game with CANDIES: https://ldjam.com/events/ludum-dare/54/candy-catcher

5. A BOARD game I printed out and had fun playing: https://ldjam.com/events/ludum-dare/54/packing-for-dracobeach-the-limited-space-conundrum

6. A cozy game with the most adorable bird and HOME DESIGN: https://ldjam.com/events/ludum-dare/54/leaving-the-nest

7. Most interesting take on the THEME for me: https://ldjam.com/events/ludum-dare/54/homeonaut

8. Mechanic I enjoyed the MOST: https://ldjam.com/events/ludum-dare/54/under-the-spot

Process

~ I learned Twine for this Jam, and didn't have time to even check it out before. So the Jam started, I decided to use Twine and downloaded the latest version. While learning how to use it, I realized it's not the best choice for me as I want to add a TON of pictures. I switched to version 1.4.2 and spent my remaining time on learning the engine, working out the plot&world, drawing pictures and CGs for the endings, writing the text, developing mini-games and bonuses, working on the game page, etc.

Proudest moments + I am most proud of my "construct a poem" mini-game. I am not really a programmer, so making it work with pretty simple code and realizing it has 256 possible combinations made me incredibly happy <3 + In my opinion, I did grow a lot as an artist since my last LD jam, and I am pretty happy with the drawings I did in that limited amount of time. + I made music myself in BeepBox, even though I have no ear for music, and it was mostly received well (it was said to be repetitive, but nobody said it was horrible to listen to xD) + My main category, MOOD, has seen an improvement in ratings: + I received a lot of great feedback and even the CUTEST fanart from one of the jammers!!!

by https://ldjam.com/users/fupi

Room for improvement + It seems I have created expectation for more branching in the story by implementing six endings, when my initial idea was to create a more unique and personal playthrough for the player to experience & enjoy without trying to go in for the second round. I definitely have to keep it in mind if I work on a multiple-endings-game again! + More experience in coding will allow me to create more memorable gameplay and more interesting UI - that is definitely one of the goals for the next time. + Art definitely has to keep developing, I am aiming for higher marks on my art for sure, but there are still ways to go! >v< + Keep working on Mood as my best category!!! (I wish there was one for Writing/Story/Worldbuilding but ig that's all going in mood?)

Plans for next jam

I am going to continue making games, learning new engines and programming languages, as well as developing my art skills. My next project is a Yuri Visual Novel for https://itch.io/jam/yuri-game-jam-2023 and I've already started working on it!

Wow secret is out I made an Undertale boss fight

If you somehow managed to not get spoiled about it from all the streams and stuff, yeah is an Undertale bossfight

Its quite hard and inspired by the harderst boss in Undertale, so thats your difficulty warning on that.

If it sounds like your type of thing yeah do give it a go even if the jam is over, I think is quite good

https://ldjam.com/events/ludum-dare/54/a-pawfect-date-pomos-cozy-romance

Hi all! We would like to express our deep gratitude to those who appreciated our game. We are very pleased with the result. This was our first experience at ludum Dare. Thanks to all(:

P.S. Our game ^_^ https://ldjam.com/events/ludum-dare/54/moksha

To begin with, I've never made a sequel to any of my Ludum Dare games before. I mentioned to some friends at the start of the 48 hours that I'd be making a sequel to Ribbon, my LD47 entry, and I was warned that making a sequel might not be the best idea. Ribbon was my first game to earn a trophy (2nd place in innovation) and a lot of people started following my LD games because of Ribbon. It's a game with a legacy, and if I were to completely fumble the sequel I'd be tarnishing that legacy. So the stakes were high this Ludum Dare... let's see talk about how it turned out. This is my postmortem for Ribbon 2!

I like to take notes for next time in these postmortems, so let's review what I wrote after my previous LD game. "I think I need to focus on simply making the game more intuitive" and "...(in the future, I should be) getting feedback before the deadline, and testing a build of the game frequently during development". Those were the big takeaways, but I also had some other goals. Here's the bullet points we'll talk about in greater detail:

• Live up to the quality of the original game
• Intuitiveness and address feedback before the deadline
• Notes from prior LD games
• Add an acapella track
• Smooth sailing into submission hour
• Holding the wrong hands

To begin with:

Live up to the quality of the original game

First things first, I'm not going to just re-use the old game's code. It was incredibly messy and it barely worked. To make the ribbon rotate around in the original, I had a series of 128 nested rectangles that all rotate slightly. gross.

I wanted to "do it right" which meant constructing a single mesh that bends and curves.

Furthermore, I had some ideas cooking for this sequel that the original game couldn't do at all. I had plans for the player leaving the ribbon and running around in a 3D space. The original game is a 2D game, that can steer around a 3D space, but since the Y axis isn't really used, it loops back around to being 2D again. For the sequel, I want you to be able to jump, and you need to drag the ribbon along in the Y axis too!

To make a long story short, the core idea I came up with to separate this game form the original and expand on the concept was entering/exiting the ribbon, and ribbon customization. Entering/Exiting allowed for some fun puzzles with buttons and doors, and the ribbon customization would showcase how I could expand this game in the future. With those features combined, I think it would be even better than the original, thus living up to the expectations of the sequel.

Intuitiveness and address feedback before the deadline

This was the key point of failure with my previous LD game. As a recap, in level 3 of "Inbox Fool" the player needs to toss a bomb at a magic tile, and the bomb needs to make contact while the player is at the apex of their jump. This was NOT explained, and it made level 3 (which is supposed to be an introductory level) way harder than I thought it would be. The difficulty curve was ruined.

To prevent that in Ribbon 2, I needed to hold the player's hand as much as possible, but hopefully not to a degree that ruins the puzzles. The puzzles in "level 1" involve buttons and doors, and while I assumed the puzzles were super easy, just in case the player forgets to use the core mechanic of re-entering the ribbon, I added a textbox that reads "You can press shift to re-enter the ribbon" if the player has walked around for 45 seconds without doing that yet.

Something I learned last Ludum Dare was to build the game and test it in a built state frequently during development. To my surprise, the shader I created to make the trees sway in the wind was completely broken in the built game (but not the editor)!

I simply decided to remove the shader (after putting in way too much time to fix it).

with about 6 hours remaining, despite the game not being done yet, I gave a build to my roommates. Watching my roommates play the game revealed something I thought was intuitive, but wasn't! One of my roommates struggled while customizing the ribbon, despite the text "Click on the ribbon", they were clicking on basically everything except the ribbon. The solution: Add a text box that says "The ribbon" with arrows pointing to the ribbon. easy fix!

What I later found out post-submission was that one of the bonus spools, which required jumping into the bouncy ribbon, was harder to collect that I initially though. If you let go of the jump button before the apex of your jump, you intentionally lose a lot of momentum. this allows for "short-hopping" but this also completely destroys the momentum needed to reach the bonus spool. Whoops! I guess I still have much to learn about explaining mechanics to the players.

Notes from prior LD games

Previously, I've made the decision to focus the gameplay on a single mechanic and worry about the story (if any) later. In complete contrast to that note, I felt like the game was lacking while designing level 2. I couldn't just make every puzzle have the same solution of "go here, enter ribbon, viola!" so I made some mini-games. The shape tracing game felt like a great use for the ribbon, though issues arose with the other ideas. The other spools, namely the "hidden box" and "chase game" spools could exist in any game, whether there was a ribbon or not. All the cool ideas I had were way out of scope, but I'm still glad I was able to add something to fill the space.

Add an acapella track

Ohhhh boy I was burning out, and I honestly considered not making one this time. For those unaware, my previous 3 LD games had an acapella track in them, and as much as I didn't want to break the streak, I didn't know where to put it. This game has, for the most part, taken itself very seriously as a sequel to Ribbon. As I pieced together what the bonus ribbon would be (for collecting 100% of the spools) I decided, "hey- I can make the music inside the bonus ribbon acapella. why not? I got time and energy." So I did.

I added a bunch of other fun acapella noises, like clicks and pops, but also a fun noise you can make when humming the letter 'v' in a falsetto. My roommates think the humming-the-letter-'v'-in-a-falsetto thing is super weird, but it's a fun noise to make, and I didn't add it in the previous game's boss fight music, so I had to put it in this game!

And that was the final addition to this game! Once the acapella track was in (and volume controls to only play it when inside the bonus ribbon) I was ready to build the game and submit, with about 20 minutes to spare until submission hour.

It was certainly a less ambitious acapella song than last time, but hey- I was burnt out and had less than an hour.

Smooth sailing into submission hour

If you read my postmortem for "Inbox Fool" you may recall this section was named "OH NOOO!" because, like always, I encounter some form of last-minute panic. For Inbox Fool, the shaders in the built game were breaking which required making serious changes to the camera / calculating the mouse position.

This time around, I built frequently during development. I encountered the trees being bad super early, (tried to fix it for about an hour and a half) and removed that shader.

I had about 20 minutes to spare, and I didn't know what I could do with the time, so I took some screenshots for my LD game page, and got it set up.

It was very bizarre having the game page ready at the start of submission hour instead of the last-minute-panic at the end that I usually experience, and I definitely believe it's because I built frequently during development and fixed minor things along the way instead of unknowingly letting them build up.

And with those bullet points out of the way...

Holding the wrong hands

Despite how much I tried to hold the hands of the players, there were a few comments stating that they didn't reach the end of the game for various reasons. One player forgot about the ribbon customization menu. This could've easily been fixed if I made the "you unlocked a new spool, press the Q button" text appear after unlocking the second unlockable ribbon, though I honestly assumed everyone would've played around with the customization a few times before reaching that point. Perhaps I didn't showcase the customization with as much importance as I should have. Again, notes for next time: remind players of required features if there's a gap in using them, and make sure players understand everything about them. Perhaps I need better explanations when introducing those features?

One issue that was brought up a lot was the camera. People wanted to be able to fully rotate the camera even though everything was desgined to be viewed from the front. The idea I had for camera rotating would be to simply add some curves to the ribbon and step inside, though perhaps once again my ideas are far from intuitive.

Speaking of the camera, I had an invisible wall in my game (in the form of a fence, with a realllly tall hitbox) that players were trying to get over. The entire reason it exists was to give the camera space so it didn't need to clip into a wall, but I still needed a boundary to prevent the player from going there. Anyway, yeah- people tried climbing over the fence, and even asked in their comments if they missed something that was over there. Perhaps I should just write "This fence exists to give the camera some space." on the floor next time, ha! The other invisible wall in my game had a neat effect where the floors, walls, and decorations were all greyscale beyond a certain point. Perhaps I should've re-used that as a motif instead of a fence.

Speaking of the camera... again... My code for following the player when inside the ribbon had a slight malfunction when the ribbon is at a sharp turn. A single line of code would've fixed it, but the camera would zoom real close to the ribbon, making the player impossible to see.

And I had one player who completely didn't understand the game at all. They left very little feedback, but from the sounds of it they couldn't solve the tutorial, got frustrated, and gave up. I honestly don't know what to take from that, as every other comment at least made it to the second stage. Reading that comment hurt. I'm still struggling to make my games intuitive. I don't know... I'm afraid this will lead to me over-explaining everything in the future, removing any chance of an "Ah-ha! moment" for any puzzles.

Reflection

So- now that the game is done, did I live up to the hype? Was Ribbon 2 better than the original? I'd say absolutely.

It's been 3 years since the first Ribbon game and in that time, though I may not immediately realize it, I have grown tremendously as a game developer. The problems I had to solve while developing this game seemed to be minor issues instead of taking most of the weekend. Were there issues? Well sure- I scoped insanely large as always. The camera in this game wasn't great, though that's partially just due to letting the player orient the ribbon in any way, and trying to make the camera follow the player inside it is... difficult to say the least.

Of course, it wouldn't be Ludum Dare if I didn't learn anything for next time, and one of the big takeaways from this one was a lack of Key-Rebinding. A friend of mine played the game on Twitch, and I was unaware they were left handed, which complicated playing the game. To my surprise, nobody has ever made such a comment to me. I never even considered how WASD + Spacebar was such an issue for the left-handed, and again, how has nobody informed me of this in 23 ludum dares?! Furthermore, I've come to realize QWERTY isn't the default everywhere, and WASD isn't always convenient. You live and you learn! You bet my next LD game will have button remapping.

I'm still figuring out "intuitiveness" after my 23rd Ludum Dare, and I think I need to really take the time to figure out why. And now we get to talk about the real puzzles of the game... I thought the "Very high jump" bonus spool was a clever use of the bounce ribbon, other's never figured it out. Some people found some very interesting uses for the entering/exiting ribbon mechanic with my generous "Coyote Time" as a means to collect that spool, and hey- the more solutions there are the better. That being said, I wanted there to be puzzles, I have to stop holding the player's hand at some point, but I still haven't figured out the perfect balance.

Results

11th Overall.

Moving on...

Conclusion

This game was a bit different from my previous few entries. I usually add humor all throughout my games, while Ribbon 2 only had a single joke at the very end. (I still scored 12th in humor though!) Take my previous LD game for instance, where every level had at least one bad joke in it as the villain taunts you through a TV screen. The game before that, The Bountiful, had a psychopathic crow giving you bad advice, then "Watch out" had a talking pocketwatch to make bad jokes, "Block or Bust"... well the core gameplay loop of that game is humorous.

I think I was too excited to make Ribbon 2 that I focused on the wrong things. My game has so many details that barely anyone would see, yet lacked general polish on the game's camera. I shouldn't care how smooth the camera movements are, if the camera is moving to inconvenient places! I think that's what affected my score the most.

So what's the big "Note for next time" that I'm taking from this LD? I feel like I've brought up a lot, from the lack of key rebinding, to the unintuitiveness, to the jank camera. I think the biggest note to reflect on is to figure out where to polish. This game had polish, sure, but I think it was in all the wrong places.

Don't get me wrong, I'm still very happy with the game I made. I still think it's one of, if not my best game jam game yet (despite the ratings). In my "Postmortem for 20 Ludum Dares" post, where I covered my first 20 LD games, I mentioned around LD38 through LD42 that my games were getting more ambitious, but they were poorly explained. I'm seeing the trend repeat, and I'm going to be focusing on making better introductory levels in the future.

I don't know if I'll make more sequels in future Ludum Dares, but I'm glad I got to make some of the ideas I've had for this one. That being said, I really like the dynamic I had in Inbox Fool with a foolish villain... I think I could get away with more foolish villains and not call it a sequel. We'll see.

☃

We tried our best to deliver a small game, and it seems we managed to do it. See you next time!

Thought it would be fun to highlight some of the approaches I took to create the graphics for the post-compo version of my entry, Super Drillboy!

Color Palette

I chose to use a limited color palette that was heavily inspired by the indie game Zero Ranger. The limited choice of colors made it way easier for me to create pixel art and backgrounds. Knowing what color to use was made pretty obvious and I didn't get paralyzed by having way too many colors to choose from when making the art. This also lent itself to having a very consistent and cohesive look.

Parallax Backgrounds

I spent a decent amount of time creating these infinitely scrolling background layers. Each one scrolls at a specified speed proportional to the player's vertical velocity. I think they add some real depth, motion, complexity, and life to the scenes while playing.

Decorative Objects

Decorative Objects are objects that are instantiated when the player reaches a multiple of a specified depth and scroll upwards in relation to the player's downward velocity similar to the backgrounds. They are spawned on top of the background and not actually part of the backgrounds themselves. This allowed for more randomness and variation.

Level Generation

My approach for procedurally generated content was to hand-create a bunch of mapSections of varying lengths. Each mapSection contained a certain configuration of blocks. The level generator randomly selects a piece and strings it underneath the previous one. Hitting a checkpoint triggers generation of a new section and deletion of an old one.

Blocks

In Super Drillboy, there are 4 types of blocks:

Solid: Only breakable when you have a boost.

Destructible: Breakable by drilling.

Damage: Deal damage to the player if they land on them. Breakable with a boost.

Walls: Never breakable. Dynamically generated when the map section is created. Distance between walls changes during play.

I used Unity's ScriptableObject class to create a LevelTheme for each level. The LevelTheme contains the level name, all three parallax background layers, a reference to the music, and all the sprite variants for the four block types. When a section of the map is generated, the current level's LevelTheme is applied to the blocks and backgrounds, swapping out the aesthetic.

Conclusion

I had an absolute blast working on this game and continue to develop it further. With that in mind, I would love to hear any more feedback that anyone has to offer about the game. Please give it a play if you haven't already and I'd appreciate any and all comments. Thanks for reading and playing, and see you in April for LD55!

Play Here

Please Leave Any Feedback Here

https://ldjam.com/events/ludum-dare/54/dont-squash-the-unicorn

7th place in innovation. It's not bad, isn't it? Because window resizing exists.

It's been a long time since I wanted to make a game relying on it. When the theme "Limited space" dropped, I had to do it. Of course, people would say it's not made for it, and at first I was afraid I couldn't do it, that refresh times would be too slow, but I think it worked out well.

At least, as well as it turned out to be. My plan for the weekend was very straightforward: do all the code Satursday, and the rest (including testing and adding cool things) Sunday. Post for Compo and profit.

Instead, I was still cramming essential sprites Monday afternoon. My workflow was terrible and my code a mess. Well, at least I submitted on time!

There is room for improvement... notably how I review other games. (I mean, Ludum Dare has this social aspect.)

By the way, I'm sorry for the long reviews I promised and didn't write (I would like to say I would do them, eventually, but I can't really promise it. I bit more than I could chew). I know how to be more efficient next time.

Oh, and I don't know if any player noticed it... but you can win this game. By killing no one (and you can lose by killing your manager during his speech). This is why I didn't think of a score system.

I already talked about my post-jam updates about the game so let's cut to me for once, I have gone into this game jam thinking I will be quite a bit on the end tail of the swarm, first ever actually finished game, in an unfamiliar engine, in 3D, which I barely used especially when your company builds on 2D games, so getting overall a 3/5 with a ton of comments saying things were good, pointing out issues and such really just made me go "hmm so that's how it works" I realized that the term: "it could've been better" just fell flat to me... like why could've been? It still can be better! so to me this jam was sort of an awakening, like when you see other motivated game devs clash ideas and share insights, you also start to feel this motivation, seeing people show up, say something, or me showing up on their game's comment section sometimes giving insight they are grateful for, I think that was the highlight... So afterall to really summarize the game jam in a few words for me...

NarrowLabs walked... so Nucleon can run...

After 9 years of Ludum Dare, this was my first game jam not done from the exact same location. In the last few months, I started college, and have moved into a dorm with all the adjustment that came with that. I like to think I adapted, but hey, a new normal I suppose. And hey, the game still got made (despite the many hurdles this post-mortem is focused on).

Brainstorming

Shrimpwrecked! is one of the most fully cohesive concepts I've ever come up with for Ludum Dare, but this came at a pretty high price. When the theme was announced, I was fully defeated. I've been doing this thing for a while now, and "Limited space" just didn't give me much to work with outside of continually linking me back to LD42's "Running out of space". I spent right around 3 hours just utterly stuck with literally no leads to go off of. I had a couple ideas, but either the scope was too big or I just knew that it wouldn't end up being fun. 3 hours might not seem terrible for some people, but it is by far the longest I've ever gone in a game jam without any semblance of direction. Right off the bat, I was already frustrated and behind, and I get the feeling that this affected my overall performance during the remainder of the weekend more than I would've like.

Productivity

I was extremely inefficient with my time during the entire course of the jam. The concept, although definitely not simple, wasn't nearly as complex as the time each element took would lead you to believe. I think this was partially a symptom of the new environment. It wasn't that I wasn't focused, but moreso that I just was not getting things done as quickly as I know I could've. It's hard to explain, but I know that I felt it in one way or another. However, this is mostly a symptom of...

Scope

I've gotten much, much better about scoping jam games as I've done more of them, but this one got away from me. If you're at all familiar with Ludum Dare 53's Stork Serenity (currently being further developed!), you'd know that that was my smallest scoped game I've ever done, and it was frankly better off for it. With the gameplay so limited, I had the time and energy to really focus on the little things and make it by far my most polished experience to date. Now contrast this with Shrimpwrecked. While it certainly isn't one of my most overscoped games (Ethereal Exchange and Planet Vesta say hi), it was just a bit more than I could handle.

As I realized once I started working on it, the minigame "levels" present in each bigger level could have basically been a full game on their own, and I had all the extra wrapper of the bigger game around it as well. The currency system, the shop, the overworld, etc, all took about as much time as I had anticipated, but the minigame system ate up basically the entirety of my Saturday. Something needed to budge, but nothing ended up doing so, and the final game felt that blow. Polish was sacrificed for a couple extra frankly half-baked systems, and doing it over again I don't think I would have made those same sacrifices.

Atmosphere

Again comparing this to Stork Serenity (which I'll do several more times), the atmosphere was something that I really wanted to nail. Stork Serenity's atmosphere was the defining element of that game, and was what took it from a simple sokoban-style puzzler to a legitimately enjoyable experience. And again, I had time to do these things because the game itself got out of the way and let me work on it. Shrimpwrecked's atmosphere was not... bad, but it definitely didn't end up being as captivating as I was hoping. Scavenging shipwrecks for treasure at the bottom of the ocean is a great pitch for a setting, but without all the elements to really tie it together it can fall short.

Overall I did actually like how the atmosphere turned out, but it still feels like it's missing that extra punch of mood that would have set it over the edge. The god rays, background, particle effects, music, all contributed to this, but it didn't necessarily feel connected to the gameplay. This seems to just be a me thing, since all of the comments seemed to universally like the aesthetics and setting I created, but it still stands out to me as a thing I can improve on. It especially hurts knowing that I did really nail it in the past, and fell short on a second attempt.

The Starting Location

This is the big one that I'm still so upset at myself for. If you've played the game, you're almost certainly aware of some of the particular quirks of the level generation. Each minigame is randomly generated, so they're different every time you play. I stand by this decision, and I'm generally happy with how it turned out, but one particular issue became basically the sole critique mentioned by almost everyone who left a comment. When starting a minigame, there's a decently high chance that there will just be an enemy spawned directly under the player, and without inhuman reaction time you will instantly die.

There were so many solutions to this, be it better generation, altered enemy bounds, or any number of other things. However, the simplest solution would have just been to leave the starting location alone. As I was wrapping up my game and preparing to export during submission hour, I took the player character in the minigame screen, and moved it down one extra tile to start the level lower on the screen. This was an aesthetic choice, as I didn't love how it looked higher up at the start, and it especially bothered me on the tutorial screen where the player is static. However, this ended up being the biggest mistake of the entire jam. This extra tile was the entire cause of the big complaint, and I didn't think to test it because I had been playing the game the whole time with no issues. It didn't even cross my mind that I had completely designed the level generation around that position, and as such totally threw off the game balance with seemingly such a small change.

Results and Conclusion

I'm overall pretty happy with how this game turned out, despite the many many flaws I pointed out in the prior thousand words or so. Going in my goal was top 150 overall, and I achieved that. I actually added some humor in the form of the shopkeeper's dialogue lines, and placed in top 100 for that, and had by far my highest fun score ever. I struggled in innovation and theme, and had a distinct downgrade from Stork Serenity in terms of graphics, audio, and mood, but I'm aware of it and know how to fix it in the future. Honestly, this was one of the most fun jams I've ever done and I'm very excited for April. In combination, my last 2 jam entries have been by far my best set of scores, and it feels good to finally have genuine improvement happening. Hopefully I can combine the best of both games for LD54, and I'll see you all again when the time comes.

Because a picture is worth a thousand words and a video is worth a thousand pictures, I present to you a gameplay video of my game: https://www.youtube.com/watch?v=cyeIWMfirn4

I recently released "Foxcrate" to Steam, which was an update to our LD53 entry of the same name. Since then, I've updated a few times to fix bugs and add a new playable character (Noelle), with more updates along the way. I'm still having trouble getting the game noticed, although it's up to three reviews (all of which have been positive). If you take a look and it seems interesting, please consider playing it and leaving a review to help support further updates. :)

I love ludum dare!

• This time I decided to completely ignore the theme and make a visual novel about the destruction of culture - originally meant for the Folklore theme.
• Used my prep time very well, def more important than I realized.
• Chose the very risky path of making a game with no good ending, some people were really into it, others felt confused and irritated. The diversity of responses from players made the experiment very worth it!
• Despite not having an artist this time, and fully running out of time to make anything more than scribbles, people really fell in love with the characters and the world which was a nice surprise!
• I wanna try even more risky things in future jams so watch out!! I'm coming to get you !!!!

Once again talked to so many awesome people and played great games that I'm gonna remember forever. Thank you to all who played my game, and the entire LD community for making this the wholesome place we all cherish, and also the important space for growth we need as developers and as people. If you're reading this, you're beautiful and I love you! :love_letter:

My original plan was to make a game for the Compo format. I have participated in a some game jams a few years ago and I had always used Unity. Now I have my own game engine that I use for my tech demo projects, but for this Ludum Dare I decided to go with Godot 4.

When the "Limited Space" theme was revealed at midnight I began brainstorming.

My first idea was giving the theme a philosophical twist and making something out of the Augustinian theodicy: privatio boni, "evil is the absence of good" or "evil is nothing". I was thinking about the metaphore that a hole in a sock is not some kind of evil dark lord sitting where the hole is but the absence of sock. I thought about making a game where the lack of space is imaginary and the player had to figure that out.

This first idea went nowhere quickly, so I started thinking about doing something simpler. Then I had the idea of making a firework game where the player had a payload that can fit a limited amount of timed explosives (this is the part that fits the theme) and the goal would be to reach the end of a vertical labyrinth, and there would be different types of timed explosives. I had already practiced the physics part of this idea from Ian Millington's Game Physics Engine Development: How to Build a Robust Commercial-Grade Physics Engine for your Game book, which has example implementation code and a few exercises on fireworks, and it would be even simpler in Godot, since I don't have to implement all the physics engine code, all I had to do is apply impulses to the payload's rigid body. The reason I chose to use impulses and not forces is because I believe that impulses are more stable than forces in terms of simulation in a frame-by-frame based engine like Godot. In no time I had a working implementation of the physics part.

Now it was time to design how the player would arrange the explosives.

In the end I decided to split the timed explosives into explosives and fuses. The explosives would determine the impulse of the propulsion and the fuses would determine the delay until the next explosive in the sequence is detonated. The direction of the propulsion would be determined by the exhaust pipe the explosive came from. The player would place the explosives in the exhaust pipes, set an initial ignition fuse on one of the three exhaust pipes and then wire all the explosives together in the desired order with the desired fuses, each fuse would have its own delay.

By the time I came up with the design of the core mechanic it was already near the deadline for the Compo, so I changed plans and went for the Jam. I then realized I completely underestimated the complexity of implementing the wiring UI. The deadline for the Jam was nearing and I had only implemented the placement of the explosives and of the ignition fuses, but I couldn't figure out how to implement the dragging of the fuse wires. I was thinking about giving up on the game jam, but ultimately decided to try to aim for the Extra format deadline. In the end, I would be working on the wiring UI all the way until the Extra format deadline (disclaimer: I wasn't working on the game all day every day, but only a few hours per day).

I didn't have much experience with Godot, so what I ended up doing for the wiring UI was to manually write the code that decides how the wire tiles can be combined given a path. I was also going to implement a Dijkstra algorithm manually to have the wire follow the cursor, but thankfully I found out about Godot's AStarGrid2D class, which saved a lot of work. The only issue I ran into was that since AStarGrid2D was always computing the best path, the first explosives were always connected with a wire that went around near the center of the payload, thus not leaving any space to wire the next explosives. I came up with a simple workaround to this issue by implementing anchor points that the player could set while dragging the wires, so that the wire's path would always pass through the anchor points. In terms of AStarGrid2D, this means that now instead of computing a single path from the explosive's port to the cursor it computed multiple paths: from the origin to the first anchor point, then from anchor point and so on, and finally from the last anchor point to the cursor or the target explosive's port, and in the end all those paths would be combined into a single path for the wire. With this, the game was pretty much done.

Canceled stuff

I wanted to release an Android version of this game but ran into issues with the UI scale so I decided not to release it. I also wanted to make more levels but it would take time to calibrate them, so I only ended up releasing the game with one level.

Eye and ear candy for the explosions

With a few hours to spare and not considering worth it to invest them in level design, I added a particle emitter to the payload's rigid body that would emit particle in the direction opposite of the propulsion. I also recorded myself crushing a plastic bottle with the phone's recorder app, sped it up twice and used that as a sound effect for the explosion.

Music

Earlier this year I took up learning music theory seriously and finished Michael Miller's Music Theory book. I'm surprised how much easier it has become for me to quickly write a decent sounding song after learning music theory. I managed to compose a six measure long song in about half an hour. In the game it is a short loop that repeats over and over, but I don't find it too unpleasant to listen to even if it repeats. I think that this is because the song's notes are long and spread out. After analyzing it, I can say that it features a puzzle solving/focus mood, that it's written in the D Dorian scale, has a I-IV-V-ii-V-I chord progression for harmony, and is embellished with claps for percussion. This speaks to me that writing music really is more about following the rules of music than placing random notes like I used to.

Results

I submitted my entry very late and didn't have the time to rate and give feedback to many games, so I didn't get a score but I got some feedback. Thanks again to those who played my game and gave feedback. On a side note, I also want to thank my roommate, who was the first to play the game, for completely breaking the game and discovering mechanics I don't remember implementing. :laughing:

Usability issues

• Players having trouble figuring out how to lay fuse wires
• Players having trouble selecting the explosive port to start dragging a wire
• Players not knowing that each explosive only accepts one input and one output
• The editing interface is conterintuitive and setting the editing mode right requires too many clicks (can't edit fuses or wires without having selected a fuse or a wire in the palette even if pencil or eraser are selected, especially if the eraser is selected it shouldn't matter)

Technical issues

• Wire laying can bug out and crash the game
• The physics simulation is inconsistent, the same payload arrangement can result in different movements of the payload
• It seems that Godot doesn't have continuous collision detection, so it is possible for the payload to go through walls using the most powerful explosive and complete the level that way

Time spent

I kept track of how many hours I spent on making the game, but not too much in detail, especially during the implementation of the wire dragging UI. In total, I spent around 60 hours on making this game, most of it implementing the wire dragging UI. I spent 01:40 brainstorming and 02:25 implementing the physics part. I think I only spent about an hour on the music and sound effects. The tiles of the tileset for the game were made as I needed to implement their specific part in the game.

LDJam 54 was exhaustive. I slept little, neglected my wife and dog and my stress levels were elevated for 3 whole days. Other than that it went great. I recorded a video with some tips to set me up for success next time around. I would love to hear your opinion about these points and hopefully get some feedback on how to fit the game jam into rest of life.

YT video - How to have a successful Game Jam

My Entry into Ludum Dare 51, Impact-Effect, did very well, and I am working to create a fully realized version of the game on Steam!

Check out the trailer! https://www.youtube.com/watch?v=SGdrV1jRQS0

If you like what you see, any support would be amazing!!!

https://store.steampowered.com/app/2611750/Cosmic_Cursor/

Hello all,

First of all, the whole team behind ColorSpace would like to thank you all for your constructive feedback and kind words!

We spent a lot of efforts and time on this game, and reading your comments was really rewarding. Even more rewarding was the final result. We managed to land an outstanding 81st place overall, and 46th place for graphics ! We did not think this possible, and I personally was jumping around for a solid 10mins ! We already knew that we were going to keep working on the game, because we really liked the Game Design we came up with (and being currently unemployed, we had time to spare)... But these results, they gave us the moral boost to keep aiming for higher ! So thank you all again !

We are currently in the process of creating our own GameStudios, of which ColorSpace might just be the first game we will attempt to fully release sometime in the near future (baby steps). We will also streamline our team processes, and show some love to older games that also had some improvements potential.

In the meantime, we published ColorSpace under our new studio name, on itch.io. Feel free to go try the post Jam version there! We will be constantly updating the game until we feel ready for a full release... On Steam maybe ? Who knows where the path will lead us !

Thank you for playing and rating another silly game about cats

I'm very pleased with these results and couldn't have asked for more. There were so many amazing games this round and I'm grateful I could play many of them. Even though this round had fewer participants than normal, the quality of the games and the closeness of the community always makes my heart swell. Until next time <3

I will be streaming for the next couple of hours on https://www.twitch.tv/vorceshard. Comment in the chat or here if you want me to play your game jam entry and give live feedback!

So I apparently got into the Top 100 with Laser Grid? I just discovered it today, as I was honestly pretty checked out for this jam. So perhaps you can imagine my surprise when I discovered this.

The context

Laser Grid is probably the game I poured the least effort in, mostly due to my increasingly chaotic schedule this month. My uni semester was starting, I had two different events to plan out, and overall, I was just stressed. My internet even went out mid-jam, to complicate things further.

At first, during the planning phase, I considered making a concept-heavy, emotionally-driven game. Even though my friends also wanted to participate, this time I wanted to go alone. The stress was taking a toll... so what better to do than to transform my suffering into art?

Slowly though, I realized that my best shot at this was trying out something simple. I had this image on my head of a fast-paced puzzle game, something that I could chew on to distract me from my problems. With a cyber-pixel theme, I could work on both the art and the music myself, as well. Everything aligned itself for me to eventually decide to go for Compo.

The process

The game was finished in less than a day. I iterated on the design a bit, but didn't deviate much from the original premise. Surprised with the lack of fucked up bugs, I was then able to focus on polishing everything up, extracting the juice out of every cranny I could.

With programming, at least for me, it's not the implementation that's hard - it's the bugs that come after. Finding them, fixing them, ughh! Due to this game's simplicity, though, there weren't many holes for which these nasty little critters could claim a home. When you reduce your scope, everything becomes simpler.

So okay. The only thing left to do was the music. I use an online tool, Jummbox, that's somewhat easier to work with, at least for a composition noob like myself. But then, my ISP decided to just give up on me - so I had to focus on something else. With this 'extra time', I went down the priority list and settled on making an intro sequence.

Nice. I watched some old DVDs with my sister, then went to bed.

The next day, the last day, I focused solely on audio - music and sound effects. That night of rest was critical for my creative juices to get a kick - had I tried on the previous day, I would've probably kept banging my head on the wall to get it right, wasting precious, precious time.

This was the result: https://tinyurl.com/ymndtx9r

With the extra time, I dedicated myself to developing a simple dynamic track system to advance the song at key times when the player reached certain waves. With this, the project was over. For the first time, I didn't even have to rely on last-minute patches or stuff to get everything running properly.

The next day, I wasn't even thinking of Ludum Dare anymore - I was too busy stressing over asking my boyfriend if he wanted to go official. A story that's perhaps a bit too personal for this site, haha.

So what did I learn?

My word of advice, honestly? Keep it simple, and keep it short. Don't think of this as making a normal game, but instead as a jam game. Introduce your concept in a concise manner, polish it up, and make it unique. Personally, when I'm going through the entries, I'm looking for that 'Oh, neat!' feeling of being surprised and impressed at the same time.

Another thing is to be wary of making it too difficult... people unfortunately don't have as much patience, there are other games to play! My idea for Laser Grid, from the outset, was for it to be action-focused - though that created difficulty problems that were tricky to solve. When in doubt, err on the side of 'too easy', at least for jam games.