Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags
(+1)

Thanks, I appreciate all feedback!

I didn't actually even think about having a prompt for making sure if the player wants to quit or not. Maybe I'll add it later.

The symbol appearance I'm most likely going to change into arrows. That was what I originally planned, but once you begin hurrying under a time limit, things get overlooked. Also: when you stare at the symbols for long enough and try to code the game while doing so, you get desensitized to how difficult they are to read for somebody else. I've been looking at them for so much that to me they're as easy to read as... well reading letters.

The right side of the screen issue. I rushed the game out for the game jam so I never actually managed to code in symbols coming from the other side as well without breaking the underlying game logic. I'm new to coding, and I pretty much had to learn how to code while building the game, so it's a bit of a mess all around. I'll probably fix that after the jam is done. I don't think I'm allowed to update the game after the submission period has ended.

The multiple cues issue was actually an uninteded coding blurb that I left in to make the middle game a little bit more difficult. I thought it feels kind of bad the way it is, but I left it in anyways due to, you guessed it, lack of time to code the mechanics properly to make the game more difficult! 

At that point the game expects you to cherry pick which symbol you want to hit. There is a not very well explained mechanic where you don't take a hit yourself as long as your score, which you can't see, is high enough. You should be fine most of the time even if you let symbols pass, unless the RNG screws you over. Essentially you can let a symbol pass for each symbol you've correctly hit and still be alright. It just makes the transition period to the next scene a bit longer. It's a sort of a buffer for fumbling.

This is the first game I've ever built and since I really haven't coded anythign at all before this, the game ended somewhat crude, short, simple and very amateurish, but I appreciate the feedback all the same.

(3 edits)

Also screen is really narrow and cues are quite fast. Framerate seems to be limited and my monitor is smudging enough to make cues completely illegible. Because game is really difficult but actually it’s pure RNG, playing it feels more like waiting for easy sequence that it’s actually beatable rather than getting better at mechanics and actually progressing with skill. Also fact that final unlocked animation is covered and obstructed by ending screen menu deeply saddens me… Still good overall.

That would be a limitation of Pico-8. The resolution is locked at 128x128 and it cannot be changed. The game runs at 30 FPS, which makes the faster notes a bit of a blurry mess, I agree. It's also possible to code the game to run at 60 FPS, which could make the symbols more readable. I'm actually wondering why I didn't start with that speed instead of sticking to the default 30.

You're right about the game being pure RNG. I wanted the "stages" to have their own uniqute symbol combinations, a few per stage and the game would just pick one of them every time it was time to spit the sequences out, but I ran out of time to do that for the jam without breaking the code. That would have at least let the player get used to certain patterns if they got stuck to any particular stage for very long. Right now it's more like a reaction test than anything else. 

Maybe a better way to do the symbols would have been spitting out... let's say 3 symbols one after another in a sequence, have the player hit all of them for a "hit" and after a few "hits" the story would progress. And instead of the symbol bar, I could have had the symbols maybe appear randomly somewhere in the screen space and have a circle shrinking around them to indicate when you're supposed to hit the key or something. The range for difficulty options could have included the size of the circle around the input symbol, the speed the circle is shrinking and the amount of symbols you need to get right to progress. A much better range of modifiers than what the project currently has.

The end screen animation I'm very miffed about, because Pico-8 is very limited in what you can have in it. It's a fantasy console that is made to have limitations by design. That includes the sprite sheet. I wanted to draw and animate something special for the ending, but there simply wasn't any sprite space left nor did I have re-usable sprites that would have fit the scene. I could have perhaps tried to squeezed every 8x8 pixel square together and optimised the area to get more sprites, but since I'm a complete beginner at coding and making games, that would have required so much more time and effort than I had available for the project. That is why there isn't any special ending and the re-purposed menu selection just kind of pops there and covers up the monster girl.

Saying that, I must admit, while I was putting the game together I felt like literally any other program could have been much better suited for what I wanted to do, but the few days I had to develop the game, I chose Pico-8 because Lua felt like the easiest language to learn in such a short notice and the program, while limited, contained everything from sprite tools to sound editing tools in it. In hindsight that very much got in the way of the visual side of the project.

What I find surprising is that many people, not just the people commenting here, seem to find the game really difficult and an exercise in frustration. Even if the stages are very short and only require 10 proper symbol hits to progress (unless you get progress deleted from missing symbols) I suppose all the testing I did to see if the game runs without breaking up made it feel too easy to me.

Thank you for the feedback though! This is all good stuff to keep in mind in case I decide to fix the issues in the project after the game jam.