So I'm just another old school gaming enthusiast who loves to make games for fun. I stumbled upon Pico-8 and I got so amazed by the concept that I decided to learn programming. I have made some mobile games before but I used Construct 2, which provides a set of widgets and tools to create a game with just a little knowledge of coding.
However, after 2-3 weeks with P8 I got into to this situation where I'm wondering myself if I want to learn coding by making a tiny game or just want to have fun while making a tiny game.
I'd love to say both but for me, it depends of how "intuitive" is to communicate with the hardware through a programming language (that's the reason why languages exist) but at this time it is not. There are a few things that should be easy but for some reason I just can't get to understand, like:
- Rotate a sprite by 90 degrees in order to recycle sprites on top view games instead of having 4 different animations for each direction
- Simple stuff like understanding how to handle arguments within functions or tables
It's Worth to recall that I'm an absolute Noob on this matter and sometimes I feel that my brain is just not compatible with programming logic :(
And yes, I have spent days trying to understand the amazing pieces of code from the community and I have learned a lot, but there are some little things that I havent't found anywhere on the web that could help me and other newbies like me to find a balance between designing a game through graphics and music, and making it work through coding. I have created this topic to share these "silly and basic questions" by non-programmers :)
Hey man don't get down over it! :) Noone's brain is compatible with programming logic. Machines are very logical and can do things very fast. But they only can what you tell them to do, the way you tell them to do it -- versus what you 'want' them to do.
As you get more experience, mess around, make mistakes, figure out how to fix mistakes, etc., that's how you level up your ability. It's the best way to do it. Don't ever be afraid to do something wrong or to mess up -- guess and check is the only way you'll ever make progress, especially at first. Over time, you'll develop a sort of mental toolbelt to solve common problems, but the first time you encounter a problem.. you're probably going to have to guess a lot. And that's 100% fine.
The big skill with programming isn't learning a language and its features. It's developing the ability to take "what I want this to do" and turn that into a series of smaller and smaller steps, until its been broken down into what you know how to do. Paso a paso.
For rotating a sprite 90 degrees, spr() has a parameter built in for that. Here's how it shows up in the manual (https://www.lexaloffle.com/pico-8.php?page=manual):
spr n x y [w h] [flip_x] [flip_y] |
How you would type that in code is like this:
spr(n,x,y,[w,h],[flip_x],[flip_y]) |
The parameters mean:
n - the sprite "number"; what shows up in the sprite editor next to the right of the tools when you have a sprite selected. They go from 0 to 255. x - the x value of the sprite -- "starting at the left side of the screen, how many pixels to the right should we start drawing this sprite?" y - the y value of the sprite -- "starting at the top of the screen, how many pixels down should we start drawing this sprite?" [w h] - width and height. The [ ]'s mean that it's optional. But since they're both in one set of [ ]'s, it means that if you include one of them, you MUST include the other. The width is how many sprites wide we should draw, and the height is how many tall we should draw it. The default for both is "1". Which will draw one 8x8 sprite. But if you have a 16x16 sprite, you could use "2, 2" as your width/height. [flip_x] - should we flip this on the X axis? If it's True, then it will show up mirrored horizontally. If it's False (the default), it shows up like normal, so the same as it does in the sprite editor. [flip_y] -should we flip this on the Y axis? If it's True, then it will show up mirrored vertically -- "upside down". If it's False (the default), it shows up like normal |
Hopefully that makes sense. If not, let me know. To 'rotate' your sprite at 90 degree angles, all you need to do is to use those flip_x and flip_y parameters; by setting them each or both on/off, you can display any of the 90 degree rotations of a sprite.
Functions/arguments work the same as spr() -- spr /is/ a function, it's just one that's built-in and already defined for you. But you can also make your own. Here's an example of one that adds "1" to a number:
function add1( number )
return number + 1
end
|
"number" is a placeholder for whatever gets put inside the parenthesis when you write "add1( 5 )" <-- so in this case, "5"
The "return" part means that if you do this:
x = 10 x = add1(x) |
then it will set the variable on the left side of the '=' to what that "return" ends up being. So in this case, you're setting x to 10. Then you're setting x to the result of the function "add1(x)". Since x is 10, doing this operation will make "add1" return "10 + 1" --> "11". So it will set x as "11".
But you don't have to use x in both places -- this also works:
z = 10 x = add1(z) |
That would set x to 11 as well.
As would this:
x = add1(10) |
So yeah, don't think of it as a choice between "learning coding" and "making a game" -- you're developing the skill /by/ working on a project (a game, a utility, whatever). That's how you get better. Just like with any other skill/art. Don't get discouraged! :)
Start small. Fail often. Fail fast. Learn what you don't know yet by finding the gaps in the things that you can't do. It really just takes time and a passion/commitment to making your idea.
Honestly I found that the easiest way to learn was to read game dev stuff - to get the idea of what I need to do/think about. Then get in and make it dirty. Make the mistakes. Get it to work. Optimization and making things better will come. Mostly when you realize that you buggered something up, or you have so much going on for something so simple and your experience has shown you a better way.
And while I am on this tangent, a bit about design and development. If you want to work on the development side and programming of a game, try cloning a game you know inside and out that is easy enough for you to handle. Atari 2600 games library is a good place to look. c64, spectrum stuff.. etc. This way the design notebook can stay closed. The amount of work, energy, and thought that goes into design is equally heavy in its own right. So for starting, pick a side. Design it, or develop it. If you design it. You are notebook bound. Where on the other side you are text editor bound and jamming code.
Yesterday in game dev - the things I know how to do.
Today in game dev - purposefully improving/using what I know how to do.
Tomorrow in game dev - fill the holes of what I need to know how to do.
Oh, I forgot in this mess somewhere another kernel. "Don't forget to have fun, and enjoy making your game." "Don't beat yourself up." "Think it through."
Yo! It takes time man. Ya just gotta keep working on it! I studied game programming at uni for 4 years and then made many little practice carts in Pico 8 then forgot about it for like 2 years, then came back to it, then made a couple ropey ass carts with glaring issues, then figured out the tools to improve those issues and now working on The Next Thing. And this thing won't be perfect either but I will better learn how to make the next next thing.
Point is like anything you get out what you put in. Programming can be hella frustrating. But it can also be hella satisfying when you pull something off or fix an issue you've been struggling with for more than 2-3 weeks.
Keep going as long as you're enjoying it. It will take a long time though - that is not unusual in this space.
Wow, thanks for all this! Nothing better than making mistakes and learning from them, that's what really encouraged me to keep this "P8 quest" despite the odds and of course, encourage and inspire others the same way you guys did here :)
For example @enargy, there are some little details that made me understand functions better than ever, because you explained the way the function is intended to communicate its arguments to the console and the reason why the "[]" are used. It could sound obvious for someone related to programming but for me it reveals a lot of possibilities.
As soon as I get to find my own way to resolve this basic sprite movement challenge I'll post a quick guide with my findings. And @Rahrahrah, thanks for reminding me to have fun (after 4 hours of trial and error the headache was pushing me to forget that :p)
Let's keep rockin'!
Actually I have just a quick question regarding rotation after using the spr and flip_x, flip_y settings. I got to mirror the sprite by changing the flip values (true, false) but rotation requires an angle to perform so the sprite reflects over its axis (x,y) but it doesn't turn, is it possible to do so with the spr() function?
Yeah I've also been annoyed by not being able to rotate. I'm sure there is some method you could write but I dunno it. For now you're probs best off drawing a second sprite. (If anyone else knows that'd be nice!!)
However you only need two sprites now - a walking left sprite you can flip for walking right, and a walking up sprite you can flip for walking down. So it'll be good sprite practice :)
In the sprite editor if you highlight a square section with the select tool and press R you can rotate the image so you don't have to re-draw it.
If you really need to rotate a sprite by an arbitrary angle, see my rspr variant at the end of this thread:
https://www.lexaloffle.com/bbs/?tid=3593
Reference material:
http://www.drdobbs.com/architecture-and-design/fast-bitmap-rotation-and-scaling/184416337
(and don’t complain that is not noob stuff!)
Hardware of the type PICO-8 is pretending to be would not have supplied 90-degree rotations, so it's not surprising there's no hardware-like runtime feature to do so.
Still, you really only need two sprites to get the full range of cardinal directions and flips when combined with the "hardware" flipping:
That being said, I'm not sure it would be overly unreasonable to request a rot90 param on the draw call. Or, more technically, a flip-diagonal flag.
Thing is, zep is hesitant to accept incremental upgrades like this, because if you keep making reasonable incremental upgrades, you do eventually end up with something unreasonably different from what you intended to make.
That would be useful from the game design perspective because it would save a lot of time and code (no need to create a set of sprites for each direction and the math to turn vars into angles). I'm amazed by the outstanding things that people create around, but making things rotate in my opinion is an essential feature to control movement that could improve several things around the game creation process in general, don't you think?
I'll dig into these solutions and post the results soon, it feels great to understand why the tools are being created for :)
It would make things easier, yes, but lots of features would make things easier. The point is to work within the limitations.
The fact that PICO-8 has flipping seems extravagant to me. :)
PICO reminds me of the Commodore 64 days ... no flipping or rotating there and people made TONS of games for it.
Weeelllllll, true it wasn't on C64, but I'd say it suits a game console of that era. NES had sprite flipping. Not diagonal--not even SNES had that, IIRC--but it had h/v flipping. So it's a feature I'd consider "in bounds", so to speak.
PICO-8 is usually like the union of all possible features on all consoles and computers of that era, I'd say. Plus a few that zep really shouldn't give us if he wants to be accurate, but which honestly let people produce better games while still being limited in scope, so I don't complain.
That distinction, btw, is why I'd be on the fence about a diagonal-flipping feature if it were up to me. I don't think it'd give people more capacity, really. Maybe it'd save some sprites in the average cart. So technically they might effectively get more (sprite) RAM out of it. Mostly though it'd just be a quality-of-life thing, which I usually support. It might also allow some cool effects for demos and tweetcarts.
I'm just not totally sure in this case.
Luckily, I don't have to make the decision. Well, sort of luckily. Yeah, luckily. I'd agonize over it. I'd rather just shrug and let him decide this one. :)
You guys have a strong point regarding the limitations (which are part of the magic of creating games ni P8) and the fact that these old time consoles got to sort things out by just tweaking the available features (x,y) to create other behaviors. I'm totally comfortable with that, bigger challenges=more changes to learn.
However if you consider that you have to create a set of variables to simulate an evironment for your game, you have to create things like gravity, friction, speed, acceleration, etc. to actually control the bevahior within x and y movement, but the angle (which is very important for movement overall) is kinda missing, or let's say you have to make a few operations to simulate movement towards an angle and thought that it should be as simple as the other environment variables.
Just a thought, sort of "nice to have" reasonable function ;)
@Birdstonelabs have you encountered this tutorial series? It seems to me if you're new to programming, this is an excellent series. It's what sold me on Pico-8 (though I was already an experienced coder) https://www.lexaloffle.com/bbs/?tid=28030
It may also be something where you may be accustomed to working much more quickly in a game creation tool. Coding will slow you down some (depending on what you are doing). You'll have to learn to enjoy putting smaller pieces together than you're accustomed to. If you can cultivate a sense of joy from building small pieces of a larger puzzle you'll be well on your way to getting more coding under your belt.
As for Pico-8 having physics and such built in, my impression of the project and its intent is that that sort of thing would be considered outside the scope of the project. However lots of folks are producing code libraries for these things that you could drop into a Pico-8 project and use. 3D libraries, physics libraries...they're around. I haven't used them myself because I get too big of a kick out of doing all those things by myself, that's kinda why I like Pico-8 to begin with. It reminds me of coding in BASIC in the old days. Simple language, but if you want to do something interesting it's all up to you.
@Birdstonelabs - Yeah my bad, 90* rotation isn't possible with just h/v mirroring. Oops!
There is a trick that may help you lower the number of sprites you use.. if you have things that are symmetrical, you can do stuff like paint half of them, then flip that image and draw the other half. And it only takes up that 1 sprite.
It's cool to see people weighing in on features and such.. I don't consider mirroring to be extravagant because I see it as a hardware thing. Like how the PPU handled it on the NES.. and that it's just changing the order and direction that it starts reading bytes. Rotation would be cool, though. But I can also see why zep wouldn't add it.
I'm pretty shocked that he added full keyboard support tbh. And even more shocked that noone seems to be taking advantage of it.
@enargy I did not know full keyboard support was added. That's actually really neat to know; I was considering adapting an old text adventure I made as a kid, but then realized that might be tricky. Perhaps it is possible now. Maybe he was torn between Pico-8 feeling mostly like an old console or mostly like an old 8 bit computer and is now erring on the side of old 8 bit computer; which would give you full keyboard support :) Makes sense since we already have a terminal.
gradualgames: I think the era that PICO-8 is going for did have keyboards, in addition to simple controllers. I mean, if they didn't have keyboards, you couldn't code the games to begin with, could you? :p
Keyboard support seems reasonable ... I mean, the Commodore 64 WAS essentially a keyboard with a graphics and sound chip attached.
[Please log in to post a comment]
