Sorry, I don't think it's possible, unless you can somehow unpack the game file itself and pick it apart.
I lost all the Pico games I had made to a HDD failure not too long after I published this one and naturally I was dumb enough to compile the only game that survived online in a way where you can't view the source code.
Would be great if there was more of a reward afterwards. After completing the game it just felt like "You win, bye". Maybe adding a gallery mode after beating it, a save state (after completing the game), and as previously stated an actual reward after beating the game. Over all, it's a great game and very great artwork.
Yeah. I was in a hurry due to the time constraint so I kept the game very basic and left in loads of faults and oversights. I was entertaining the idea of making an updated version on Godot with all kinds of fancy things in it in addition of fixing bugs, but I've had no time to sit down to properly start coding anything new since the game jam. Should work on fixing that before the next year's game jam begins.
Sorry, can't really improve on this game even if I wanted to. The code and all the assets are long since gone. Could always make a sequel of sorts with actually good gameplay mechanics. Don't hold your breath though, even if it's something I've been wanting to do for months now.
After playing this game for a good 15-20 minutes, I must say that it's not the best. It's a good concept but the execution of that concept is dreadful.
1. IF you're going to make a game like this, you need to have the buttons you have to press be more clear, for example the up button actually being an up arrow instead of the letter U. Further more on that is the fact that you can't really see the letters unless you're leaned into the screen due to how they are all shaped, it's easy to get them confused when you're not looking at the colours themselves, D and R look exactly the same if you aren't completely leaned into your screen.
2. Sight reading this game is incredibly difficult to do. The notes move very fast and there's some form of an input delay as well so you only really get a second to react to what's coming, if the button sequence is cursed then you're screwed, especially if some buttons overlap.
3. The entire right side of the target is completely useless. After failing a cue, they should either disappear or the target should be moved further to the right.
4. The game would be a lot better if you could customize the button layout, say for example the arrow keys are uncomfortable to use in this way so you'd prefer using WASD or any other keys other than the arrow keys.
That's all. If some of these things were to be improved on, this game could be a good idea/concept but for now it's simply not fun to play.
Hey, thanks for the feedback. I feel you on all the issues you pointed out. Most of them were something that I had already taken a note of while writing the code, but I decided not to try sorting them out just yet. I've no spare time to put into the project for now and I needed to get the project out for the jam, with warts and all.
Arrows for the symbols were something I was originally going to change before uploading. I knew the symbols as they are now aren't the most readable kind. But, as you develop stuff like this, you get used to the things on screen and become blind to the faults.
The overlapping symbols was an unintended, can't call it a bug, but maybe a coding behavior. I left it in for the most part to make the middle game more difficult due to the lack of symbol variation. What the game expects from you then is to let some of the symbols pass. Essentially if you cherry pick the symbols you can manage to hit in time, you should be alright unless the RNG royally pisses on you. It's not very well explained, but when the symbols hit the right side of the screen, you don't take a hit unless your "score" is too low. I thought about showing the score at first, but then decided to keep it hidden. Roughly speaking you can let as many notes pass as you manage to hit properly. It's a bit of a shitty mechanic, but hey! I was short on time. :D
The right side of the screen is mostly unused, yes. The original idea was to have symbols sometimes come from the right side as well, but the code is such a mess that getting it work reliably for the jam would have taken too much time to fix.
The button layout I think is customisable to a degree before the project is packed. The game is made on Pico-8, a fantasy console, and is very limited in what you can set it up to do input wise. The default keys are z,X and Arrow Keys and I'm not sure if there's any way of changing them from what they are hard-coded to once the game is out.
Most of the faults are from rushed development time. I only had a few days to learn how to code and make a game. The main goal for me was mostly just getting it done, or just getting the game working without breaking. I've never coded a game before so this is all very new to me in many ways.
But all critique is welcome. I might poke around in the game code and fix most if not all of the issues you brought up once I've more time in my hands. The story and dialogue kind of also end abrubtly due to not having enough time, so maybe that'll change too.
This is a good start; great artwork, good concept for gameplay, but there are some issues I noticed.
1. No matter what game you're making, you need to have an "Are you sure?" screen after selecting any quit option. This is vital to ensure the player doesn't accidentally quit the game; for example, in this game, it's possible that the player hits an extra button after failing and selects "Quit" without them noticing.
2. This either needs an option to swap to an alternate appearance of the cues or just change them to arrows, because mentally converting the letters to directions is just frustrating.
3. You should really move the target closer to the end/right, so you give the player the most time to prepare and can catch their misses asap. Currently, the entire right half is wasted be because the player can't do anything about the cues there, and it unnecessarily creates a potential for a delayed fail since the misses aren't counted until they travel the other half of the screen.
4. If you really want a challenge, try to figure out a way to prevent multiple cues from reaching the target at the same time; while it doesn't break the game when it happens, it is still annoying.
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.
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.
← Return to game
Comments
Log in with itch.io to leave a comment.
Is it possible to get the p8 file anywhere for this? That way I could run it in retroarch?
Sorry, I don't think it's possible, unless you can somehow unpack the game file itself and pick it apart.
I lost all the Pico games I had made to a HDD failure not too long after I published this one and naturally I was dumb enough to compile the only game that survived online in a way where you can't view the source code.
Love it. Shame we as society don't have continuation of this.
I enjoy her design a lot. It would be a crime to not make another game with her in it. A shame indeed.
.....unless
Would be great if there was more of a reward afterwards. After completing the game it just felt like "You win, bye". Maybe adding a gallery mode after beating it, a save state (after completing the game), and as previously stated an actual reward after beating the game. Over all, it's a great game and very great artwork.
Yeah. I was in a hurry due to the time constraint so I kept the game very basic and left in loads of faults and oversights. I was entertaining the idea of making an updated version on Godot with all kinds of fancy things in it in addition of fixing bugs, but I've had no time to sit down to properly start coding anything new since the game jam. Should work on fixing that before the next year's game jam begins.
Thanks for the comment, though!
If you improve the game, if I'm able to donate you
Sorry, can't really improve on this game even if I wanted to. The code and all the assets are long since gone. Could always make a sequel of sorts with actually good gameplay mechanics. Don't hold your breath though, even if it's something I've been wanting to do for months now.
After playing this game for a good 15-20 minutes, I must say that it's not the best. It's a good concept but the execution of that concept is dreadful.
1. IF you're going to make a game like this, you need to have the buttons you have to press be more clear, for example the up button actually being an up arrow instead of the letter U. Further more on that is the fact that you can't really see the letters unless you're leaned into the screen due to how they are all shaped, it's easy to get them confused when you're not looking at the colours themselves, D and R look exactly the same if you aren't completely leaned into your screen.
2. Sight reading this game is incredibly difficult to do. The notes move very fast and there's some form of an input delay as well so you only really get a second to react to what's coming, if the button sequence is cursed then you're screwed, especially if some buttons overlap.
3. The entire right side of the target is completely useless. After failing a cue, they should either disappear or the target should be moved further to the right.
4. The game would be a lot better if you could customize the button layout, say for example the arrow keys are uncomfortable to use in this way so you'd prefer using WASD or any other keys other than the arrow keys.
That's all. If some of these things were to be improved on, this game could be a good idea/concept but for now it's simply not fun to play.
The artwork is great though.
Hey, thanks for the feedback. I feel you on all the issues you pointed out. Most of them were something that I had already taken a note of while writing the code, but I decided not to try sorting them out just yet. I've no spare time to put into the project for now and I needed to get the project out for the jam, with warts and all.
Arrows for the symbols were something I was originally going to change before uploading. I knew the symbols as they are now aren't the most readable kind. But, as you develop stuff like this, you get used to the things on screen and become blind to the faults.
The overlapping symbols was an unintended, can't call it a bug, but maybe a coding behavior. I left it in for the most part to make the middle game more difficult due to the lack of symbol variation. What the game expects from you then is to let some of the symbols pass. Essentially if you cherry pick the symbols you can manage to hit in time, you should be alright unless the RNG royally pisses on you. It's not very well explained, but when the symbols hit the right side of the screen, you don't take a hit unless your "score" is too low. I thought about showing the score at first, but then decided to keep it hidden. Roughly speaking you can let as many notes pass as you manage to hit properly. It's a bit of a shitty mechanic, but hey! I was short on time. :D
The right side of the screen is mostly unused, yes. The original idea was to have symbols sometimes come from the right side as well, but the code is such a mess that getting it work reliably for the jam would have taken too much time to fix.
The button layout I think is customisable to a degree before the project is packed. The game is made on Pico-8, a fantasy console, and is very limited in what you can set it up to do input wise. The default keys are z,X and Arrow Keys and I'm not sure if there's any way of changing them from what they are hard-coded to once the game is out.
Most of the faults are from rushed development time. I only had a few days to learn how to code and make a game. The main goal for me was mostly just getting it done, or just getting the game working without breaking. I've never coded a game before so this is all very new to me in many ways.
But all critique is welcome. I might poke around in the game code and fix most if not all of the issues you brought up once I've more time in my hands. The story and dialogue kind of also end abrubtly due to not having enough time, so maybe that'll change too.
This is a good start; great artwork, good concept for gameplay, but there are some issues I noticed.
1. No matter what game you're making, you need to have an "Are you sure?" screen after selecting any quit option. This is vital to ensure the player doesn't accidentally quit the game; for example, in this game, it's possible that the player hits an extra button after failing and selects "Quit" without them noticing.
2. This either needs an option to swap to an alternate appearance of the cues or just change them to arrows, because mentally converting the letters to directions is just frustrating.
3. You should really move the target closer to the end/right, so you give the player the most time to prepare and can catch their misses asap. Currently, the entire right half is wasted be because the player can't do anything about the cues there, and it unnecessarily creates a potential for a delayed fail since the misses aren't counted until they travel the other half of the screen.
4. If you really want a challenge, try to figure out a way to prevent multiple cues from reaching the target at the same time; while it doesn't break the game when it happens, it is still annoying.
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.
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.