I made a very simple FPS controller as a sort of example cart to build off of. This is just to get you going, as opposed to a full framework around which to build a full game. Hopefully it serves as a good jumping off point for someone to make something fun.
It uses player 2's ESDF controls for moving around and SPACE for jumping.
EDIT: Here's a very heavily commented version! Probably way more comments than usually necessary, but it's intended to help you learn, rather than just briefly annotate what's happening in the code.
@kabin30240 The mouselook part starts with this line of code:
poke(0x5f2d, 0x5) |
That tells PICO-8 to not only pay attention to mouse movement, but also lock the mouse cursor to the center of the screen. This means that you can still try to move the mouse, but it will tell you how far you moved it each time, instead of where you moved it to. In other words, we're no longer interested in "where did you move the mouse to?" but rather "how much did you move the mouse?"
And then we take that info of "how far" and turn any horizontal mouse movement into rotating the camera (looking left/right) and turn any vertical mouse movement into changing the pitch of the camera (looking up/down). That's where this code comes into play:
if (stat(38)!=0) then ☉rot-=stat(38)/☉rotspd end if (stat(39)!=0) then ☉pitch=mid(☉pitch_min,☉pitch-stat(39)/☉pitchspd,☉pitch_max) end |
If stat(38) is not zero, that means the user moved the mouse left or right. So we take the amount they moved the mouse (which is usually a big ol' number, like 300-ish or 700-ish) and divide it by another big ol' number that gets it down to between between 0 and 1. A full rotation of the camera goes from 0 to 1, and we only want the camera to rotate a tiny bit when they move the mouse, so that's why we need to divide by ☉rotspd.
We then do the same thing to stat(39), which is vertical mouse movement. But this time we apply it to the camera's pitch (how far it's looking up or down). With horizontal mouse movement, it's okay if they just keep moving the mouse and keep spinning around in one direction or the other. But with vertical movement, we want them to look down only so far. Otherwise, they'll loop around and start looking at the world upside down! And we don't want them to keep being able to angle upward either, or they'll end up bending over backward and also looking at the world upside down! So that's why we use mid() and ☉pitch_min and ☉pitch_max to make sure the pitch doesn't change too far.
I hope that helps! If you have more questions, or questions about the above, please let me know. I'm happy to explain. :)
Mouse code doesn't seem to work at all on my computer - maybe it's a browser bug with pico8? (I'm on Firefox)
🤦 Shows what a good night's sleep will help with... @kabin30240 I just realized you probably meant trouble with using the mouse on the BBS, not trouble with the mouse code. Welp. Hope the explanation helps someone. 😁
BBS does not have the necessary code to request a mouse pointer lock - the feature only works when exporting to HTML.
This thing is really cool, I'll probably try using it for a game some time!
Couldn't you use player 2s o and x buttons to do wasd controls instead of esdf
@kabin30240 Ha, it didn't even occur to me. I always think of player 2's O and X buttons as TAB and Q, respectively, so never even tried W and A. But yes, you could definitely remap those if you wanted. :)
[Please log in to post a comment]
