It's interesting to see another approach to a tiny shooter. I managed 141 points, but I'm not really sure what the best approach is. It seemed like sometimes the green ones took a couple shots and other times only one, and I'm not sure why.
Recent community posts
I can see a couple spots where some characters could be saved, though maybe not enough to add back in anything.
You've got 4 lines for movement, each costing 13 character, plus the base cost of using substitution on the function, for 57 total. Compare that to using btn with bitmasking: "v=btn()x+=(v&2)/2-(v&1)y+=(v&8)/8-(v&4)/4" is only 41 characters. This assumes you aren't preventing the player from going offscreen of course, but I don't think your game needs that.
Your conditions seem inefficient as well in a couple places. I'm not confident, but I think "t()%2" can only have 0 or 1 as a result, so rather than "==0" you could use "<1". Also there's a "b==1" and I'm not sure where b could be given a value that isn't either 1 or nil. If those are the only values, "==1" is redundant.
Other than that, I think there's a few places you could save a character or two by re-ordering the statements that don't depend on each other. "g,h=n,n b=1" could eliminate the space by putting "b=1" in front. Similarly, "j,k=-4,n u=1" could be "u=1j=-4k=n" to save 2 characters.
I got to world 12 once, but I think that's about as far as I can get before the rng hands me either instant game over cause spawned in a wall I guess or too wide an open space with too many spread out enemies.
The most effective strategy seems to be to line strafe when ever able to get vertically or horizontally aligned while letting the enemies ram into your shots. When that's not viable cause stuck with too many at an angle, just twirl around and let shots hit whenever they can. Also the enemies going through walls seems to be the player's best boon.
Tip to anyone else who tries this: don't bother letting go of the shoot button.
I was liking the game at first, but the moment the screen flashed, I scrolled away. Going from a screen full of black to a full screen of white and back is a really drastic change that definitely should have a warning.
I would be very surprised if it were possible to fix this within the code limit, but while I was playing an egg spawned in the middle of the snake, which caused it to get eaten a moment later but not spawn another egg.
This game is very interesting. I beat it on the first try, but then I wasn't sure if there was some level progression due to how quickly the game restarts. Then on the second try I ran into a dead end. Third try I realized that I could turn around by just waiting long enough.
My high score is 21328.
I've gotten the impression that the pico-8 community has very different preference than me, so I won't comment on what I did or didn't like in your game. I will say this though: if you make a game with a goal of just getting as high a score as possible without the gameplay ramping up to absurdity, make the points gained as small as possible. That minimizes the chance that some jerk like me is going to come solve your game and repeatedly break the score counter. If that score seems off, it's because I hit the maximum pico-8 integer value twice.
For anyone who reads this wondering how, the safest spot is right next to the laser, moving diagonally is faster than moving straight (cause not enough code space for properly multiplying by square root of 2) and if you pay enough attention you can tell which of the spawning circles will make it in time to not be hit immediately by the laser.
Depends on engine/libraries/coding ability I guess. If you don't have the option of using neat tricks to compress things, then a concept that allows rectangles and lines and such as characters works. In that case, it could a simple platformer with a silly gimmick (flipping gravity on the fly while barely ever touching the ground) could work. A simple dungeon crawler with barely any story (ie. red-rectangle needs to save blue-circle from an army of black diamonds with their line-segment of hurtfulness) might be good. Alternatively, using ascii instead of shapes or images has a vast history, and still supports any game type that has an arcade-ish feel.
If image compression is an option, then it doesn't take much to make a visual novel or jrpg. I'm currently looking at the option of a pokemon clone using RLE-encoded tilemaps for the environment and normal view of characters alongside simplified vector art that gets rasterized at start-up for the sprites and portraits. That opens up any 2d genre as a possibility as long as the game isn't too long. Even a point-and-click adventure would be an option.
As for the concepts and themes, I'll just mention, in response to your phrasing, that particle systems and decals are a great way to show blood and gore with no or almost no images. I would suggest "thomas was alone but with blood", but I guess that's just super meat boy.
Perhaps a clarification of that term is needed. "Runtime" does refer to the time when the program is running, but when talking about included files, it's usually short for either "runtime system" or "runtime environment". When any program is run, the executable does the basic setup for the type of executable it is, followed by loading anything that the executable lists as required to run. Usually some of what's required is included in the OS's files, especially the "kernal", but not all of what's required.
To give Pico-8 as an example, this game I exported with version 0.2.1b a while back has a windows distributable that includes the optimized .exe file, a data file, and a mysterious version of SDL2.DLL. Since the .exe file loads the DLL file at the beginning of its runtime, it would be counted as part of the runtime environment. Thus, the game's file size is the total of all 3 files, not just the game data and the exe file.
Also, I'll go ahead and mention that the pico-8 IDE is too big (around 20 MB) but it looks like a windows distribution is only 2.83 MB on disk, so you should be fine using pico-8 as long as you export a stand-alone distribution rather than the cart (look up export in the readme if you don't know how). More generally, if you're not sure if a file is part of the runtime, move it out of the game folder temporarily and see if the game runs without it. If not, it counts.
The Mystery of the Room is an experimental puzzle game based on a simple concept: what if the puzzles have already been solved? The player is presented instead with two goals: 1. figuring out what the solutions were from the muddled state each puzzle was left in and 2. learn why the puzzles are there in the first place.
Be warned, though. There may be sinister things lurking under the surface.
This is drifting off topic, but I feel this is rather important to point out : that's not what "royalty" means. A royalty is a payment for continuous use of something. It is not payment for initial access or initial modification of the thing. That's why they tend to be percentages of the profit of a larger commercial work. GPL allows charges for modification and distribution but it definitely doesn't allow charging for the actual use of it.
Also to clarify since I'm replying anyway, I meant that implication in context. It is completely pointless to require payment to digitally access a GPL work, since the person then can just release the work for free themselves. The reasons one would want to require payment for access are either because a physical copy always costs money somehow to create or as a symbolic way to charge for the service to the community at large, neither of which apply here.
I think you should put more consideration into the level of pixelation in your visuals. The character creation currently makes the character always look bad due to the size on screen, which is only made worse by the background looking so crisp. Also, the dialogue text looks like it's half as crisp as the text for who's talking, except when highlighted.
When first looking at the quest menu during the tutorial, I was momentarily confused, because it wasn't clear that I was looking at a menu. I think it was because I hadn't received any mention of how to leave a menu, so I wasn't in the right mindset. I suggest putting in a small bit of text mentioning that escape goes back, partially for that reason but also because some game quit in response to pressing escape. It's good to make it clear that your game doesn't.
When the warp rings were misaligned, I had trouble finding them, because I didn't realize there was a doorway downward from the fuel room. I think an indication on top of the walls of what sort of wall they are would help with that.
When I reached the first planet, I had the diagnostics menu up due to just exploring what was there. I'm not sure if that's why, but the menu disappeared without actually leaving the menu, resulting in the game not being responsive.
I wish GMS2 would pause while not focused. I think I made the initial warp attempt harder because of trying to type up feedback while time was still passing.
I think having a freeze-frame when the agent is spotted would've helped. I got to a part where getting past a guard requires dropping down into another room, and I can't tell what's going on. The moment I drop into the next room, the game claims I failed.
Tried two times. I got all the coconuts, and I think I got all the achievements on one of the two runs. It's harder to remember them when they're inconsistent in tone though. (Bullying Mugwort is bad, but making Mellow angry is good?) Other than that, everything is intuitive, so I think this game is better than the Dizzy games I've tried.
The controls are intentionally slippery. I was aiming for about the level of Super Mario World. Ideally, the main challenge would've been dealing with the momentum, thought the levels don't really support that.
Using HTML for the documentation is definitely a better choice. The headers actually working makes it a lot easier to ignore parts too. That said, I'm not really sure what else has changed that would relate to my original complaints.
If you meant that "giving it another shot" in the sense of just seeing again if I want to use your engine, then I suspect you've misunderstood. The complaints I started this thread for were the things I would expect to make a lot of people in general have trouble with your engine. They're not at all the reasons I haven't been using it. My reasons for not using it start with the suspicious absence of any documentation or modules that address the game window. Anything I make will be targeting PC first and foremost, so not having a clear way to provide fullscreen mode, windowed mode and some form of resolution persistence is a deal-breaker. I also prefer if my games remember where the window was when the player closes the game, with some safety check to ensure the window isn't stuck off-screen.
I don't like the 4th level. It feels off from the rest in how dangerous and how precise the platforming is. Further, it feels like it's designed to make the player have to backtrack, which is irritating. The 5th level feels that way a bit too, but it's not a problem to backtrack for a bonus item, in my opinion. However, the 5th level also feels out of place in a different way: it feels like it would've needed more levels leading up to it. The solution for dealing with the pit of spikes requires more comfort with the mechanics than I would expect the player to have at that point. If you do choice to continue working on this, I would recommend both of those levels being moved to later in the game. I would also recommend introducing spikes in a smaller way.
Those two levels sit in contrast to the first 3, I think. The initial tutorial is excellent, though I may have missed any mention of which button is jump. The bigger thing missing, I think, is a way of learning and getting a feel for how the rate the time power goes down is determined. I had the impression at first that it was always the same, then only later noticed that it seemed to be different sometimes.
Overall, I hope you do finish the game at some point. I think pixel art games are never a bad thing, and I think there's a lacking of platformers with cute bunnies and interesting takes on the mechanics.
It's possible I didn't make the areas for interacting with the cat well enough. It's supposed to fling you downward into the wall when you pet it. Anyway, thank you for the detailed feedback.
I scared some birds away, then I scared some ground animal away. Then I jumped into a bird to scare it away, got stopped by its hitbox, and fell on top of the worm. Was that intended? Cause I don't see any way I could've saved the worm in that case.
I don't see much benefit in trying to avoid healing the enemies. It just results in having to do much harder dodging while shooting the enemies themselves less. Meanwhile simply shooting like mad will have a chance of destroying stuff while allowing staying still against shot patterns that usually miss entirely anyway.
I think having something really important be off to the side in a bullet hell game is a bad idea. It means the player has to constantly be changing where they're looking rather than just focusing on the action.
The in-game instructions don't make it clear needs to be done to win. It mentions chores but not what those chores are.
On the side of distribution, Game Maker Studio has options for what form of build to make when you build the executable. They're in the dialogue that pops up when you name the file. I recommend using either the zip file option or the single executable option so that players don't have to go through installation. Furthermore, there's no point in making a .rar archive out of your game if said archive isn't going to be smaller. All that does is weed out people who haven't installed something like winrar or 7zip.
I don't know much about setting up games in browsers, but for whatever reason it ended up very small in my browser (chrome, on windows, with a 1377x768 resolution screen). As a result, the detailed textures didn't look very good and the text was hard to read. The actual gameplay wasn't affected though.
I think next time you make a game, it'd be a good idea to consider how much content you have in relation to how long you make the game. This game appears to be just dodging arrows at the same rate and of the same type for quite some time without variation. The dodging itself is fine, but it's not interesting for as long as it takes to win. This is made worse by the scrolling background being the same the entire time. As such, I think it would've been better to keep the game a little shorter to compensate the lack of time to make more variation. Similarly, if you decide to do any updates to this later, I think even so much as allowing there to be 2 arrows shot at once later on would improve the game.
I like this concept, but there's several parts I didn't like in practice. Like other commenters, I didn't like the camera movement. I think this would've benefited more from have the dog being the parent of the camera and crafting the dog's movement around a comfortable speed/acceleration instead. Besides that though, the items were constantly too close together. I think having them be thrown off from defeated orcs would've made it much easier to grab individual items. Lastly, it feels oddly subject to RNG. I got to level 2 and failed almost immediately because no health potions were dropping at all.
All that said. I do think the visuals are surprisingly functional given how clustered together everything is inevitably going to be in a game like this.
I think it would've been helpful to have markings on each bar to indicate how full they are. They wouldn't need to be real measurements, just something as a stand-in for number of seconds so that the player can better get a sense of how fast to count.
The game's resolution turned out to be too big for me to see the menu properly, and some of the story text was cut off, but the puzzles had no problem. Some of the specific box arrangements felt nostalgic. I was reminded of Rescue Rover as well as one of my first game projects way back when too. I don't think I've seen height difference used for box puzzles before though. Good job on that innovation.
This game is great, but only after the initial wall of scrolling text is over. If you do any updates after the ranking period is done, I would recommend putting that information somewhere in-game as reading material, such as on a table as an "old informational pamphlet". Having it all scroll by at once like that is very intimidating, and especially having it scroll on its own with no player input encourages the player to not actually read any of it.
Similarly, I think having the website be displayed as a line of narration at the end would be more convenient. Not having the text move would make it easier for the player to type it into their browser and/or write it down. Putting the link on the game page would also be a good idea.
I don't have anything to add on the game itself, especially since it seems like the other commenters are more into this type of thing than me. However, I would recommend in general when using Unity that you post a downloadable version as an alternative to any web version. I had multiple issues that seem to be related to my computer just not being very good, and such issues are usually worse in a browser.
In case I'm wrong about the cause, the issues were as follows: 1. the game didn't seem to go beyond the instructions screen on the first try. On reloading though, it appears that it was just having trouble loading. I've noticed unity games sometimes take a huge time to load on one try and then no time at all on a second try, which worries me to no end for technical reasons. 2. the plants were refusing to grow at all, even after minutes of watering. The issue went away after pausing and scrolling around the page, though, so I think the game just was having trouble loading the models.
If no one else complains about these issues and you can't think of any reason for them, I wouldn't worry about them.