LÖVE

Posted: **Sat Feb 15, 2014 10:03 am**

First of all, notice that this won't work:

 tile = {__index = tile}

tile.__index will receive 'nil', just because of one simple reason. The table with the field __index is created first. At that time, tile doesn't exist, so the field __index receives nil. Then the table is assigned to the variable "tile".

The right way to do it would be:

Code: Select all

tile = {}
tile.__index = tile

Second, about classes, keep in mind one thing. What you are calling a class should be like a "pattern". All instances from a class are supposed to know/use each and every single method defined in the class itself. For that matter, you do not need to define a draw method when you create an instance. Rather, move that draw instance in the class definition itself.
Also, it was not needed to have tile.create separated from tile.new, because they are supposed to do the same.

Updated code:

Code: Select all

-- The class itself
tile = {}
tile.__index = tile

-- Updates a tile
function tile:update(dt) end

-- Creates a new tile.
function tile.new(x,y,w,h)
  local instance = {}
  instance.x, instance.y = x, y
  instance.w, instance.h = w or 32, h or 32
  return setmetatable(instance, tile)
end

-- Draws a tile.
function tile:draw()
  love.graphics.setColor(255,0,0,255)
  love.graphics.rectangle("fill", self.x, self.y, self.w, self.h)
end

Hope this helps.

Posted: **Sat Feb 15, 2014 6:56 pm**

Oh! sorry I guess no one made that clear. I thought I could shorten it down with

Code: Select all

tile = {
     __index = tile
}

obviously I was wrong.

And I did have the draw function seperate at first, I guess I was overthinking the process or was misled when reading goature's entity library thing

Code: Select all

instance.x, instance.y = x, y
instance.w, instance.h = w or 32, h or 32

Didn't know you could do that, I did try

Code: Select all

local recW, recH = 10

But it didn't work so I thought it wouldn't work in any case.

Roland_Yonaba wrote:Hope this helps.

Of course it does! Otherwise I wouldn't come back here >.> Thank you! Whatever happened to the karma system by the way?

edit: forgot to mention, that one of the tile:create function was suppost to create a new type of tile, should I just create a method "type" in the class? or just create a different class?

edit: Yup, now getting an error. Says that the second argument... or self.x (probably self.y too) is nil. I tried this...

Code: Select all

function tile:draw()
	if instance then
		love.graphics.setColor(255,0,0,255)
		love.graphics.rectangle("fill", self.x, self.y, self.w, self.h)
	end
end

but the if instance didn't work. i'll upload the .love.

Posted: **Sat Feb 15, 2014 11:09 pm**

Zilarrezko wrote:
Code: Select all
instance.x, instance.y = x, y
instance.w, instance.h = w or 32, h or 32
Didn't know you could do that

Well, this is a handy way to create new objects with default values.

Zilarrezko wrote: I did try
Code: Select all
local recW, recH = 10
But it didn't work so I thought it wouldn't work in any case.

There is definitely a problem with this. You have to know how Lua deals with multiple assignments.
In this case, you have two variables on the left side of the assignment operator ("="), and only a single value on the right side.
Lua will assign this value to the first variable, and will assign nil to all the variables remaining. So recW will be 10, while recH will be nil.

Zilarrezko wrote:Whatever happened to the karma system by the way?

Broke. As far as I know.

Zilarrezko wrote: edit: forgot to mention, that one of the tile:create function was suppost to create a new type of tile, should I just create a method "type" in the class? or just create a different class?

It depends. What do you mean by " a different type of tile" ? In what way is this supposed to be different ?
You can have it as an optional paramater, and let your methods handle it differently... But if the "new tile" behaves like the others, but implements new methods, maybe inheritance is what you are looking for.

Zilarrezko wrote: edit: Yup, now getting an error. Says that the second argument... or self.x (probably self.y too) is nil. I tried this...
Code: Select all
function tile:draw()
	if instance then
		love.graphics.setColor(255,0,0,255)
		love.graphics.rectangle("fill", self.x, self.y, self.w, self.h)
	end
end

The "if-clause" is wrong. instance is nil, here. Remember that, when calling a method with a colon, Lua spawns a value as a first argument to the method itself. That value can be caught with "self", not anything else.
Example:

Code: Select all

local t = {}
t.func = function(...)  print('arguments', ...) end
t.func(1) -- will print 1
t:func(1) -- will print a table, then 1. The keyword "self" will reference this table within the function body. And this table is actually "t" itself.

Replace instance with self, it should work fine.
But IMHO, it won't make any sense, because since you are calling the method with a colon, you will always have a self argument.

Posted: **Sun Feb 16, 2014 8:37 pm**

Roland_Yonaba wrote:It depends. What do you mean by " a different type of tile" ? In what way is this supposed to be different ?
You can have it as an optional paramater, and let your methods handle it differently... But if the "new tile" behaves like the others, but implements new methods, maybe inheritance is what you are looking for.

Ah so I could have a parameter called "type" and say, if type == "this" then instance.destructable = true end. I understand.

Roland_Yonaba wrote:The "if-clause" is wrong. instance is nil, here. Remember that, when calling a method with a colon, Lua spawns a value as a first argument to the method itself. That value can be caught with "self", not anything else.
Example:
Code: Select all
local t = {}
t.func = function(...)  print('arguments', ...) end
t.func(1) -- will print 1
t:func(1) -- will print a table, then 1. The keyword "self" will reference this table within the function body. And this table is actually "t" itself.
Replace instance with self, it should work fine.
But IMHO, it won't make any sense, because since you are calling the method with a colon, you will always have a self argument.

I tried it, same problem happens. So I must not understand what you mean by replacing instance with self.

Code: Select all

--Start with a table crap
tile = {
}
tile.__index = tile

--Create a tile crap
function tile.new(x, y, w, h)
	local self = {}
	self.x, self.y = x, y
	self.w, self.h = w or 32, h or 32
	return setmetatable(self, tile)
end

--Draw the tile crap
function tile:draw()
	if self then
		love.graphics.setColor(255,0,0,255)
		love.graphics.rectangle("fill", self.x, self.y, self.w, self.h)
	end
end

Sorry to make this difficult, but I don't seem to be learning from reading a static manual. A dynamic manual like someone answering questions seems to have gotten me more push than reading and watching only. If the karma system would be working right now I'd be rapid firing 7404 clicks per minute at dat good karma button (thank you cooler master inferno).

Posted: **Sun Feb 16, 2014 10:26 pm**

Here's the problem, in main.lua:

Code: Select all

tile:draw()

Thing is, you don't really have a map yet.

You made one tile:

Code: Select all

tile.new(0,0)

... but you throw that tile away. Here's a simple solution:

Code: Select all

tileList = {tile.new(0, 0)}

Code: Select all

for i, t in ipairs(tileList) do
    t:draw()
end

Posted: **Mon Feb 17, 2014 12:45 am**

Apperently not, same thing is happening. Problem with dat argument still.

Posted: **Mon Feb 17, 2014 1:52 am**

You call "tile:draw", but tile is undefined. Do

Code: Select all

map[1]:draw()

instead.

Posted: **Mon Feb 17, 2014 3:51 am**

I saw it haha, coming back to say how stupid I was because I left tile:draw out of that for loop for some reason.

Posted: **Tue Feb 18, 2014 5:51 am**

Everyone's suggesting you to do OOP in Lua all from scratch, which is not a very easy way to learn it. I really suggest you use some third party library like middleclass.

Every person that I show Lua to, I always point to middleclass, and in just about 3 hours they get their first game up and running in LÖVE.

Metatables aren't something you should really dabble with unless you're extremely good at Lua. I didn't need metatables when I first started out in Lua, but I eventually got to learning it when I needed more advanced structures.

Posted: **Tue Feb 18, 2014 6:14 am**

Indeed, it's not an easy concept to learn, and it's like walking through a corridor since learning Lua, the table concepts were like a room where it took me time to examen the floors, decorations and surroundings. Now OOP and it's relatives are like the open world, I can't seem to grasp it when I read about it, watch it, hear it, given it, or even experience it; it's severely frustrating. I feel a personal taboo when contemplating the use of other's libraries.

qwook wrote:and in just about 3 hours they get their first game up and running in LÖVE.

I'm trying to do something much bigger, it'll take me years til version 1.0. I'm not trying to build a game I want as fast as possible. But rather learn Lua so I don't have to ask questions, and learn programming in general so when I get into college next year and take computer science I'll have an advantage in most concepts (take stress now and not later right?).

I've looked at several tutorials on OOP and look at about 3 libraries and followed along on a couple and I still don't feel I've even scraped it enough to use it, just a couple posts ago I couldn't write a map class worth crap. Still can't either...

qwook wrote:Metatables aren't something you should really dabble with unless you're extremely good at Lua. I didn't need metatables when I first started out in Lua, but I eventually got to learning it when I needed more advanced structures.

I guess I'm not that good at Lua, probably because all the tutorials I look at don't even have all the information or their explanations are sub par to crap. No tutorial I saw had the second argument for table.insert. Even the love wiki doesn't list out the set type of arguments for a good portion of their functions.

LÖVE

OOP help

Re: OOP help

Re: OOP help

Re: OOP help

Re: OOP help

Re: OOP help

Re: OOP help

Re: OOP help

Re: OOP help

Re: OOP help

Re: OOP help