Log In  


Cart #amiquest-4 | 2023-04-06 | Code ▽ | Embed ▽ | No License
15

AmiQuest: The Game is a BBS compatible multicart PICO-8 fangame (no reload() usage) made for the VTuber Amiya Aranha! Play as Amiya as she explores a variety of platforming levels to find the buckos.

While the game is intended as a fangame, it is perfectly playable even if you don't understand the references. This game was developed over the course of roughly 6 weeks. For convenience, the complete source code is avaliable on the itch.io page.

Buttons:
O: Jump/Menu Select/Level Select
X: Web/Menu Back
PAUSE: Pause Menu (press again to access default PICO-8 pause menu)

Music Credits:
Main Theme: DOVA-SYNDROME - 素直じゃないね恋心
Level Theme: Amiya Aranha - AMIQUEST
Credits Theme: DOVA-SYNDROME - 人狼の為の子守唄

Updates:
V1.2:


-Fixed an issue where the sticky web upgrade didn't contribute to game completion percentage.
-Fixed an oversight where the enemy death sound effect didn't play when hit by the wall of fire in Level 3-3.
-Fixed an oversight where collecting a money powerup allowed you to temporarily go over the 999 coin cap.
-Fixed a bug that caused buckos in Ami's House to show up for the wrong levels.
-Added a sign to the end of Level 1-4 that explains how to exit a level with the pause menu.
-Added a coin trail to a cloud on the left side of Level 1-4, removed a snake enemy that was easy to accidentally jump into.
-Stopped the sprite sheet glitch in Glitchland from flashing to prevent issues with photo-sensitivity.
-Added version number to main menu.

V1.1: Added tutorial text clarifying how to wall jump in the first sign in Level 1-1.

15


3

Wow hot anime girl

Oh yeah the game’s good too, I love how it feels like Mario + Sonic with some differences, I love the music, honestly though I hate the wall-climbing


1

the wall-climb feels wacky, i couldn't get over the wall in the first level. i'm not sure if i didn't get enough height, but i'm not a fan of the wall-climbing


Nice game! I'm sure your oshi will be pleased. Jump upgrade onegaishimasu .
.
.


1

I wonder if people are holding jump while wall climbing, or tapping it? I tend to do the former, and felt it works fine, but I just tried doing the latter and it's possible to mess up the timing and fall. For now I will add a note on the first sign to hold the O button, but I might also look into adding a grace period for people who prefer to tap jump each time so it feels less jank.


1

Not sure why, but I held top-right on the first wall at first and expected her to slide up like a Minecraft spider ¯_(ツ)_/¯

Grace frames for tap wall jumps would probably be better, and for ledge jumps too since there's a lot of ledge jumping to the wall above.

You could also force the PC away from the wall when they're pressing against it and tap jump, which might be easier for players then moving away and pressing the jump button at the same time.

Edit: The cart on the BBS seems to be bugged? I finished the first level but it didn't take me back to the map, which is weird because it was working before. Same thing with dying.


Fixed now, thanks for letting me know. Forgot to update something when exporting and it was trying to load a local cart instead of a BBS cart.


1

ah, i understand the walljump now!


2

I can see the idea of the game but the wall jump is really nightmare!
I suggest making it like this:

  • If Ami jumps and touches a wall while Jump is held, she'll stick to the wall as long as Jump is held.
  • If the above sounds too cheap, have Ami costs her web if she sticks to wall too long.
  • Instead of Left or right, press Up button to wall jump upwards.

    I wish Ami could stick to wall and won't cost anything though.


1

So, I do think this is one of the better games I've played on this site. However, there's a lot that this game does that are pretty egregious, so I'm just going to list off the issues I saw as I remember/encounter them (still playing while writing):

  • the explanation on how the wall climb works is completely insufficient. from what I could tell, it worked best if I held jump and started tapping up the moment I hit a wall, but the explanation doesn't even mention that up is useful.
  • having a small tunnel with a periodically shooting enemy on the other side isn't a challenge. it's a time sink.
  • any form of challenge that is punishing needs to be not only skill-based but also consistent in feel. this means that having different timing on grabbing the thin platforms depending on whether you are facing left or right is bad design.
  • let me also add in that the bottom corners of the thin platforms are nebulous, so jumping toward particularly high ones is a guessing game.
  • paths of coins are traditionally paths that the player can actually traverse. unless there's a glide that the game never told me about, a lot of these paths can't be traversed.
  • if paths of coins are used to indicate safe paths, then they should consistently be a good idea to follow. this includes not having paths of coins that result in just barely missing a ledge.
  • whether the player has to play a level again should be the result of either a lack of skill or the player's preference. it should not be the result of the player guessing wrong about which path would lead to the mandatory collectible.
  • if you're going to start a level with a wall of fire immediately heading for the player, it's courteous to program the movement in a way that allows holding the button to move before the level begins. if that's not possible, don't set up the level make the player need to quickly start moving.
  • having the player guess which direction to go on the wall of fire level is already bad enough, but having one of the directions look like a bottomless pit makes it look like a bug when the player is punished for being wrong.
  • most of the wall of fire level feel like just praying the wall climb won't go wrong for mysterious reasons.
  • having sudden visuals flashing on screen barely ever actually adds to the game. meanwhile depending entirely on the individual player the irritation of such visuals ranges from negligible to completely ruining the experience. as such, doing it as just another gag is a terrible idea.
  • the redlight/greenlight thing just felt like a reason slow down the player and randomly take off hp in the case that one that was just off-screen could shoot.

Thanks for the extensive feedback. I will respond to points by number.

1: Up isn't used in wall jumping.

	if btn(⬆️) then
		if gamestate==3 then
			foreach(signs,check_sign)
		end
	end

This is the code for the up key in the engine, it only runs the check_sign function which checks if Ami is overlapping a sign, and if so, reads it.

2: I don't think the amount of time you need to wait is typically significant, and it does technically add a timing-based challenge.

  1. Unsure what you mean by the timing being different on grabbing thin platforms? That certainly wasn't intentional.

  2. Fair enough, if I update the game I may add a few pixels of leeway to the bottom of small platforms.

5/6. There is one example of a coin trail I can think of in level 2-4 that has this issue, though I did try to keep coins consistent to the jump trajectory when possible. I can't think of an example of an unsafe coin trail but I can look into it.

  1. One regret I do have here is that I didn't make it clear that you can exit out of the level with the pause menu with a sign or something. Playing an entire level over again shouldn't be necessary. There are a few levels I can think of that do lock you out of buckos if you drop down (for example 1-4) which I can understand being annoying.

  2. Fair, though I don't think that's possible as I think it's PICO-8 resetting the hardware state when loading a new cart that's making the button become unheld when starting a level. I probably should've started Ami further from the screen edge and used an obstacle to adjust the timing instead of starting her so close.

EDIT: I might be wrong on this, it could be because the main cart uses btnp. I'll look into if there's a possible fix for this.

  1. My bad on that, I did assume players would have the radar by this point which would be pointing downwards over said pit.

  2. The wall jump is a tough one to fix because it works consistently for me, which tells me there's a mismatch in expectations of how the mechanic works, and that I've done a poor job of conveying how it works. This is probably a problem the project will live and die with as I don't intend on patching it extensively. To respond to the other poster, I don't really plan on making a system to stick to the wall like that, I enjoy how games such as Super Meat Boy for example do a slide down to introduce tension to any given situation.

  3. I thought Glitchland was a fun idea, apologies you didn't find it so.

  4. Fair enough.

If up isn't used that I'm really confused about how wall climbing works. It looked like using up was doing something. In case it helps, I'll mention that what I usually did was hold the jump button the whole time, then on hitting the wall alternate between pressing toward the wall and pressing up.

Regarding the wait times for enemies on the other side of tunnels, the amount of time to wait for one shot isn't big. The issue is that for most of the cases where it came up I had to wait for several shots to pass before the gap between shots was big enough.

The reason the timing is different when going left or going right is because the visual amount of overlap between walls and the player sprite is different.

Regarding Glitchland, I didn't mean the whole level. I meant specifically the part where a bunch of sprites that weren't there before started blinking in unison all over the screen. Most of that level is fine, but that specific way of being glitchy can trigger photo-sensitivity.


The specifics of how the wall jumping works is by checking if there's a map sprite flagged as 0x1 (solid) in the direction you're pressing, and if so, it sets a "climb" variable to true. This variable is checked as part of the code handling the gravity, and while you're pressing into the wall it lowers the gravity variable (thus making you slide down the wall slowly) and resets the jump timer. So, if you're next to a wall to the right, you jump into the wall holding O+right, then you alternate left and right while holding O (as I put in the first sign to clarify,) you will jump up the wall. I felt it controlled intuitively, but I was obviously mistaken.

The reason up would've "worked" is then because of how the wall jumping is programmed, you stopped holding into the wall, which reset the jump timer and since you were still holding O, executed a wall jump.

I didn't think of the photo-sensitivity thing and yeah I might slow that effect down or just remove it.


3

I did it! I have completed the game!
I think the PICO-8 pieces, filled with ideas as the creator himself would want them to be, are worth playing.

There are a couple of things I found difficult when it came to precision action in this game.

  • The character's height may be different when landing on the ground, making the jump predictable and unstable.
  • That it always runs at 30fps. (I wish it was _update60() at 60fps)

I would like to keep these points in mind when I create a platform game.


(The unusual control method may be an against the rules for experienced players. But it should be a new experience. It is enjoyable enough.)


was wholesome game



[Please log in to post a comment]