Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
A jam submission

Robin "Xmas" SweatersView game page

Help the poor of the village get their yarn back to stay warm this winter
Submitted by Edvid — 15 minutes, 50 seconds before the deadline
Rated by 9 people so far
Add to collection

Play game

Robin "Xmas" Sweaters's itch.io page

Rate this game

In order to rate this submission you must be logged into itch.io and have submitted your own entry. Anyone with an account can leave a comment.

Godot Version
4.3

Wildcards Used
Silent Night, UI is Real, Advent Calendar

Game Description
Help a distant cousin of Robin Hood keep the villagers warm and happy this winter

How does your game tie into the theme?
You help the villagers not freeze this winter by getting them their yarn back

Source(s)
N/A

Discord Username(s)
edvid

Participation Level (GWJ Only)
2

Leave a comment

Log in with itch.io to leave a comment.

Comments

Submitted (1 edit)

I wasn't quite able to enjoy the game as much because of the severe lags - my fanses exploding. I think this might be because you were rendering the whole map at the same time? And all of them were doing path-finding, and a rather complex one?

The ideas are nice, but the lags made the game unplayable for me.

Very charming, simple, fun, and there's a surprisingly large amount of strategizing involved. I personally haven't experienced any lag while playing.

Submitted(+1)

Simple but a good concept. I thought the very first guard was a great way to introduce the mechanic as it made it very easy for me to understand how to play. I didn't have any technical issues as other comments have suggested.

Submitted

Surprisingly addictive.

Submitted

A bit laggy but not a nice idea.

Submitted

Hello! The game freezes (no pun intended lol) if we walk for too much time. I suppose that it can be an issue with how you instantiate your audio player node, it looks like you're instantiating dozens of nodes and adding them each frame.

Developer

How odd! I never encountered such problems during development, nor has any of my friends playtesting it. Not even my profiler flaired up when I’ve been moving for a while. If anything, physics calculations take up more CPU time than AudioStreamPlayers. What device are you using? Which browser? I’d be willing to get to the bottom of this if you have the time, since I can’t reproduce your problem myself. I’d at least be learning something about godot!

Developer

I’ve been able to get 2 friends to reproduce the issue on their computers. So that’s just short of half of those who’s played the game so far. I’ll be looking into this, but obviously can’t fix it till after voting period

Developer(+1)

I’ve now narrowed down the problem to just one line of code! The audio stream player instantiations are not the problem, it’s the way I check for knights hearing footsteps. When walking for a while, there will be many footsteps in the scene at once, and they each have their own range in which they can be heard by knights. There’s 30 knights in the scene, and when walking for a while, probably upwards of 100 footsteps. Each knight checks every footstep for overlapping hearing range (except when one is found to overlap), which might be too many checks per frame on some browsers. I’m not quite sure what my lesson learned is here, since I playtested with some of my friends, my not the ones that ended up being able to reproduce this issue.

Submitted (1 edit)

Oh, I see! Just throwing it out there but  "Each knight checks every footstep for overlapping hearing range" seems weird to me, in a technical way. Are you using Area2D for this? Maybe this is what you have already, ignore if it is the case but I would try to have something like:

  1. Knights have an Area2D that only checks footstep's Area2Ds (selecting only the knight's mask layer)
  2. Footsteps have an Area2D that only checks for Knight's Area2D (selecting only footstep's mask layer) (if you really need to, check the item below)
  3. Footsteps don't need to check for Knights, so you can disable the "Monitoring" and keep only "Monitorable" for the Footstep's Area2D
  4. Knights are the ones who should check if they are overlapping with a Footstep's Area2D, so you can maybe disable "Monitorable" for it

If the knights are meant to chase you when they hear a footstep within their ranges, you could only call it one time when the Knight/$Area2D.area_entered signal is emitted.

Again, you can totally ignore this thought, I don't know exactly about your internal rules so it may not make sense, just wanted to share if it can help you in any case.

Developer(+1)

Nope! Works a lot simpler than that. No signals, no overlapping Area2Ds. A knight will find the distance to a footstep, and check if the distance is greater or not greater than the radius in which a footstep can be heard. I have an Area2D on the footstep but its only used to visually store the radius in a way I can play around with in editor. The Area2D has no collision layers or masks it listens to. I expect this calculation is a lot cheaper than 2 overlapping polygons (even if rectangle and circle are faily simple), but I suppose 30 knights * how ever many footsteps you can make in 15 seconds, is just too much for some browsers to handle. Once the Game Jam is over, my GF has pointed out to me it would be a lot better if its not the footsteps the knights will compare to, but just the player character himself (as long as he’s making footprints). Footprints should remain visual only