Log In  

I see these things in almost every singe program, but i don't know how to use them

snippet from the collisions demo

function make_actor(x, y)
 a={}
 a.x = x
 a.y = y
 a.dx = 0
 a.dy = 0
 a.spr = 16
 a.frame = 0
 a.t = 0
 a.inertia = 0.6
 a.bounce  = 1
 a.frames=2

 -- half-width and half-height
 -- slightly less than 0.5 so
 -- that will fit through 1-wide
 -- holes.
 a.w = 0.4
 a.h = 0.4

 add(actor,a)

 return a
end

also, what does the "return" do?

Sorry for asking such an obvious question

P#44283 2017-09-17 16:49 ( Edited 2017-09-24 23:37)

1

I literally just finished writing the section of my upcoming zine that covers these two topics. I haven't finished the proofreading and editing, but I hope these explanations help. (I'm interested in any feedback on whether these are helpful explanations too!) :)

You can skip the first page on the left (page 16).

The only thing the above pages don't cover that's relevant here is the part where it has add(actor,a). That's just a function that adds a value to another table. In this case, it's adding the newly-created "a" table as a value to the "actors" table. (Tables can store other tables as values.)

So basically what's happening in that function is that the make_actor() function is creating a table and calling it "a", and then adding a bunch of values to that table with specific keys like "x" and "y" and "frame". Then after adding the newly-created "a" table to the "actors" table, it returns "a" as the result of the function and can be used wherever the function make_actor() was run.

I hope that helps some!

EDIT: I should note that the first page (page 16) of what I posted isn't relevant to your question. It seemed like you knew what a function was, but just not what return meant. It's just that the first page was part of the same double page spread.

P#44288 2017-09-17 18:27 ( Edited 2017-09-17 22:39)

@MBoffin

So its a way to organize values?

P#44290 2017-09-17 19:33 ( Edited 2017-09-17 23:33)

Yup. It allows you to keep a ton of values contained in one variable name.

A lot of game developers refer to the "alive" characters in their game as "actors", hence the name you see used. It's easy to group them together like that because they share a lot of similar characteristics. For example, all actors in a game might have in common the fact that they have an x and y coordinate, a sprite, a direction they're moving, a width and height, etc. Each of those might be different from actor to actor, but they all have them. Tables are a great way to store these kinds of collections of values.

This means you can have a generic function where you just give the function an actor, any actor, and it will be able to do its work without worrying about whether or not that actor has those values attached. For example, maybe you could have a function like this:

function move_actor(a)
 a.x+=a.dx
 a.y+=a.dy
end

That function doesn't care which actor you give it, but it can safely assume that the actor ("a") has an x and y coordinate and dx and dy values, because all actors in the game have those.

So the make_actor() function you were looking at up top was just a way to create a generic actor table for the game and give that actor all the normal values an actor should have in the game.

P#44291 2017-09-17 19:45 ( Edited 2017-09-17 23:49)

Other languages and scripts I've used in the past did tables differently or not at all, So it took some getting used to but it's the most handy data structure for game programming ever! Position, Lives, Speed, Sprites.. All can be stored within a table!

And unless I'm mistaken, Collections of tables can be stored inside OTHER tables! (At least a friend trying to explain full LUA mentioned something like that.. I might've gotten her wrong tho.)

P#44292 2017-09-17 19:54 ( Edited 2017-09-17 23:54)

Lua data is tables, all the way down. Tables hold values, and one of the value types is "table". Global scope is just a hidden table.

Structures and classes are just syntactic sugar on tables, e.g. object.member is syntactic sugar for object["member"], while object:method(...) is syntactic sugar for object["method"](object,...).

It's a cool language. It's not efficient at all, with everything being based on table lookups, but it's incredibly flexible for things that don't need a ton of performance. I've really grown to love it for scripting.

P#44324 2017-09-18 13:34 ( Edited 2017-09-18 17:36)

This is way more useful than I thought

thanks to all of the people who answered

P#44383 2017-09-20 05:05 ( Edited 2017-09-20 09:05)

Hey, guys, I'm having an issue changing the values.
I keep getting

runtime error
<eof>
line 10: attempt to preform arithmetic on glodal 'x' (a nil file)

P#44426 2017-09-21 19:39 ( Edited 2017-09-21 23:39)

Hi PixelBytes! It's tough to tell without seeing your code, but it looks like your code is running some math on a value that you haven't yet defined (hence the computer being unable to complete the equation). Can you upload your current code, so we can see where your issue is?

P#44427 2017-09-21 22:44 ( Edited 2017-09-22 02:44)

Eggnog

function player()
 p.x=63
 p.y=63
end

function _update()
 if btn(0) then p.x-=1 end
end

function _draw()
 cls()
 print(".",p.x,p.y,7)
end
P#44477 2017-09-23 09:24 ( Edited 2017-09-23 13:24)

The problem you're running into is that you are defining p.x and p.y, but you haven't defined what p is yet. Add p={} before you set p.x and p.y in the player() function. That will create an empty table called p, which will then allows you to set the x and y keys of that table.

And just as an aside, if you just want to draw a single dot for the player, you could use pset(p.x,p.y,7) instead of print().

P#44497 2017-09-23 15:14 ( Edited 2017-09-23 19:15)

MBoffin

It worked, but I had to get rid of function "Player()" and have the variables out in the open in order to work, but why is that?

P#44500 2017-09-23 16:49 ( Edited 2017-09-23 20:49)

@M~Boffin when do you think the zine will be out? And where will it be available? Thanks!

P#44502 2017-09-23 16:54 ( Edited 2017-09-23 20:54)

@PixelBytes

You didn't happen to write the suggested "p={}" as "local p={}", did you? That would explain it not working when the code is inside a function, since local variables only exist while the function is running.

P#44519 2017-09-23 21:30 ( Edited 2017-09-24 01:31)

@Felice

No, i didn't use "local p={}"

P#44538 2017-09-24 11:43 ( Edited 2017-09-24 15:43)

actually you only defined player() but didn't call it at all. either call it "in the open" or in _init()

function _init()
player()
end

pico-8 first executes the code "in the open" till the end of the file (that's when functions are defined, but not called), then it calls _init(), then it loops with _update() and _draw().

P#44541 2017-09-24 12:05 ( Edited 2017-09-24 16:08)

Ultrabrite

Thanks, works now ^-^

I never found a use for "_init()" for my code before, so I never think about it.

P#44551 2017-09-24 13:40 ( Edited 2017-09-24 17:41)

@penthouse_guy I'm giving away printed versions for a workshop I'm giving soon. Once that happens, I'll have it on itch.io for download and I'll likely do a Kickstarter or something to cover costs for those who can't attend the workshop, but would still like a printed version.

P#44575 2017-09-24 19:37 ( Edited 2017-09-24 23:37)

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2024-03-28 17:03:36 | 0.031s | Q:36