Dagg Nabbit

hard enough to get Lua shit reviewed, better to leave the simple stuff alone

second one adds a bunch of stuff that's harder to understand

the first one will be easier to digest/review

@SimonAndréForsberg because it's a big change

the ECS can hold its own but still having a hard time visualizing how it will be used with a TCG exactly. Feel free to use it though.

with the Lua ECS thing

i made pong

The SVG files themselves would be part of the mod, sent to the client at the beginning of the game (there would probably only be one or two "templates" for an entire game), so there is no problem with the results of getDisplayProperties (or whatever) matching the placeholder values in the SVG

Each card would have a function named something like getDisplayProperties, and this would return a table with just the stuff the UI needs to display the card. This table gets sent over the wire, and the UI drops the properties of the table into an SVG template... for example if the tables have "name," "description," "health," and "defense" properties, the SVG files would have matching tokens like {name} and {health}, and the data would be inserted with simple replacement

@SimonAndréForsberg I think this might be more a matter of which properties should be sent to the client. The only thing the client needs to work with the card is an ID, and then it needs some properties to display. I was imagining this working like this...

i think this is the equivalent of what i tried to write above in Java (and probably failed miserably)

function each(javacrap)
  local iterator = javacrap:iterator()
  return function()
    if iterator:hasNext() then
      return iterator:next()
    else
      return nil
    end
  end
end

like

could we cheat and just dump a Lua function in a string on the Java side

wouldn't bet on it, but no clue really

or if we need zone.getCards on the Java end, make another function named something like that to do this

so that in lua we can do: for card in zone:getCards() do

i want to turn zone.getCards into a function that returns a Lua iterator function

how would this look if it did not look horrible?

but... umm... yeah

lol, it looks horrible to me

abstract class LuaCardIterator extends ZeroArgFunction {
    public LuaValue call();
}

public class LuaCardIteratorFactory extends ZeroArgFunction {

    private ListIterator<Card> iterator = field.getCards().iterator();

    public void call() {
        return new LuaCardIterator() {
            public void call() {
                if (iterator.hasNext()) {
                    return iterator.next()
                } else {
                    return LuaNil
                }
            }
        };

would it look anything like this:

@SimonAndréForsberg how do you define a Lua function that returns another Lua function in Java?

field:eachCard() would return a function that returns each card in succession

wouldn't even need to make a table, just have a special iterator that returns one card after another until none are left

what about something like that

for card in field:eachCard() do
    if card.data.sickness > 0 then
        card.data.sickness = card.data.sickness - 1
        print("Card on field now has sickness" .. card.data.sickness)
    end
    card.data.attacksAvailable = 1
end

inserting is no problem, shuffling can be a simple fisher-yates which is like 4 LOC

just something to get rid of the weird linked list iterators

really the current system would be fine with me if there were a public zone.cards or something that ipairs could operate on

zone = setmetatable({}, { __newindex = function() ... end })

have a metamethod on your "zone" tables that does all that when you insert new stuff

with metamethods

i think it could though

true, true

table.insert(x, card) is well documented and many people are already familiar with it

card:moveToBottomOf(x) is something that nobody already knows

and will a Lua IDE really find this stuff that was defined in Java?

maybe this is a cultural thing then... i rarely use an IDE, i use text editors for light stuff and vim for heavy stuff

either that or something like card.zone = owner.data.battlefield

i should be able to do this: table.insert(owner.data.battlefield, card)

i should not have to remember that here's a function named card:moveToBottomOf

just like if we do ECS on the script side. It's not something proscribed, it's more like an example that people can follow, or not

if it were all on the script side, it would be more like "this is how we do zones in this game, you can use this, or do something similar, or just do whatever"

and i don't just mean game:addZone and card:getZone, i mean the whole iterator API that comes with it... all that adds complexity, more specific stuff to know

and not just deal with them however they want

if you are having the script deal with zones anyway, then you are adding complexity by having the script also have to deal with them through a special API

here's how i look at it... you put stuff in the core that it needs to handle, like communicating with the client, and stuff that you don't want the script to have to deal with, because it's too low level