This is the cartridge for the platformer tutorial I made for fanzine#2. Feel free to ask questions!
The scrolling can be broken if you stop on the edge, due to there not being an extra piece of platform on each side.
Basically, have an extra block on each side. This happened to me in my port of Joust (Strike Down) that I'll probably port to PICO-8.
EDIT: Not trying to advertise, I'm just throwing my example out.
Thanks for this, it was nicely done! I was surprised that I could turn this into a basic scrolling platformer just by tracking the player position with the camera.
You mentioned some complicated math to smooth out the animation- any links you could share?
so, when we get to the canfall function, I'm a bit confused by the line
return not fget(v,0) |
The zine doesn't explain it as far as I can tell (could be missing it, I tend to miss things) but based on a cursory google search, it looks like in LUA "return" deals with array data, and "return not" would convert a nil value to "false".
Is that what we're doing with that line? Basically, if there's no flagged sprite at that point, "return" would return a nil value, because there's nothing there - so we convert it to "false" so we can use it in our argument?
Thanks, I know this is really old but I thought it was worth an ask.
We want CANFALL() to return:
- TRUE if there is no wall sprite beneath the player (i.e. FGET(V, 0) is FALSE)
- FALSE if there is a wall sprite beneath the player (i.e. FGET(V, 0) is TRUE)
NOT always returns TRUE for NIL/FALSE values and FALSE for everything else.
We're using the NOT operator to invert the result of FGET to a value we want:
- RETURN (NOT FALSE) --> RETURN TRUE
- RETURN (NOT TRUE) --> RETURN FALSE
I hope I didn't make that more confusing...
@tarek no, your statement returned NOT confusing- thank you I understand now. My failing was thinking it was more complex than it is, I should stop letting myself be intimidated by code. Thank you.
If it helps anyone, it can be useful to think of not
as function:
function not(value) if value then return false else return true end end |
Such a function might make more sense with the name invert
or flip
, because that's basically what it does, but in most programming languages we call it not
.
As an aside...
It also makes more sense if the function or expression after not
is named appropriately.
For instance:
function moving() return velocity.x != 0 or velocity.y !=0 end function stationary() return not moving() end |
The "not moving" part reads naturally as what it means, rather than forcing the reader's brain to engage 'read code' mode.
Most of the time a boolean function, that is to say, one that returns true or false, should use an adjective, e.g. paused()
or moving()
.
Often it's best to put a word like is
or can
in front, to differentiate between words that could be confused with another usage, e.g. is_green()
and can_move()
. This is especially useful with methods (object-relative functions) because it reads more fluidly, e.g. car:is_green()
or player:can_move()
.
Basically, when writing code, try to write it so another person reading it can read it as natural language.
[Please log in to post a comment]