LÖVE

Posted: **Sat Jun 09, 2018 9:44 pm**

Hello, I've recently downloaded love2d so I can start delving into game development. I started programming in Java, and I'm wondering whether that's restricting me. My "Player" table looks like the following:

Code: Select all

local Player = {}

function Player.new(x, y)
	player = {}
	player.x = x
	player.y = y
	player.speed = 150

	function player:draw()
		love.graphics.rectangle("fill", self.x, self.y, 50, 50)
	end

	function player:update(dt)
		if love.keyboard.isDown('w') then self.y = self.y - self.speed*dt end
		if love.keyboard.isDown('a') then self.x = self.x - self.speed*dt end
		if love.keyboard.isDown('s') then self.y = self.y + self.speed*dt end
		if love.keyboard.isDown('d') then self.x = self.x + self.speed*dt end
	end

	return player
end

return Player

You can see that all of the player functions are within an object that is returned upon calling the Player.new() function. In looking at other peoples' code I've noticed that their layouts are quite different, involving the use of functions outside of objects to be created. Some concerns I have include the fact that there will only be one "player" in the game, and thus some of this code is redundant. Is this style of writing restrictive, and what do you think would be a better option? Thanks.

Posted: **Sun Jun 10, 2018 1:08 am**

I don't give style advice, as that's somewhat personal. I can tell that defining the methods within the constructor, means new functions are allocated on every invocation, and need to be garbage-collected when freed. That's of course not a problem for an object that will be created just once, but it's a reason why to have the functions out of the constructor.

On an unrelated note, if you want French players to be able to play your game without getting frustrated, use isScancodeDown instead of isDown, because in a French keyboard the keys in these positions are ZQSD, not WASD.

Posted: **Sun Jun 10, 2018 4:27 am**

You can see that all of the player functions are within an object that is returned upon calling the Player.new() function. In looking at other peoples' code I've noticed that their layouts are quite different, involving the use of functions outside of objects to be created. Some concerns I have include the fact that there will only be one "player" in the game, and thus some of this code is redundant.

Lua doesn't have "objects" per se.
With the closures technique (where you copy the "methods" into each object),
it's more common to return a function that creates a new object.
That avoids the "Player" global and means better encapsulation.
Like pgimeno said, the closures will be GCed so this is good for long-lived objects,
and access should be faster since there are no metatables and passing around of "self" references.

Code: Select all

return function(x, y)
  local player = {}
  -- init code goes here
  player.x = x
  player.y = y
  function player.destroy()
    ...
  end
  function player.draw()
    ...
  end
  return player
end

If you are absolutely sure that there can only be one "Player" object then I suggest removing/renaming the "new" function.
And you don't need to copy over the rest of the functions:

Code: Select all

player = {}
function player.init(x, y)
  player.x = x
  player.y = y
end
function player.draw()
    ...
end

Note that in both cases you don't need to use "self" and colon ":".

pgimeno wrote: ↑Sun Jun 10, 2018 1:08 am On an unrelated note, if you want French players to be able to play your game without getting frustrated, use isScancodeDown instead of isDown, because in a French keyboard the keys in these positions are ZQSD, not WASD.

That's good to know, I didn't know that either.

Posted: **Tue Jun 12, 2018 12:04 pm**

programming style is a set of rules set. computer program fir a code source.it is often calmed.

LÖVE

Styles of writing game code

Styles of writing game code

Re: Styles of writing game code

Re: Styles of writing game code

Re: Styles of writing game code