On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

Birdwards

48
Posts
4
Topics
55
Followers
A member registered Sep 10, 2016 · View creator page →

Creator of

Recent community posts

(1 edit)

I was a participant in ScoreSpace #17, which just released its results. I know that games receive a score penalty if they have fewer than the median number of ratings, so during the rating period, I had been checking both the number of ratings my game had and the number of ratings the median game had (when sorted by "Most Rated"), and trying to share my game with as many community members as I could to ensure my game did not fall below the median. By the end of the rating period, I thought I had just managed to avoid the penalty, as both my game and the median game had 14 ratings.

When I checked the results, I was surprised to see that I ended up receiving a pretty hefty ratings penalty that bumped me down from 3rd place overall (by raw score) to 21st place (by adjusted score). I was especially surprised because, while I had worked out the median to be 14 ratings, the results page stated that the median was 12 ratings, meaning my position was safer than I thought.

However, when checking the results in the individual categories, I noticed a discrepancy: while the Overall results said I had 14 ratings as I expected, the results for all the individual categories (Gameplay, Theme, Aesthetics, and Sound) said I only had 9 ratings (see attached image). I checked to see if this was the case for the other entries in this jam, and it was: all the other games I checked were listed as having slightly fewer ratings in the individual categories than in the Overall results. I copied all these smaller numbers into a spreadsheet to find the median, and sure enough, it was 12, not 14.

It seems that, for all games in a jam, the number of ratings that a game receives is actually two different numbers. The larger number is displayed on the game's rating page and the Overall results, as well as being used for the "Most Rated" sort. The smaller number is displayed on all the individual category results, as well as being used to calculate the median and adjusted scores. I'm guessing that this discrepancy is a bug, since you are required to rate a game in all categories before you submit, so it's impossible to have fewer ratings in one category than you do overall. Besides, I doubt this has anything to do with there being fewer ratings in one category than overall, since for all the games I checked, the game was listed as having the same exact number of ratings in all four categories - an unlikely coincidence if some voters were leaving some categories blank. If it isn't a bug, why are there two different numbers?


This is cool! I got 1,502,850. The graphics and sound are great. However, since the teleport does the same amount of damage as the regular attack, I didn't see much of a reason to walk or attack instead of just teleporting into all the enemies and bullets. I'd recommend placing a cooldown timer on the teleport, and maybe reduce the amount of damage that walking or teleporting into an enemy does.

This is cool! After a couple tries, I got 01:13:13 without using shortcuts, but I can see how that time could be slashed with the right route - I'm tempted to look for that optimal route myself. I noticed that sometimes, when I fell off and respawned, I would be facing backwards on the track, and I wouldn't necessarily be placed back in the area from which I fell. I also agree with Robin about the camera, but I totally sympathize with 3D cameras being super hard to get right. One thing I would suggest is focusing the camera on a point in the air above Speedy, so Speedy is near the bottom of the frame (or the top of the frame, when gravity is reversed), then using the mouse controls to orbit around that point, instead of panning and tilting like it is now. That should make it easier to see more of the track, especially when there's a bump ahead.

This is great! I got 1097. The fast pace makes it a bit tricky, but I like the challenge.

Here's mine; I'll play and rate yours now!

https://itch.io/jam/scorejam17/rate/1377797

Woo, 2nd place! I really liked this one. Those spiraling patterns are super satisfying to hit! I could see this working well as a rhythm game.

Here's mine; I'll play and rate yours now!

https://itch.io/jam/scorejam17/rate/1377797

Good work! I got 1020. It's interesting how the high score is based on max combo instead of how many enemies you defeat overall. I do wish you could see the descriptions of each power-up before selecting them.

Here's mine! I'll go play and rate yours now.

https://itch.io/jam/scorejam17/rate/1377797

Nice! I got 299. I know others have said this, but I also really like the splatter - although I found that the splatter sometimes served as camouflage for the enemies (maybe it should be a bit darker than the enemies).

Here's mine - I'll check yours out now!

https://itch.io/jam/scorejam17/rate/1377797

Good work, especially for a first project! I got 4640. I like how you don't tell the player exactly what they'll be doing in the description - I laughed out loud as soon as I realized what was going on. I also like the conflict of protecting the ship versus not blocking its shots. That said, the ship does miss a lot, especially when there aren't many enemies left. I'm guessing that's because the ship moves to a randomly generated position after each shot. If the random positions were restricted to where enemies are (or soon will be), it could quicken the pace of the game.

Here's mine - I'll go check yours out now!

https://itch.io/jam/scorejam17/rate/1377797

Pretty good! I like how there are two different goals that the player needs to prioritize. I got 66! I noticed the spawn-rate problem too, but I see you're already aware of that. It would be nice to see the current and high score on the game-over screen, not just during the game, so it's easier to see whether you beat your high score.

https://itch.io/jam/scorejam17/rate/1377797

I'll go play and rate yours now!

Nice work! I agree that the controls took some getting used to, but this game is very polished overall. I was a bit confused by the sound effect that sometimes plays when the water hits a house. At first, I thought the sound effect represented me putting out the fire, but it would sometimes play when the water wasn't hitting anything on fire, and sometimes it wouldn't play when I was putting out a fire.

(1 edit)

This is wonderful! It's super cute (I love the squeaky-toy sound effects used for when the squirrels get hit), and pretty fun to play once you get the hang of it. I did run into a couple of issues, though:

- I noticed a bug where squirrels would run towards an empty spot on the ground for a while, sometimes gathering in a cluster. I think I saw a nut fall through the ground at one point, so my guess is that they're running towards a nut that they can't reach because it's underground, only changing their focus once the nut falls down far enough that the AI determines another nut to be closer.

- I think the red squirrels got temporarily stuck inside the stump a couple times (maybe a nut was blocking their path?), but that bug was much less common than the first one.

- I found the hold-the-mouse-to-aim to be a bit difficult to use - many a stone flew over their intended target, especially at close range.

- The difficulty curve seems to be a little slow. I ended up stopping once I reached 100 acorns in the stump and just waited for the gray squirrels to steal them while I wrote this. However, I did notice that after I stopped playing, the gray squirrels suddenly seemed to appear in much larger numbers than before - can the spawn rate be affected by how many gray squirrels you knock out?

Still, great work overall (and I'm happy to have the highest non-dev score)!

(1 edit)

Thank you! Unfortunately, I couldn't reproduce the problem - I made it past 3 minutes a couple of times and the game didn't crash for me. Just in case, I uploaded a version below with a debug window so you can see any errors that come up while the game is running. I don't know if it'll help (when the game crashes, it might just close the debug window at the same time), but if you manage to see an error on there, it would be a huge help if you could let me know the error. This is a Windows version; let me know if you're on Mac or Linux and I can upload one for that instead.

https://mega.nz/file/tQBUgJ4C#SXAnifNyH0IGTIGens6Mm-HMWtkwaFZ60EMpQ8AM6G0

No obligation, of course; I know there's a lot of other games to try and not much time left to rate them.

Oh no, thanks for letting me know! I'll look into it and see if I can get a fix going.

(4 edits)

Hi! I got a different error when trying to run the .exe:

The procedure entry point _ZNKSt7__czz1112basic_stringlcSt11char_traitslcESalcEE5c_strEv could not be located in the dynamic link library C:\Users\[my user folder]\Downloads\Build\game.exe.

After a quick search, I'm guessing that this is also related to the DLL stuff.

Edit: I was able to get it running by compiling from source, though!

Hi, I just saw this! Each row has a rectangle over it whose purpose is to tint all the other objects in the row a given color. If you're using Godot, you can use a solid white rectangle, set its Material to a new CanvasItemMaterial with blend mode "Mul" (in any other engine, there may be an equivalent "multiply" blend mode). Then, by changing the rectangle's Modulate color, anything underneath the rectangle is tinted that same color (all the platforms here are actually white; they're just tinted by that rectangle). From there, I had a counter that kept track of how many rows spawned, and for each new row, I would tint it the next color in the sequence.

Wow, this is ambitious for a 3-hour jam! I loved the monologue. I was worried at first about whether or not I would remember what the ship looked liked at the beginning so I could recreate it, but thankfully, it doesn't matter what pieces you put where- which I think is actually a pretty clever tie-in to the message of the monologue.

Finally, a game that draws attention to the perils of bycatch. :P

I love the cute crayon graphics, and the whole thing has a nice, relaxing atmosphere.

The speed limit on the dragons makes this very difficult, but I enjoyed it. The ability to drag multiple dragons at once creates an interesting risk-vs.-reward decision: how long do you let the dragons gather at the plane and damage it so you can fling them all away in one go?

Cool idea, though it very much needs a way to restart if you fall. Also, I encountered a bug on level two where my character "fell" even though they were standing in the middle of a piece.

(2 edits)

It's a neat idea, but whenever I stopped time, I ended up dying before time resumed, since I can't move out of the way of bullets that spawn while time is still stopped. As such, it's actually safer to never stop time. Still pretty neat, though.

By the way, I'd strongly recommend adding a thumbnail image for the game page. Per the rules, you don't have to count making your game page as part of your 3 hours, so it's fine to do it afterward.

I can't take credit for the music, but I'm glad to hear you liked the game. Thank you!

Thank you! Yeah, I agree that the places where the ball can rest are a bit too hard (see my response to Spielsieb above).

Thanks- I was considering fleshing this one out into a mobile game, so this is very encouraging to hear!

(1 edit)

I was surprised how long I played (and survived) this one- I got to 592 seconds before deciding to just let the goblins take over the castle. It'd be nice to see the timer during gameplay, though I wouldn't be surprised if that was cut for time. The goblins are super cute, and I love the idea of turning a dropped object into an area-of-effect attack by shaking the ground. The ability to directly pick up and drop your enemies reminds me a lot of the old Flash game Defend Your Castle. Nice work!

(1 edit)

I like it! Given how high you need to raise a rock to squash a bug, there's a lot of skill in timing the drop right. My one critique is that there's a strict limit on how high of a score you can get: the number of bugs that can spawn in 30 seconds. For a game like this, it'd be nice to have a mechanic that (for example) extends the timer for each bug you squash. Of course, adding a mechanic is easier said than done in a 3-hour jam; I wouldn't be surprised if that suggestion was already on your to-do list.

(2 edits)

Haha, I actually called the square bracket (the one with the point in the center) the "evil block" while I was working on it. I think it'd be a little easier to deal with if the marble didn't go flying off to the side so easily. If I did any more work on this game, I think the first thing I'd do is experiment with the mass of the marble and perhaps a speed limit on how fast the rows can move, to make the game less punishing. Thanks for the feedback!

(1 edit)

Right now, in ranked game jams, games receive a penalty to their score if they receive fewer than the median number of ratings. I wrote a whole thread last week about why I dislike this system. However, I have since found the response by leafo (an admin) to another user asking about the scoring system last year, and realized my original thread was really more of a suggestion phrased in the form of a question. So, let me rephrase my thoughts in a more appropriate forum:

I understand the problem that the score penalty is trying to solve, and agree that it is a valid problem- if a game has a tiny number of ratings, its score is likely to be very inaccurate. However, using a score penalty to reflect this is highly misleading to devs: it tells them that their game was worse because it was less popular. As leafo notes, players usually ignore a game when they think the game doesn't look good, so there is at least some correlation between popularity and quality. However, this isn't always the case - I've played great games with terrible thumbnails and bad games with beautiful thumbnails. Plus, a game looking bad isn't the only reason a player might choose to ignore a game. For instance, I am far less likely to click on a game whose thumbnail makes it look like a horror game- even if it looks like a well-made horror game- because I don't like horror in general.

My suggestion is to replace the score penalty with a system that simply leaves a game out of the rankings entirely if it does not receive enough ratings- or at least allow game jam hosts to switch between the two systems/turn them off entirely. Leaving ignored games unranked has been proven to work well - Ludum Dare has been using this system for years - and it still keeps the benefits of the score penalty: encouraging community interaction (so devs can get their games ranked) and preventing largely ignored games with skewed ratings taking the top spots in a jam.

Also, I'd like to rethink the question of how many ratings are too few ratings. I think it was smart to base this threshold on the median number of ratings, so it's not skewed by a small handful of games having way more ratings than everything else. However, I think the median itself is much too high of a threshold- it guarantees that nearly half of the entire field will be penalized, regardless of how evenly the ratings are distributed. It's pretty obvious why this would be a bad thing in the do-not-rank system I'm suggesting, but it doesn't sit right with me to see a game with 9 ratings receive even a small penalty in a jam where the median number of ratings is 10. I'd prefer something like half the median- this would still penalize games that are clearly passed over repeatedly, but if the less-popular half of the games all got a number of ratings that is still pretty close to the median, it wouldn't have to penalize any of them.

Thanks for your time, and I'm interested to hear itch's thoughts on the matter.

I found a previous thread asking this same question, but with no response. That user shares my thoughts exactly on the issue, but to reitertate: in a ranked game jam, each game receives two scores: Score* and Raw Score. Raw Score denotes the actual ratings a game received from its players, while Score* seems to be one of two things:

  • If the game was rated by at least the median number of players (regardless of how well or poorly it was rated), Score* is the same as Raw Score.
  • If the game was rated by a below-average number of players (regardless of how well or poorly it was rated), Score* is lower than Raw Score. The fewer players a game received, the more it is penalized.

Entries are then ranked by Score* instead of Raw Score. I am strongly against such a scoring system, because:

  • It gives games a scoring advantage if they have an eye-catching thumbnail or if the developer has a preexisting following.
  • It gives games a scoring disadvantage if they belong to a niche genre.
  • Having two separate scores with no explanation for the difference is confusing to developers.
  • Games with a high Raw Score can have a low Score*, making developers feel like their game was much worse than it actually was. To use an extreme example, this Trijam game received an overall Raw Score of 3.833 - not bad at all! - but since it was only rated by 3 people, its overall Score* was brought down to 2.213 - a pretty bad score. This had a huge effect on its ranking, as well: it would've ranked 12th out of 35 by Raw Score, but it actually ranked 28th out of 35 by Score*.

I have a guess to why itch does it this way. When a game has very few ratings, there's a greater chance of the rating being skewed up or down by a particularly opinionated player, or in less scrupulous circumstances, by a willing accomplice/salty troll attempting to artificially inflate/deflate a game's ratings. I can see the logic behind behind awarding the victory to a game that got, say, an average of 4.5 stars from 20 players, rather than naively awarding it to a game that has 5 stars because only one person played it and that one person happened to give it 5 stars everywhere.

However, this scoring system seems like a poor solution to that problem. Yes, a game's rating may be biased if only a handful of people have played it, but there is no way to tell in which direction the rating is biased. Fewer ratings are not necessarily a reflection of lower quality; they are a reflection of higher uncertainty about the game's quality. But this scoring system doesn't reflect that uncertainty- it simply tells developers that their games were worse because they got fewer players. Also, the median number of ratings is much too high a threshold at which to start punishing games for having too few players- you're effectively disadvantaging the entire bottom half of the submission field sorted by popularity. I'd think half the median, or better yet, a fixed number of ratings like 3 or 5, would be a better threshold to determine if a game has too few ratings to rank well. Above 5 ratings, I'd have a hard time claiming that any one player skewed the numbers too much.

To me, a more honest system would be simply not ranking any game that doesn't receive enough ratings. It still prevents the 5-star scenario I described above, but it doesn't tell the developers that their games were worse than the more popular games- just that not enough people played their games to get an accurate assessment of how good the game is.

If not that, I'd at least like the option to turn off the Score* system- if I were running a ranked game jam, that's the first thing I'd do.

Just so you know, the itch.io upload of this game doesn't work- it's missing the data folder. The Gamejam.com upload has everything necessary to run the game, so I was still able to play it. Nice work!

Thank you so much for the feedback, and I'm glad you liked it! Your analysis of "primary" vs. "secondary" games was really interesting. About the pits of death on the platformer: I originally didn't have them, but added them after finding in playtesting that it was too easy to completely ignore the platformer and just focus on the other two games. You're right that it feels unfair when you're already holding left or right when the platformer starts; the player is already very close to the edge by the time the static has finished fading out. What I should probably do is disable the controls until the static is gone, so the player has more of a chance to react.

Some of the enemies climb up the pole, which is a common way to help bring the pole down in the real bo-taoshi. Originally, the climbers were the only enemy type, but the game wasn't interesting enough with only climbers, so we later decided to add the kickers for some variety. I feel this decision made it a better game, although it meant sacrificing some of the game's connection to the theme. Thanks for playing!

Here's one for your scoreboard. I made it all the way to spaaaaaace! I had a lot of fun with this one.

This was cute and fun! A couple notes, though:

  • There are some impossible obstacles- during the "Faulty Construction" sudden death (where the right lane is removed), I got two of those tall signs side-by-side.
  • For any music or sound effect that you didn't create yourself, please credit the source in the game description.

This was cool! I had the same comment as PeaQueueAre about the portals, but other than that, I enjoyed figuring out each level. Some of the puzzle solutions were surprisingly clever!

However, I'm not sure this game would quite work in the streamer competition. Since each level has an optimal solution, there is a maximum theoretical score. This could lead to a tie if more than one streamer figures out the best solution to each level- and someone could cheat by watching other streamers solve the puzzles. It's still a good game in its own right, though.