This is my 3rd LD and I hope I will create something really interesting this time! I learned a lot in previous jams so will try to avoid my previous mistakes. Have a great jam guys!

Suddenly caught a terrible cold right before the LD. Started to code but wasn't able, so laid in the bed for the whole weekend and didn't do anything except the layout of the level. Very sad, but hope will do the next LD!

This time I have no team and thinking about joining the compo!

Tools

• Unity
• Gimp
• Bosca Ceoil
• BFXR

I also have an idea of Idle (incremental) game, so maybe I will use my favorite Kotlin language for it

Despite I wrote that I am considering joining compo if someone wants we can make a team! Just comment this post or you can message me on facebook https://www.facebook.com/zankur

Caravan will be a game based on text quests with multiple endings. It is almost finished, just need to add some more quests inside. Now you can check a few screenshots :)

Made previous one last minutes before the submission hour end :) Finally had time to create a new one, a bit more chaotic

Share link to yours in comments if you have commits/screens :)

Day 1

Day 2

I usually find all the music creation tools unnecessary complicated for the task I want to do during the jam. This time I used Bandlab as it is super user-friendly and has a large library of synths and loops there for free. Also it's available from browser.

Created music for Tiny Inc. Repair shop (https://ldjam.com/events/ludum-dare/56/tiny-inc-repair-shop) in ~20 minutes while was waiting for Unity to build the project. What do you use for music creation?

Heard on one of the streams that it is nice to put a gif in the description that explains how to play your game, so people understand this even before they start.

Made one for my game, shows what player should do and how creatures interact with each other to solve puzzles.

I was watching how different people play my game, and noticed an interesting common issue with the tutorial. Tiny Inc. Repair Shop is a puzzle game, where you need to place tiny creatures on the board in the correct position, so that they bring electrical charge to a battery (gif probably explains it better). Every creature is special: - one is going only left or right - second up or down - the third one charges and pushes any creature on it's way.

The tutorial that I could afford making during 2 days of compo, looks like notepad on the side which shows creature description when you hover the creature. Like on this gif

The problem with this is that people don't notice that the text in the notepad changes and can't understand how the creatures work, as their eyes and attention are at another place. What I saw is that players rarely read the notepad at all, they just put the creatures on the board and try to understand what they do after.

How could I help player to understand this better?

One way might be to show gif in the notepad (or pictures) instead of the text. The blinking should be more attractive to the player's eye, and catch their attention.

Another way I quickly implemented is that creatures just describe what they do while they sleep and wait for player to take them, something like this:

The reason I like this idea is that apart from exposing player the information about how creatures work, I also convey their personality through the short line of text. Something I used entire notepad page before could actually be just three words of text in a bubble.

What do you think, is it helpful or too vague? Any other ideas on how to make tutorial in such games?

If you want to play, btw, here is the link: https://ldjam.com/events/ludum-dare/56/tiny-inc-repair-shop

I added analytics to my LD game and noticed that big amount of players close the game on level 4. Fun fact: level 4 supposed to be a chill level to give player a break between challenges and a tutorial to a new mechanic at the same time. It was created to hook player's interest to play further, but instead had an opposite effect. How did that happen? Let's have a look!

When I started working on Tiny Inc. Repair Shop at the beginning of the first day, I set my self a goal: the game should have at least 5 levels and all of them should be finished by the end of Day 1, leaving Day 2 for polish only.

For those of you who didn't play, Tiny Inc. Repair Shop is a puzzle game, where you need to arrange differently behaving creatures on a grid board so that they bring a charge to a battery.

If you want to play it to understand better what I am talking about consider playing the game here

https://ldjam.com/events/ludum-dare/56/tiny-inc-repair-shop

Context

From the beginning I had 3 creatures in mind:

1. The first will go left and right only
2. The second will go only up or down
3. The third will stay idle unless it sees a red color thing either vertically or horizontally. If it sees one it will charge to it and push it until meets the wall

Combining them along with placing some blocks on the grid opened some space to design a few interesting puzzles. But I got exhausted pretty quick (after the 3rd level) and decided I need a new mechanic: a button that will open a door. To introduce this mechanic I needed an easy tutorial level, something that should show the player that:

1. There is a door
2. There is a button
3. If the creature steps on a button the door opens

So I created this:

The idea is simple: you place a creature that goes from left to right (the green one) near the button and then another one near the charge. The one near the button will open the door and the one with the charge will go inside and finish the level. In fact, this was what most of the players who played in front of me did. But what happened instead was this:

The green guy presses button, encounters the wall, turns back and then presses the button again, closing the door right in front of the other green guy, carrying the charge!

Obviously I saw this during the development and tried using other creatures to see if the level is passable. In the end it was and at the time I though it might be a good idea to leave this as is, so that the player tries the most obvious solution and the game says "Gotcha! Try again!". I thought that maybe this will require the player to think a bit more and then once they realize how to pass it they'll get this "Aha!" moment which all puzzle designers strive for.

However what I observed from people playing this level, it was completely unobvious how to pass it. Some people randomly found the solution, some people exploited a bug (which I fixed later) and some people (majority) just gave up, abandoning the game.

One big mistake this level did for players was violating the rule of the puzzle genre. Instead of making a player feel smart it made them feel stupid. And no one likes feeling stupid!

Fixing the bad level design.

The best fix for this level I think is bringing it back to the original idea: just introduce the new mechanic in the easiest way possible so player understands how to interact with it. If I just move the button one tile right, the green creature just doesn't have time to come back to it and toggle the door.

Yes, the level will be much easier and it doesn't show that the button closes the door as well as opens it, but it's okay. I can expose togglable behaviour on a different level and create this "Aha!" moment once player realizes how to overcome it.

However I didn't use the fact that button toggles the door state in any of the other puzzles, so the other fix could be to just disable it and use button to only open the door.

Conclusion

If I will do puzzle games for future jams here are the crucial things to take care of:

1. The puzzle should make the player feel smart, not stupid
2. When the solution feels unobvious at the development stage it is unobvious for players
3. When designing a certain mechanic (e.g. toggling the door state) consider if I will use it at all in future or if it is unnecessary complicates things. Whatever makes things unnecessary difficult should be thrown away.

What puzzle design advices could you give to new puzzle designers? Would love to hear!

I made a game about doomscrolling: basically this feeling when you are so deep in your reels/tiktok/shorts feed that you start seeing weird things.

The game is about managing your stress while watching weird/scary short videos, and relieving it while watching memes or posting comments.

One thing that I really wanted to add is a tribute to the meme about gnomes and knights that was viral some time ago, does anyone even remember it?

So the idea was that when you first encounter a gnome or a knight you can either swipe away (thus joining the corresponding team) or "fight" with it by posting comments under the video (thus joining the opposing team). And then, if you are a gnome, encountering gnome videos on your feed will calm you down, and the knight videos will increase your stress level.

Unfortunately I didn't have time to implement the mechanics, although managed to create "videos" for both:

Anyway, at least you saw this silly idea if not in my game, then here :)

Do you have any easter eggs in your game? Feel free to share in comments, I would love to search for it :)

If you want some doomscrolling though, please have a look at DoomScrolling

I played a few games here that have an upgrade mechanics, most of them implement kind of vampire survivors upgrade system with 3 random choice upgrades (like on the picture below)

In fact, I encountered it so many times, I started to feel weird about my game implementing this as well (if you want to try another game with upgrades, feel free to check out Doom Scrolling - roguelike about bottom of your short videos app)

Even though the upgrade system clicks in Vampire Survivors I have a controversial opinion that it might be harmful for the LD entry.

The upgrade system works in VS because it matters and it matters for two reasons:

* 1. Without it game is still fun *

If you remove upgrades from VS, and leave only one ability the game will obviously miss a lot, but it will still be fun to play for 4-5 minutes. The reason is because the core gameplay loop is fun - you have enemies around, and you need to maneuver between them so you can hit them and avoid being hit yourself. The number of enemies on screen becomes bigger in time, so it becomes more challenging to keep alive and number of seconds you survive could be a indicator of your skill which you can use for competition with other players, or the game designer can use as a game goal. Note, that people will play your LD game for 5-10 minutes tops (unless they are super hooked), so while it's not great for steam release, if your LD game is enjoyable for this timeframe you did a great job.

* 2. Without upgrade system Vampire Survivors is much more difficult and becomes unplayable quick enough *

While core gameplay loop tests your dexterity/reaction skills, upgrades/meta tests your strategic planning skills - how good can you choose upgrades to keep up with bending challenge curve? Upgrades add another dimension to the game, Without it you can compete for seconds of the gameplay, with it you compete for minutes of additional gameplay time.

What's wrong with LD games with upgrades?

Most of the games with upgrades I saw lack either 1 or 2 of the above criteria. If your core gameplay loop is not polished enough and doesn't click, upgrade system doesn't make it better. There is not much motivation to search for upgrades and explore upgrade tree if the core game is boring. At the same time, if you can complete the game without a single upgrade - the whole system also doesn't make any sense (you could've just removed it).

Why could upgrade system be harmful for your LD entry?

LD is very time constraint event and you must prioritize properly, otherwise you can't finish with something playable. Without polished core gameplay, upgrade system doesn't add to you game. This means that time spent on developing the system is taken from time you could spend on polishing core, and in the end it means you spent your time on nothing, not making your game better, but wasting your precious effort and time.

Well polished core gameplay without upgrades is always better than average bland core gameplay but with.

What do you think? Feel free to comment here if you saw a great entry this LD of game with upgrades, or let me know if you think I am wrong, I am always happy to chat :)

If you think a guy writing a post like this created a great game - you are wrong :) I think I fell in the same trap this time, but if you don't mind, feel free to try my game out - here is the link

I finally finished post jam version of Doom Scrolling, finishing everything I was planning for compo.

The best illustration of me overestimating myself is this - it took me around a month to work 2-3 hours a day to implement all the features, balance it and fix all the bugs (well, not all of them, but only critical ones).

It even involved building paper prototype of the game, as it was much faster to iterate on game balance with real cards, rather than fixing everything in Unity.

I can write another post on the paper prototype, how I came to it and how it was useful, if you want to, please like the post :)

I'd also appreciate if you play the game and leave any feedback under the post: even if you opened, didn't understand how to play and closed, that would be an awesome feedback already.

Check out the game on itch

Happy Doom Scrolling :)

Since the rules allow to start with any base code, I prepared a small template which sets up a bunch of useful libraries for unity (such as DOTween and UniTask) and adds a little bit of utility functions.

However the biggest advantage I see is the CI pipeline based on github actions. Whenever I commit my code it will do a build and if the build fails I'll be notified. Very easy to know about any issues with the build at the moment the issue happens, rather than at the moment I need to upload this on itch :)

If I create a release on github it will build and upload it on itch.io. It is possible to upload build from every commit (I did it last LD), however I prefer to submit selected ones.

If you are interested to setup the same feel free to fork my github repo here. There are also instructions on how to setup same pipeline with continuous build and continuous upload on itch. Only web is supported for now, but you know the power of open source, feel free to contribute if you wish!

You can play and listen Paper Fishing here

It was very fun making it, but the most challenging part was making a sound of the reel, when you pull out the fish

I listened to at least 15 different reel sounds before trying to reproducing it. The main challenge was that I can't pronounce the hard R properly so I can't do TRRRRRRRRRRRRRRRR sound that it makes.

I noticed that sometimes the reel sound consists of two (good example might be this video https://www.youtube.com/watch?v=gMTin3LDdE4)

• Sound of the string vibrating in the air, which more like a breathing out sound
• Sound of the spinner squeak, which I could actually repro without R sound, but just relaxing my throat to max, and do a creaky eeeeee sound.

I think it ended up good enough, but I guess fun of making it was the most important part for me. My friends always notice the wind blow sound, but no one mentioned the reel sound, which I think turned out quite interesting :)

If you want to catch some fish and (and listen to my voice lol) consider playing (and rating) Paper Fishing

Paper Fishing just got new cover! The old one doesn’t seem to attract clicks on itch.io. What do you think about this one? Any feedback? :) to me it feels the bottom is a bit too heavy, but I can’t think of anything to add on top.

Join here https://www.twitch.tv/io_vo

Drop your game in comments here :)

I will start from the games under this post and will continue looking at the games here.

Join on https://www.twitch.tv/io_vo

I will start in 15 minutes with game by @mikhailne and continue with keklik by @rogaven. Feel free to submit your game on the stream, just message !submit in the chat. https://www.twitch.tv/io_vo - see you here!

I never did a proper retrospective for my past LD. I always had in mind what was working and what not, but this time I decided it might be fun to run a full fledged retro in I wish / I like format.

What is retrospective?

For those of you far from corporate world and agile processes, retrospective is used to extract learnings from the past work find the most painful issues and come up with action plan to get better next time.

There are various formats on how you can do retro, I used the simplest one this time.

The idea is that you have two columns. In each of these columns you put facts about your work during LD. - I like put facts that start with I like, e.g. I like sounds I made for the game; - I wish put facts that start with I wish, e.g. I wish the game had more content

Do it in a brainstorming format, timebox yourself to 20 minutes tops. Just do a complete braindump about your LD there. Maybe have a look in comments about your game, but just for inspiration.

Extracting the value

Go through each item and ask yourself: - "Why did I like that? What could I do next time to make sure I will like it again?" - "Why the thing I wished for didn't happen? What can I do now or next time to make this happen?".

The answer will probably lead to an action item you can plan for yourself. If that's the case - write it down. If it doesn't immediately lead to an action, ask yourself "Is there anything I can do about it?" and write down what you can do.

By the end of the retro you should end up with: - A short-term plan: e.g. what you can do now (maybe learn something a bit deeper, maybe practice in something) - A long-term plan: how you will approach the next LD.

Paper Fishing retro

Here is how my retro looked like.

Please comment if you have any recommendations on the action items I defined, also feel free to share your retro results in case you also decided to run one!

If you want to see the game I was doing it for you can play Paper Fishing