LÖVE

Kemair wrote: ↑Wed Jul 29, 2020 1:25 am 1a. Conceptually, what are the issues regarding screen size, resolution, and having my art assets work with all that?

Kemair wrote: ↑Wed Jul 29, 2020 1:25 am 1b. If the game works on my laptop, will the art scale on the phone?

Kemair wrote: ↑Wed Jul 29, 2020 1:25 am 1c. Should I be testing everything from the start in a certain resolution on my laptop to emulate the phone screen?

Kemair wrote: ↑Wed Jul 29, 2020 1:25 am 1d. Are you aware of any good resources regarding these types of topics?

Kemair wrote: ↑Wed Jul 29, 2020 1:25 am 2a. Is my code just going to work after I import it with the distribution tools?

Kemair wrote: ↑Wed Jul 29, 2020 1:25 am 2b. Are there certain features of love or Lua that I should avoid using because they aren't cross platform?

Kemair wrote: ↑Wed Jul 29, 2020 1:25 am 2c. Do phones work in some different way that I should structure how my code handles my game mechanics?

Kemair wrote: ↑Wed Jul 29, 2020 1:25 am 2d. Should I be skeptical of Lua's tables and getting creative with them?

myFunc{param1 = 3, param2 = 5}

local myTable = {} -- place this where it will be executed only once
...
-- every time you want to call, overwrite the current values:
myTable.param1 = 3
myTable.param2 = 5
myFunc(myTable)

local function newObj()
  local obj = {x = 0}
  function obj:incX()
     obj.x = obj.x + 1
  end
  return obj
end

local function obj_incX(self)
  self.x = self.x + 1
end

local function newObj()
  local obj = {x = 0, incX = obj_incX}
  return obj
end

Kemair wrote: ↑Wed Jul 29, 2020 1:25 am 2e. Is multi-threading at all a relevant consideration for a somewhat simple game?

Kemair wrote: ↑Wed Jul 29, 2020 1:25 am 3. Does running a (cloud) server change any considerations? Is this required to stop cheating from happening on a leaderboard system? Do I have to consider hackers altering in game values or does Android/iOS prevent this from happening? How are in-game real life money purchases handed normally? Any good resources on this as well is appreciated.

Kemair wrote: ↑Wed Jul 29, 2020 1:25 am 4. Is there any other category of a potential problem I'm not even aware of?

zorg wrote: ↑Wed Jul 29, 2020 12:57 pm Both ios and android platforms disable the JIT part of luaJIT, that löve uses; what this means for you is that you should/can not use some more advanced things, like the FFI library,

Kemair wrote: ↑Wed Jul 29, 2020 1:25 am My control scheme exclusively consists of pressing buttons on the game's UI, so I'm not too worried about getting the controls to work on the phones.

pgimeno wrote: ↑Wed Jul 29, 2020 11:43 am

Kemair wrote: ↑Wed Jul 29, 2020 1:25 am 2d. Should I be skeptical of Lua's tables and getting creative with them?

Lua has a problem. The garbage collector sucks. The more objects the GC needs to deal with, the slower it gets. For big projects, GC issues manifest themselves as lag spikes.

There are two ways to stress the GC: to have lots of active objects, and to generate lots of garbage. The first means that the fewer tables you use, the better. For example, in case of 2D maps, it's better to flatten your map to 1D, than having 1 table with NROWS sub-tables each with a row.

The second means that you should avoid creating temporary variables that need cleaning up. For example, avoid things like this:

Code: Select all

myFunc{param1 = 3, param2 = 5}

You could rewrite it like this:

Code: Select all

local myTable = {} -- place this where it will be executed only once
...
-- every time you want to call, overwrite the current values:
myTable.param1 = 3
myTable.param2 = 5
myFunc(myTable)

local myTable = {}

myTable.param1 = 3
myTable.param2 = 5
...

myTable = nil

pgimeno wrote: ↑Wed Jul 29, 2020 11:43 am Avoid creating functions on the fly; in most cases you don't need them to work as closures, or you can make non-closure versions. Keep them until they are really needed. For example, this is bad:

Code: Select all

local function newObj()
  local obj = {x = 0}
  function obj:incX()
     obj.x = obj.x + 1
  end
  return obj
end

Instead, create the function outside the other function, making use of the `self` parameter, and add a reference to it in the object:

Code: Select all

local function obj_incX(self)
  self.x = self.x + 1
end

local function newObj()
  local obj = {x = 0, incX = obj_incX}
  return obj
end

zorg wrote: ↑Wed Jul 29, 2020 12:57 pm I'll keep my opinions on monetized mobile software to myself, so i'll just add a few relevant things instead:

ivan wrote: ↑Fri Jul 31, 2020 6:29 am

Kemair wrote: ↑Wed Jul 29, 2020 1:25 am My control scheme exclusively consists of pressing buttons on the game's UI, so I'm not too worried about getting the controls to work on the phones.

Touchscreen input is probably the biggest difference between desktop and mobile gaming.
Your controls may work, but that's not enough the question should be "is the game fun to play on a tiny touchscreen".
That's why it's good to look into gestures and multitouch input.
As for dealing with hackers and cheating, I doubt that will be an issue unless your game is already very popular.

Kemair wrote: ↑Mon Aug 24, 2020 1:46 pm

pgimeno wrote: ↑Wed Jul 29, 2020 11:43 am The second means that you should avoid creating temporary variables that need cleaning up. For example, avoid things like this:

Code: Select all

myFunc{param1 = 3, param2 = 5}

You could rewrite it like this:

Code: Select all

local myTable = {} -- place this where it will be executed only once
...
-- every time you want to call, overwrite the current values:
myTable.param1 = 3
myTable.param2 = 5
myFunc(myTable)

I'm not sure I understand the difference here with the code. Are you saying I should minimize the amount of tables I use by writing over values in a single table instead of creating separate tables? What about nested tables in a single table, is this better?

Kemair wrote: ↑Mon Aug 24, 2020 1:46 pm Can I flag a table for deletion by the GC as such?:

Code: Select all

local myTable = {}

myTable.param1 = 3
myTable.param2 = 5
...

myTable = nil

Kemair wrote: ↑Mon Aug 24, 2020 1:46 pm I intuitively understand what passing 'self' to a function does. Can you explain what it does on the code and performance level? Is it just passing values by reference to the function so it can access the variables? Does this pass local variables as well?

local function newObj()
  local obj = {x = 0}
  function obj:incX()
     obj.x = obj.x + 1
  end
  return obj
end

local function newObj()
  local obj = {x = 0}
  obj.incX = function (self)
    obj.x = obj.x + 1
  end
  return obj
end

obj:incX()
obj.incX(obj)

local A = {a = 1}
local B = {b = 1}
local C = A

local function f1(param)
  param = B -- this does not change anything in the caller; a real pass-by-reference would
end

local function f2(param)
  param.a = 5 -- this alters the table passed to the function
end

print(A) -- prints some value X
print(B) -- prints some value Y
f1(A)
print(A) -- prints the value X, NOT the value Y
f2(A)
print(C.a) -- prints 5