!Lander's weird control scheme explained

[Sophira]

Back when I had my A3000 (from a Learning Curve package), I used to enjoy playing !Lander. But it's only recently that I've been able to work out what's up with the control scheme, and why it feels so weird.

The key to being able to pilot your ship well, as it turns out, is realising that unlike most games that use the mouse for positioning, !Lander doesn't use the relative movement of the mouse to determine the ship's direction. Instead, it uses the position of the mouse pointer on screen - which is of course invisible!

This may not be news to some of you, but I was playing it again recently and had a revelation that this was how it worked, so I wanted to share it for the people like me who had no idea how this worked.

Imagine, if you will, that you had a mouse cursor while playing !Lander and that you also had an on-screen visualisation that looked something like this:

[Updated 26th January 2024: In actual fact, it turns out this image is slightly incorrect. See my update post downthread for a more accurate image!]

As far as I can tell, !Lander uses two factors to determine where the ship should point:

• Firstly, the position [edit: to be more precise, the angle] of the (invisible) pointer relative to the centre of the screen (shown here by means of quadrants, but which in the actual game is more precise) determines the direction of the ship (its yaw). For example, if your pointer was in the upper-right quadrant of the screen, your ship would want to fly away from you and to the right.
• Secondly, the distance of the (invisible) pointer relative to the centre of the screen (shown here by means of the blue/purple/red circle background) determines whether your ship is pointing up or down (its pitch). (Note that this visualisation isn't an entirely accurate representation, but should suffice for this explanation.) If your pointer is in the blue centre portion, your ship will be flying upwards. However, if your pointer is in the red portion of the background, at the edges of the screen, your ship will be pointed straight down! To actually fly in a particular direction, you would need to have your pointer in the purple portion.

In practice, what this meant is that if you ended up in the red zone, with your ship pointed straight down - as was very easy to do - the only way to fix it would be moving your invisible pointer back to the middle of the screen. But the direction you needed to move the mouse to do this in differed depending on where it was on the screen! And if you panicked and moved the mouse in the wrong way, it was entirely possible to stay in the red zone but change which side of the screen the mouse pointer was on, leading to further confusion and probably a (very silent, despite what the second half of the Learning Curve introduction VHS would have you believe) crash landing.

Most games, such as Elite, get around this by only using the relative movements of the mouse and not relying on the position of the pointer. For !Lander, however, this wasn't a thing and led to a lot of woe.

I hope this helps anybody who was as confused about the control scheme as I was!

[edit: Rewording the second paragraph slightly.]

[IanJeffray]

very silent, despite what the second half of the Learning Curve introduction VHS would have you believe

The sound effects there are quite clearly from E-Type.

[jms2]

This is a very helpful explanation. I wasn't aware it worked like that, and I don't recall anyone else commenting on it either. I think most people just thought the game was simply very difficult, not weird. However you have successfully argued that it is a bit strange!

I wonder if it is "fixable", and if so how much better (or not) this might be. I never like the mouse controls in Elite either, and simply reverted to the keyboard.

[Sophira]

I wonder if it is "fixable", and if so how much better (or not) this might be.

You know... you've inspired me.

I haven't really coded in ARM assembler before, but I have experience with other (CISC) assembly languages. I'm seriously tempted to give this a go. I would be very interested to answer this question for myself, too.

...I need to delve into the PRMs. >_>

[sirbod]

An alternative explanation is that Zarch simulates a Joystick using the Mouse.

It uses a 512x512 mouse window, with 256x256 being the centre. It doesn't employ a Deadzone, so the few pixels around 256x256 can cause the ship to point in random directions as it can't determine a precise vector. The position of the Mouse relative to 256x256 mirrors what a self-centring Joystick would feel like. ie the vector from the centre determines the yaw and the distance from the centre determines the pitch.

If you try Zarch on a Pi using ADFFS with an XB360 controller, you'll see it feels quite natural.

[Sophira]

That makes a lot of sense and is doubtless how it was meant to feel. Of course, the big problem with that is that a mouse doesn't self-centre on its own. If the game had included its own self-centre feature (by programmatically nudging the pointer back to the centre a bit every frame) then I suspect it would have felt a lot nicer. In fact that smells like the sort of thing you could write a module to do if it detects that !Lander is running. (I don't know how possible this will be considering RISC OS's cooperative multitasking, but it might at least be interesting to try.)

Something like that would probably vastly increase !Lander's playability all by itself, so I might try to see if that's possible, rather than try to change the game's code itself - unless somebody's already done it, of course!

[paulb]

That makes a lot of sense and is doubtless how it was meant to feel. Of course, the big problem with that is that a mouse doesn't self-centre on its own. If the game had included its own self-centre feature (by programmatically nudging the pointer back to the centre a bit every frame) then I suspect it would have felt a lot nicer.

I suspect that the Voltmace Delta Cat might have been produced with some consideration of these issues.

[IanJeffray]

I suspect that the Voltmace Delta Cat might have been produced with some consideration of these issues.

You'd think, but as I have one here I can say Lander/Zarch are essentially unplayable with this, IMO. Perhaps I've just got used to the way the mouse works in these games though.

[jms2]

(I don't know how possible this will be considering RISC OS's cooperative multitasking, but it might at least be interesting to try.)

I'm no expert, but I think that the game would have to voluntarily release control to allow that to work. As most games run in single-tasking mode, I'm not sure that can happen.

However, I think you can create interrupt-driven effects just like on the BBC, by hooking into event handlers. Not multitasking, but more than just the one thing happening. I think.

[sirbod]

the big problem with that is that a mouse doesn't self-centre on its own. If the game had included its own self-centre feature (by programmatically nudging the pointer back to the centre a bit every frame) then I suspect it would have felt a lot nicer

You'll probably find the game unplayable if you auto-centre the mouse as you'd have to constantly reposition the physical mouse to keep it on the mouse pad. The minute you pick the mouse up - you'll lose control of the ship.

The trick to the game is knowing where your mouse is relative to the mouse centre. Probably a more practical training method would be to make the pointer visible, put a crosshair at 128x128 and have a panic button that re-centres the mouse to 256,256.

A word of caution though. As I mentioned earlier, the ship will point in random directions when re-centred as it loses accuracy on the yaw - it's on my list of issues to fix (in Zarch) as it causes problems shooting flying ships - the best tactic with them is to go into a vertical strafe to avoid them circling.

[IanJeffray]

it causes problems shooting flying ships

Aint no ships in Lander - you're too much Zarch

[pdjstone]

Talking of Lander, I recently found this in the Archimedes Welcome Guide:

Has anyone ever progressed far enough to see the falling rocks?? I'd love to see a video of it!

[davidb]

Yes, the falling rocks do start at 800 points. I'm not sure if I ever managed to shoot any.

[paulb]

Has anyone ever progressed far enough to see the falling rocks?? I'd love to see a video of it!

A screenshot of this phenomenon can apparently be found in this article:

"RISC revealed", Acorn User, August 1987.

I imagine that most people seeing that eventually concluded that it just showed an experimental version of Lander.

[BigEd]

Great digging, as ever, paulb - thanks for the link!

[RobC]

I imagine that most people seeing that eventually concluded that it just showed an experimental version of Lander.

From memory, it really isn't that difficult to get to see the falling rocks - I'm terrible at playing games (and am rubbish at Zarch) but I managed it consistently BITD.

You just have to take care not to be too wild when shooting so that your hit/miss ratio is sufficiently high to rack up points. The same goes for flying around - be slow and steady and line up your targets.

It's a different matter once the rocks start falling though!

[Sophira]

Since Mark Moxon released the disassembled source code for Lander, I've been playing around a bit and there's actually more to this than I first thought.

In the first post in this thread, I said:

Imagine, if you will, that you had a mouse cursor while playing !Lander and that you also had an on-screen visualisation that looked something like this:

It turns out that that image is subtly incorrect. In actual fact, it's more like this:

Okay, so what's going on here? It turns out in the screen mode Lander uses, the mouse coordinates usually range from 0-1279 for the X coordinate and 0-1023 for the Y coordinate. However, after reading the mouse position, Lander caps the X coordinate to use 0-1023. Also, each time you start the game or the game repositions you on the launchpad after crashing the ship, the mouse pointer is set to (511, 511) and treats that as the centre.

However, the game doesn't limit your mouse to this area! Your invisible mouse pointer can still go to the black area - and if your mouse is in that area, the game just treats it as if you're at X coordinate 1023 instead.

What this ends up meaning is that if you move your invisible mouse pointer to the far right, then as long as it remains in the 1024-1279 range at the far right, moving your pointer left or right will not change your direction at all - but the same isn't true of the far left of the screen.

(This isn't a new discovery as such - in fact, sirbod rightly pointed out earlier that the mouse window was square - but my brain skipped over that and didn't really understand the implications until I was able to play with the source myself! Also, it's worth noting here that the mouse coordinates are not the same as screen coordinates - the screen coordinates are within 640x256 (I believe - someone please tell me if I'm wrong), while the mouse coordinates are within 1280x1024.)

[IanJeffray]

in the screen mode Lander normally uses

...normally?

[Sophira]

in the screen mode Lander normally uses

...normally?

Sorry, my mistake. You're right, that word isn't necessary - I'll remove it.

[IanJeffray]

in the screen mode Lander normally uses

...normally?

Sorry, my mistake. You're right, that word isn't necessary - I'll remove it.

Ah. Just wondering if there was some deep hidden multi-mode stuff I wasn't aware of, because also:

mouse coordinates usually range

It's funny how I've never considered the controls "weird", just "sensitive".

[Sophira]

mouse coordinates usually range

My purpose with saying "usually" there was because in the case of Lander, it uses only 0-1023 of the available 0-1279 space - sorry for being unclear!

[ash73]

The control system makes the game unplayable imo. Might be better if the mouse cursor was visible.

I'm used to flying RC aircraft so I'm quite happy using relative controls even when a model is flying towards me, shame you can't switch to that system in the game.

Also would be fun to see it with a lot more tiles now RISC emulators are so much faster.

[MarkMoxon]

Also would be fun to see it with a lot more tiles now RISC emulators are so much faster.

Check out this post and the surrounding thread, which is about exactly that topic - !BigLander with 64x64 tiles looks pretty amazing and runs really fast on Risc PCs and emulators, and apparently you can get it as high as 122x122 tiles.

viewtopic.php?p=418268#p418268

Mark

[Sophira]

One of the ideas I had on how the controls might be made better and that could be easy to program (which I didn't express here, but only on the Discord) was that due to the way the mouse controls worked, there'd be no real difference between the angles on the far edges of the usable mouse area (1024x1024), so wrapping the pointer between the edges might be a viable strategy - so that if you go off the right side of the screen, your (invisible) mouse goes to the left side, and so on for the other sides.

I tried implementing this, and the ZIP files beginning with "W" attached to this post are the result. (WLander.zip is a version of Lander that wraps the mouse along the edges, while WLanderPtr.zip is one that also forces the mouse pointer to be shown in-game, in addition to implementing the mouse-wrapping. As always, make sure you're using RISC OS to unzip these, otherwise you'll lose the filetypes.)

Unfortunately, I don't think this actually improves the gameplay that much - it's still way too easy to accidentally end up in a situation where the ship points straight down, because even if you do the obvious and keep pushing the mouse in one direction, it's too easy for your arm to steer the mouse off-course. In my view, the version that forces the mouse pointer on is easier to play.

So... I'm going to bite the bullet and actually try implementing relative mouse movement controls next, rather than this hack of a solution. That said, I'm curious to know what other people think of this version.

Oh, and for good measure, I've also built a version of the original game that forces the pointer on, but without the mouse-wrapping code, in case you just want to see how that goes. That version is attached as OLanderPtr.zip.

The source for WLanderPtr is available at https://github.com/Sophira/archimedes-l ... wrap-mouse . WLander is simply the same as that source but only using the "Wrap the mouse around the screen" commit, and OLanderPtr is that source but only using the "Show mouse pointer while playing" commit.

[MarkMoxon]

I tried implementing this, and the ZIP files beginning with "W" attached to this post are the result.

These are fascinating! Having the mouse pointer visible makes quite a difference, once you get used to it. I also found that having the pointer on-screen means I hardly ever move it away from the centre, so it doesn't matter if it wraps or not. I'm not sure I'm any better at flying with the pointer, but it definitely makes it a lot easier to recover when things go wrong.

Wrapping doesn't really make a difference to me, as by that point I'm out of control anyway. But I'm a rubbish pilot, so there's that.

Good job on these - it's great to see the pointer in action and how it relates to the flight algorithm!

Mark