[MrD]

Originally Posted by lilalurl

Tested on a slightly customized A1200 setting in Winuae.

Works pretty fine. Rank S on level 1 (not a first try ofc).
Level 2 is a bit difficult but I think I can manage to finish it after a bit of training. Level 3 I am not that sure if I can ever finish it.

Congratulations! A secret golden cat medal well-earned.

The other levels are hard, but there are multiple routes on Level 3 depending on how gutsy you're feeling. I've watched first-time players get A, B and C on Levels 2 and 3.

Small suggestions would be some cosmectic stuff (not mandatory) like a thruster effect/trail and changing the music. The music played once the box is picked up was OK but I must say that the main music has something that makes it inappropriate for cave flying IMO. Perhaps because it has some high-pitched spikes?

Thruster trails would be nice, but they're low on the list.

Music is totally temporary. Totally, totally temporary.

Now for the main feedback:

- You can get out of the level boundary in the first level on the right side. If you fly far enough off-screen (I also flied up after that so not sure if it had an impact), something like 10 seconds, you can manage to get yourself stuck forever (you can still move the screen vertically). Perhaps I rotated without noticing it though.
You can do the same on level 2 (on the right of the location of the box), but somehow, I did not get stuck out forever.

Yeah, the sky doesn't have a collision boundary to it. If it did, you could bounce the box off the level edges and I thought that would be unfair. I figured the only reason why anybody would want to fly into the sky would be to look around and waste time, except on level 3 where it's not made 100% clear where the exit is (though you DO start right next to it, and there are two giant arrows pointing to it).

-Not sure if you can do something about it, but sometimes you are stuck and yet it does not look so. For example in level 3:
Thrusting forward did not help while visually it should have.
Rotating a bit to the North allowed to get out of it.

That particular wall is awful and I apologise. There's two overlapping collision polygons at the very bottom edge of that wall, which means there's an invisible two pixel sticking out part at the bottom where the ship is in your image. I need to go through all the levels and move some of the collision areas around. Tiled isn't a great tool when it comes to precision; the polyline tool doesn't show the pixel numbers and it uses great big antialiased blobby lines.


It looks right, but as you've found out, it's not.

- Is it normal to have to press the fire button to get the rank displayed? Once you finish the level, the first two parts (Elapsed... and Box...) get displayed automatically, but the rank only appears after you press the fire button. I don't see a reason why.

That's odd. It isn't programmed to do that, the results screen is all frame-counter based. Fire isn't checked at all until all the text has appeared. If it's only appearing when you press fire, that means you're just pressing fire at exactly the same time the final line of the results screen appears (with the total time, the press fire caption and the rank icon).

It's possible that there's some odd glitch there but if there is and it's affecting only the rank icon that means that the bottom right quarter of a playfield isn't being displayed... (the text and the rank insignia are on the same playfield).

- Would be nice to have a life bar or counter for the box. Useful and also it could add tension when you have it almost destroyed, are near the goal and have a difficult obstacle to negotiate.

That's true. After seeing how awful the box explosion ran on a real A500, I decided to step back from adding more drawn things on the screen.

I'd considered a proximity alarm that beeps faster when the box gets closer to the wall, or a health indicator that beeps faster when the box is damaged, but audio is hard.

- "If the box gets stuck, detach from it!"
The suggestion will depend on how you consider the collision detection of the game. But if it is possible that it gets stuck indefinitely in a wall or an obstable, then a key to have it auto-destroy could be useful.

Perhaps in such a case it is supposed to receive damage while being stuck and therefore automatically destroy? I have not tested thoroughly. However, I tried to let it on the ground for a while and it did not get destroyed. Therefore in case it can get stuck in the ground that could be an issue.

I've not seen the box get stuck 'in' the ground. I've designed the collision detection so that neither the ship nor the box should ever enter the ground, and definitely not try to travel through it. If the box is stuck, it would be because there's a sticking out object between the box and the ship when the beam's on, like you're trying to drag it through a crate. The box will repeatedly make tiny bounces off the crate rather than slide along its sides and that's what makes it explode. That also means if the box does get stuck in the ground somehow, trying to yank it out will blow it up too.

The ship does sometimes (hopefully rarely) get stuck on walls, and the only way to get it out is to try and make the exact reverse course that got you in there. I have to go through the collision polygons pixel by pixel and find where these things happen.

A suicide key would need keyboard access and that's a problem. I could use the mouse, I suppose.

- "Your ship is indestructible"
Pretty sure some people would be happy with a hardcore more where you have a life bar/counter. Perhaps some would even want a one hit point wonder (I know I would not):
http://tvtropes.org/pmwiki/pmwiki.ph...HitPointWonder

That is a reasonable idea, but it would require absolutely infallible collision detection. I wouldn't be able to make a one-hit challenge to players if I knew there was a chance that the game wouldn't be playing absolutely fair. As it stands there are certain passages that are one tile wide (like the pipe on the left side of Level 2) where precision is essential.

- Implement a key to suicide/go back to the main menu.

Yep. Main menu key is important.

Up until about five minutes before I uploaded, the mouse was used to directly move the camera for debug and the buttons were used to instantly quit to shell. Without those functions included, I could use the mouse for this too.

- Since the levels are quite large, perhaps you could think of a second game mode that would include additional boxes. One of them (at random?) would be the correct one and the others being just fake, although you could only determine that after bringing it to the goal.

Random boxes? That would make it impossible to compare times with other players.

Or perhaps put some bonuses or whatever. Anything that could interest the players who like that to explore and make some trade-off between the time wasted and the benefits.

I think that's outside the scope of the game. If you want to fly around to discover hidden messages at the edges of the map or race around in circles, play Gravity Force 2!

Thanks for the useful input!

-

If there are any Amiga gurus reading, I would like your advice on the following:

Keyboard access. For a simple puzzle game on the C64, I used the kernal functions to read keyboard input (restricted to one character at a time). Is there anything as simple for the Amiga? I read elsewhere that reading the keyboard wasn't as straightforward and that it required a handshake or something along those lines.

Disk access. At the moment, GB is a standard Workbench-formatted disk, that has a startup-sequence that loads the GB executable. Is there a simple way to access files on the disk without writing my own loader? C posix style routines would be smashing (but knowing my luck there's no such thing in the rom, or it doesn't work with Forbid).

Fast clearing. I'm using the dual playfield mode for ingame, with the tiled background on one field and the ship, box, links and text on the other. I'm not using the hardware sprites at all. To draw the sprites, I calculate their position on the sprite playfield framebuffer and invoke the blitter. I then store the calculated blitter (bltsize, bltdpth and bltdmod) parameters on a stack. To clear the sprites for the next frame, I grab these values back and use the blitter again with d=0. Is this a good idea? Or for small sprites (like the three dots connecting the ship to the box) is this daft?

Drive motor/light. I have no idea why the drive light stays on while the game is running. Is it supposed to do that? I haven't touched the drive in my code.

Any documentation or example code you could point me to would be most appreciated. The game is based off the simple bitplane example in the Abacus ASPG, using Forbid - Permit to suppress task switching. This is the version of vasm I'm using.

vasm 1.5a (c) in 2002-2011 Volker Barthelmann
vasm M68k/CPU32/ColdFire cpu backend 1.2a (c) 2002-2011 Frank Wille