LÖVE

Posted: **Tue Nov 07, 2017 3:42 pm**

Hi! First game here. New to Lua as well. I'm wondering how to organize all the game state. I'm not using an OOP library. By game state I mean everything about the game that has to be kept in memory, eg. entities.

Do you just have a table several level deep or am I completely off base here?

Code: Select all

state = {
  entities = {
    player,
    monster,
    npc_a,
    ...
  },
  world = {
    in_interior = false,
    map = overworld,
    ...
  },
  stats = {
    playtime = 127,
    achievements = {
      ...
    }
  }
}

I feel that just using tables in tables in tables for everything might get a bit messy, so I made a small struct-like thing that I can use like this:

Code: Select all

define_type("complex", {
  x = "number",
  y = "number"
})

-- works
local c = new_t("complex")
c.x = 10
print(c.x)

-- does not work
c.x = "a"  -- type error: type complex's x field is number but got string!
c.y = 10  -- type error: type complex doesn't have a z field!
print(c.y) -- type error: type complex doesn't have a z field!

Does this make sense? Would the same problem be solved by using an OOP library? How is this data usually kept in memory by love games? Is there any open source example game I can take a look at?

Let me know if it's not clear what I'm asking.

Posted: **Tue Nov 07, 2017 6:40 pm**

Everything in lua is either a table or a data variable (bool, string, number, function, userdata... that's already all of them)
OOP / Class libraries just wrap tables nicely and provide some utils.

But yes. Ultimately. You will have lots of tables within tables.
It usually makes sense to store things in list like structures.
Aka have a "character" list. Where all characters are stored. So you can easily loop over all of them and render them, update them or do whatever.
Structure is an important aspect of development and how you decide to structure your game will have a huge influence over your development.

Don't be shy to use libraries here. Unless you want to learn how to create those yourself. Just use them!
There's a decent variety.

For OOP my favorite is middleclass. Not the fastest but has a pretty nice API and the right amount of information I'd wanna get out of classes.

For ECS, I can advertise my HooECS. Which enforces a structure but takes care of almost all "Where should data be stored", "what list should I iterate over" and things like that.

Good luck!

Posted: **Tue Nov 07, 2017 8:00 pm**

I was wondering about dependency between entity updates and how to solve them. If I have a single player.update and sentry.update, maybe the player hides before the sentry can see them or maybe the sentry sees them before they can hide. Depending on whether the player or the turret is updated first, the player can die or not die.

Do components in ECS systems solve this (in general) by separating the move and shoot part of the update (in my particular example)?

Posted: **Wed Nov 08, 2017 6:05 pm**

ECS solves this by not having code in the entity nor in the component (not much anyway. They are mostly containers. Entities are containers for components and components containers for data, like images, position, etc).

Systems do all the work. Systems operate on all entities with a (in the system) defined set of components (or just a single one... or just operate on all entities).

A system takes care of a specific task. EG. Movement, line of sight detection, drawing the world, drawing characters, movement input (or input generally if you don't want or need to split it up), etc.

You define the order they are called in. First all update systems are processed. Then all draw systems.

So at least the order is tightly controlled. What actions happen after one another. Even though the order in which entities are processed might not be reliable or controllable.

Posted: **Wed Nov 08, 2017 6:12 pm**

Nice, I think I already have a very lightweight version of that. I'll study your library (and maybe switch to it) to learn more.

Thanks for the help.

Posted: **Wed Nov 08, 2017 7:02 pm**

There's also tinyecs and lovetoys (the framework my library is based on. Less features, slightly better performance).

Variety is awesome. Look around and pick the one you like best. That's why there's more than one!

Posted: **Fri Nov 10, 2017 7:35 pm**

I have posted a scenemanager example in github recently. https://github.com/RednibCoding/Love2D_Scenemanagement

Hope this helps

LÖVE

Game state in lua (or in general)

Game state in lua (or in general)

Re: Game state in lua (or in general)

Re: Game state in lua (or in general)

Re: Game state in lua (or in general)

Re: Game state in lua (or in general)

Re: Game state in lua (or in general)

Re: Game state in lua (or in general)