Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Grid – A Lua Game Engine

planimeter.org

Post reply on HN
Print view View original

71–79 of 79 posts

Re: Grid – A Lua Game Engine

#71

Post by andrewmcwatters »

voppe wrote: post #66
andrewmcwatters wrote: post #20

Thank you for posting this, Bambo! I was curious why we were seeing 10s of new stars all of a sudden and trying to figure out where the GitHubbers were coming from. Grid Engine 9 is now the largest pure-Lua game engine on GitHub. As s_y_n_t_a_x has mentioned in this thread, I built the Grid Engine on top of LÖVE. I came from the hlcoders world, having used the Source Engine for several years, and was upset the 2D wor…

Of course it is you! Astounding work as always. Thanks!

Thank you for the kind words, voppe. :)

Re: Grid – A Lua Game Engine

#72

Post by andrewmcwatters »

mmlkrx wrote: post #62
andrewmcwatters wrote: post #55

Earlier quoted context omitted.

I will prioritize this immediately. I believe one should be able to understand all of the concepts the engine offers within short order, and clearly I need documentation to back that belief. Everything is there to get started in just minutes, reducing any installation friction typically found with larger game engines, but I agree that documentation should be able to reduce the cognitive friction such that one can get…

If you're looking for inspiration on how to organize your docs, I found this resource really valuable: https://documentation.divio.com You can see the documentation system in action in this project: https://www.brachiograph.art Regarding Grid, personally I always like to look at example applications built with framework/library/engine so seeing a list of projects that utilize Grid would be nice.

Thank you, mmlkrx. I'm focusing on this today and I appreciate your help! I will keep this feedback in mind and emphasize the points you have made.

Re: Grid – A Lua Game Engine

#73

Post by kroltan »

kroltan wrote: post #49
CreepGin wrote: post #32

Earlier quoted context omitted.

Hehe, hence the word "embeddability" instead of "embeddable".

Oh yes. I used that word very precisely :D

I was half asleep when typing that comment, sorry. Too late do edit now. I meant to write:

"I believe that word was used very precisely"

Re: Grid – A Lua Game Engine

#74

Post by spc476 »

tpxl wrote: post #63
spc476 wrote: post #41

Earlier quoted context omitted.

Integer support was added in Lua 5.3 (released in January 2015). It also added binary operators, rendering the bitop module obsolete. One thing I never understood is the mania for OO programming---I regularly see people announce Yet Another OO Module for Lua on the mailing list, and I have to ask myself, "Why?" Is OO the only thing taught these days in school? There are other ways of organizing code than OO.

Serious question: How do you organize your data in a semantically meaningful way without something like an object/struct (in a strong type system preferably). I get functional programming and all, but structs just seem like a natural way to organize data.

Structs are a natural way to organize data, but that doesn't necessarily make it "OO". In Lua, a module is typically a table (associative array really) of functions. All of the standard modules that come with Lua are just collections of functions that don't have a concept of "this" (like math or os).

Now, an object in Lua can have functions that assume a "this" parameter (Lua calls it "self") and thus, it can be viewed as an object qua OO, for example, an open file:

    file = io.open("foo.txt","r")
    file:setvbuf('no') -- no buffering
    file:seek('set',10) -- seek to byte 10 in file
    data = file:read(8) -- read 8 bytes
    file:close()        -- close file
but Lua lacks typical OO features like inheritance, a "class" function or method, which are what the OO modules in Lua always add. It's this mentality, that OO is missing if you don't have inheritance.

Re: Grid – A Lua Game Engine

#75

Post by ebg13 »

spc476 wrote: post #74
tpxl wrote: post #63

Earlier quoted context omitted.

Serious question: How do you organize your data in a semantically meaningful way without something like an object/struct (in a strong type system preferably). I get functional programming and all, but structs just seem like a natural way to organize data.

Structs are a natural way to organize data, but that doesn't necessarily make it "OO". In Lua, a module is typically a table (associative array really) of functions. All of the standard modules that come with Lua are just collections of functions that don't have a concept of "this" (like math or os). Now, an object in Lua can have functions that assume a "this" parameter (Lua calls it "self") and thus, it can be view…

> Lua can have functions that assume a "this" parameter (Lua calls it "self")

Even Lua's assumed "self" via the thing:funcname(...) call is just a charade and is secretly just thing.funcname(thing, ...). The split between . and : calling, IME as an informal Lua teacher, is confusing to programming newbies when they first encounter it and I kinda wish the language hadn't chosen _that_ as the thing to spend time implementing.

Re: Grid – A Lua Game Engine

#76

Post by shezi »

symmitchry wrote: post #3
Kataphract wrote: post #2

Why do people use Lua in a world where we have Python?

Does Python have any good game engines? PyGame project is a nightmare. Lua's https://love2d.org/ is amazing.

Arcade is pretty nice. It's what pygame should be, at least in terms of installability.

https://arcade.academy/

Re: Grid – A Lua Game Engine

#77

Post by spc476 »

ebg13 wrote: post #75
spc476 wrote: post #74

Earlier quoted context omitted.

Structs are a natural way to organize data, but that doesn't necessarily make it "OO". In Lua, a module is typically a table (associative array really) of functions. All of the standard modules that come with Lua are just collections of functions that don't have a concept of "this" (like math or os). Now, an object in Lua can have functions that assume a "this" parameter (Lua calls it "self") and thus, it can be view…

> Lua can have functions that assume a "this" parameter (Lua calls it "self") Even Lua's assumed "self" via the thing:funcname(...) call is just a charade and is secretly just thing.funcname(thing, ...). The split between . and : calling, IME as an informal Lua teacher, is confusing to programming newbies when they first encounter it and I kinda wish the language hadn't chosen _that_ as the thing to spend time implem…

The same is true in C++ and Java, only the "self" argument is completely hidden in that case.

Re: Grid – A Lua Game Engine

#78

Post by anonymoushn »

Stevvo wrote: post #61
rishav_sharan wrote: post #9

Earlier quoted context omitted.

IMO, these are the main reasons; 1. Embeddability. You can create a game engine in a performant systems language like c++ and embed lua in it for the scripting. 2. Speed. The lua interpreter is much faster than python in general. When you throw luajit into the fix, they are not really comparable at all. 3. simplicity: lua is tiny. and one of the easier languages for non coders (game designers, artists) to get started…

You could make the same 4 points about Pawn, I don't know why nobody uses it. Pawn has all of lua's strengths without any of its quirks and weaknesses.

Some reasons I might not use Pawn:

The only benchmarks I could find claims that it is significantly slower than Luajit. The official docs claim that the fastest implementation is available on fewer platforms than Luajit.

Regarding the lack of structs, the official docs say "pawn has no "struct"s, but it extends arrays so that it can mimic light-weight structures with arrays; as an example of those extensions, pawn supports array assignment and array indices can be assigned an individual "identify" (or "purpose") and even form a sub-array." but the manual's mentions of array assignment make it seem like that's just memcpy. One could imagine having bullet objects and declaring BULLET_X=0, BULLET_Y=1, BULLET_SPRITE_IDX=2, and so on, just so that when one has a bullet object and they would like to draw it at the right location they could avoid writing draw(b[2], b[0], b[1]). Having an array of untyped cells and memcpy isn't really the same as having a struct with named members. Please correct me if I'm wrong.

A lot of useful patterns become less possible when one does not have a map or set type and when one does not have coroutines. It seems like instead of coroutines Pawn includes a syntactic sugar for a switch statement that depends on a single global state variable, in which the cases can be declared like functions. This is interesting but not particularly helpful. Why can one not have multiple different state machines, multiple instances of a state machine, and so on?

Re: Grid – A Lua Game Engine

#79

Post by EamonnMR »

symmitchry wrote: post #35
EamonnMR wrote: post #28

Earlier quoted context omitted.

I'm curious as to what you found nightmareish about Pygame... It's SDL.

Years of being extremely difficult to run on a Mac (no pip install), horrible website update (the old one was bad, but at least it was cool & functional), and on-going issues like this: https://github.com/pygame/pygame/issues/555 There's not even a note on the website that it's entirely broken in Mojave. It's just _always_ something. Compared to LOVE and numerous other projects which just worked right out of the box.…

Fair enough. Though I have similar complaints about other packages on mac (Python and Ruby MySQL packages being good examples.)
Post reply on HN