Lyner is my first attempt to dive deeper into pico-8.
I am not a coder, so I'm working within my limitations
and trying to learn Lua, amongst other things.
Improvisation is a great teacher, as are the Picozines :)
This is a rough version, in any aspect, but it should
deliver the idea. I figured getting it out now helps more
than later. Next stop: fix bugs and optimize gameplay.
Appreciate your hints for improvement.
Cheers
Patrick
I'm feeling unusually energetic, so you'll be my Advice Victim today.
Um, hope something in here is what you were wanting. :)
PICO-8 TIP
Pick a screenshot for your cart that shows the gameplay. Not many people will even click on the thread unless they see some clue of what kind of app you're posting. Even just starting the game and taking a pic immediately would be more intriguing.
Pretend everyone has ADHD on the internet. Because they do. ;) If it's not a bright, sparkly thing, then mos--oh wow, what has Logan Paul done now?
Sorry, got distracted. Where were we?
GAMEPLAY NOTES
Sounds are basic but it's a retro console and that fits, so you're okay there. The relentless UNNT UNNT UNNT would get on my nerves eventually, so I hope you'll do something with that. :)
You need to remember where other obstacles have been placed so you don't place two so close together that the player just says "wtf" and has to crash into one.
Sometimes when you hit an obstacle, it remains and paces you until a new one comes out on the same level. Probably just a missed re-initialization.
Question: What other game mechanics do you plan?
Having the two sides of the ... conveyor belt? ... move at different speeds might be good.
A limited ability to hop might be good, maybe giving you a fixed number of get-out-of-jail cards. In an old game like Defender this would be analogous to the smart bomb. Actually, you could also offer a smart bomb. :)
Maybe give the player a small amount of ammunition that they can use to fire at a box in front of them to move it forward a bit, maybe make a difficult gap bigger.
Eh, it's your game, I'll assume you have your own ideas. Just thinking out loud here, feel free to ignore this.
A BUG-PRONE CODE PATTERN
(Before I say anything, I'll just mention that I'm going by your comment that you're not a coder, so pardon if I come across as talking down or patronizing or something--I'm just trying to offer tips I always want new programmers to know.)
In difficulty() you have an if/elseif/end sequence to set speed by score range. This is fine, but your sequence ends with an elseif and no else:
if score<=250 then
spd=1
elseif score<=500 then
spd=2
elseif score<=750 then
spd=3
elseif score<=1000 then
spd=4
elseif score<=1250 then
spd=5
elseif score<=1500 then
spd=7
[b]elseif score<=1750 then
spd=9
end[/b]
|
Once past 1750, this function doesn't actually set spd, so assuming it gets called between 1500 and 1749, spd will just remain 9. Might as well take out the final condition and just make it an unconditional else:
...
elseif score<=1500 then
spd=7
[b]else
spd=9
end[/b]
|
This isn't a big deal in your game, but it's a programming pattern that can cause a lot of hard-to-find bugs in more complex code, so I wanted to put it on your radar. You almost always want to have a final 'else' that accounts for any conditions not previously satisfied. Sometimes all it does is assert that you shouldn't have arrived there, but still, it's good to explicitly handle all cases.
PICO-8 API TIP
Beware that almost all rectangles handed to the API are inclusive, which is to say you specify the last drawn column and row of a rectangle, not the column and row where it ends. So where you have this:
rectfill(0,0,128,128,flasheffect.clr)
|
You're actually filling a 129x129 area, columns 0-128 inclusive and rows the same. So if, say, you wanted to fill the upper left quarter of the screen with red, you'd say
rectfill(0,0,63,63,8)
|
As an aside, cls(color) is a shortcut for clearing the screen. It clears to black if you give no args. You're actually doing both in at least one spot:
cls()
rectfill(0,0,128,128,15)
|
Not a big deal in a low-overhead game, but it's possible to run out of cycles pretty easily just the same, since clearing the whole screen does take significant time.
LUA TIP
Minor thing: you need not compare a boolean value to true or false. It can stand by itself.
Like, you need not say these:
if ugly==true then |
if ugly==false then |
You can just say these, which read more naturally:
if ugly then |
if not ugly then |
In fact, any comparison is effectively a boolean value. For instance, to Lua, these two lines produce the same result:
always_true = true always_true = 0<1 |
Sometimes this is handy for eliminating or simplifying if/else statements that end up just setting a flag true or false. Sometimes you can just take the conditional expression and assign it directly to a variable. It's nice that way. :)
Also note that a lot of the time we write an if/else with the two options already sort of ordered in our head, and it's easy to write if not flag then ... else ... end when you could just swap the two bits of code and remove the not.
Another thing it's easy to do, which is actually similar to what I pointed out in the previous block, is to test a condition in the if and then test the opposite of the condition in an elseif when you really just needed an else with no condition.
Here's an example of all of these from your code:
if switched==false then
...code block 1...
elseif switched==true then
...code block 2...
end
|
And here's how it simplifies:
if switched then
...code block 2...
else
...code block 1...
end
|
LAST THOUGHTS
Good gimmick for a retro game. Needs a little embellishing, but it seems like a good foundation. :)
Your code shows more skill than your self-description suggests, especially in terms of modularity. Are you better than you say, or are you doing some of it by cut/paste from samples? It helps to know more about your background and skill level, because then we know where to offer help vs. where it's unnecessary or too early.
Anyway, I just threw out a bunch of stuff that tumbled into my head while I played and skimmed your code. With a little direction on what kind of feedback you're looking for, I and others could probably offer something a lot less random and a lot more useful, so I suggest you spill your own brainstuff into the next update. :)
After a spambot was first to reply to my post, your feedback is far more than I've expected :) Thank you, Felice. Much appreciated.
Yes, I'm aware of them bugs. And I do have more ideas, I'm eager to try out (jumping, shooting and better music included ;). Your advice will definitely help me improve things and get going.
As I mentioned, I made use of various resources to learn about structure and syntax. Also, I used a few snippts (eg. the stars in the background), to not slow progress down to much. By implementing these 'templates', I got a better understanding of what each function does. Beyond all that, working in a small indie studio provides certain basics, too.
On the other hand, I've always considered myself rather bad at maths and related stuff. It's always a fight to get my head around it. I'm surprised to hear that the code is not too big a mess, since it's the first code I've written (in most parts) from scratch. Which makes your feedback my first code review, I guess.
Thanks, again!
[Please log in to post a comment]
