
Grid – A Lua Game Engine - Bambo
https://www.planimeter.org/grid-sdk/
======
andrewmcwatters
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 world didn't have sophisticated game engine
technology like the 3D solutions in the field.

There's tons of great game software out there! But to me, a game engine isn't
just a load, update, draw framework. There's a lot of hard work involved past
binding libraries together.

A game engine needs an architecture, it needs to do multiplayer serialization
for you, and give you a meaningful way to load maps out-of-the-box, and so
much more.

Too many hobbyists are rolling this themselves, and I hope to continue to
bring rich game development features OOTB to other hobbyists like myself.

If you're interested in Grid, but don't find something quite right with it,
could you tell me? I've worked on this project for at least the past 6 years
from what my logs tell me, but it only continues to get better thanks to
people like you all reading posts like this and giving me feedback over the
years.

Thanks again, Andrew

~~~
emmanueloga_
I also saw this on your repo [1], I was wondering if you are planning to move
from Love to it, or what is it about? (just curious :-)

1: [https://github.com/Planimeter/lgf](https://github.com/Planimeter/lgf)

~~~
andrewmcwatters
A few casual notes, though I could continue to expand on this:

lgameframework is a project I took on some time ago to provide a LuaJIT FFI
alternative to LÖVE. It helped educate me on what was necessary to interact
directly with the OpenGL layer, and understand what challenges the LÖVE
developers will have in the distant future with OpenGL being deprecated on
macOS. (Will they move to bgfx? Or Vulkan/MoltenVK? Who knows. Ask Alex, I
suppose.)

As an interesting side note, it does things LÖVE doesn't, which may or may not
be interesting depending on whether or not you think first-party 3D features,
PBR, VR (See also LÖVR) are desirable in a pure Lua project.

It also serves as a hatch door project I hope I never have to use. Valve broke
Source for modders somewhere between the 2007 and 2013 engine branches with
SteamPipe, and the idea that you could spend literal years on a project and
have some developer break your work in Bellevue was scary to me. They don't
have the same respect for the modding community today that they did maybe 15
or so years back. I don't think that's going to change, unfortunately, but I'm
digressing.

I trust the LÖVE team, and appreciate that it's FOSS software, but I need full
control over the stack I present to developers using the Grid Engine, and I
need to respect users by not breaking things.

In the event LÖVE breaks things, the Grid Engine needs to be patched to
account for those changes, and Grid has been around long enough to see this
happen a small number of times. I think the changes have been reasonable so
far, but mature projects will inevitably end up with deprecation notices and
backwards compat patches, and that's where we are now.

lgameframework is defensive software, but I'd rather continue to promote LÖVE.
The only issue I see with this, and cannot condone however, are the libraries
that have come out of the community with inappropriate names.

Edit: I apologize that all of this sounds a bit dark, that's not my intention,
but a lot of people's hard work can be at stake. Implementors of such software
need to defend their users. The LÖVE developers have created something
wonderful, and I must reiterate this.

I plan on Grid being around for years to come, which means you have to start
thinking about protecting that mote. Planimeter projects have been in the
works since 2010. I work in a narrow subset of the gamedev space, and don't
plan on stopping any time soon. It will be my life's work.

~~~
emmanueloga_
Thanks for the extensive answer! It is very commendable that you want to
provide such level of stability for your users.

On a side note, your comment made me check: hard to believe Love2d was
released 12 years ago now!

~~~
andrewmcwatters
Thank you for browsing my work, I greatly appreciate it!

------
TiccyRobby
Lua is a little confusing language for me because you need to throw out most
of the things you know because it has its own way of doing things, it is not
necessarily a bad thing but it is confusing. Luckily, it is a very small
language so it wouldn't take that long to grasp it all. The most confusing
thing was the fact that (almost) everything seems like a hashtable.

~~~
ebg13
Ignoring metatable weirdness, I think "you need to throw out most of what you
know" is quite wrong.

The main thing you need to know is that Lua's table type can be numerically
iterated between index 1 and the first gap where numeric index has nil value
using the ipairs iterator in addition to the non-exclusively-numeric unordered
pairs iterator. A common pitfall with sparse tables is that the length
shortcut # returns seemingly the wrong result if you aren't aware of that
first part.

Most of the difficulty writing in Lua comes from the fact that there's no
first class support for OO-style Classes, so you have to fake them, and
there's no standard library so you end up reinventing a lot.

But other than that, it's a dead simple language with few features.

~~~
grawprog
Lua's lack of integer support caused me some issues. Using floor() around
everything wasn't really an ideal solution and I ended up changing languages
for that project.

Metatables are cool, but have some weirdness to them. For OOP i ended up using
metatables to make a simple prototype(rather than class) based system, but it
was hacky at best.

Tables themselves are pretty awesome and powerful, but I have to admit,
working with them gets a bit tiresome in ways working with dedicated arrays
and hash maps don't. You have to remember exactly what kind of data is in your
tables and looping through them can be a pain.

Overall though, I still love lua, it's the language that helped me 'get'
programming and I wouldn't actually appreciate dedicated data structures and
typed variables so much if I hadn't had the experience of starting with a more
free, loose and simple language like lua. Also, its ability to easily
interface with C and be easily embedded has made it appear in so many
different and sometimes strange and just downright cool applications.

I've been playing with the solarus engine lately, it uses lua for its
scripting, it's the first time I've written any lua in a while, but i've been
enjoying it as I rediscover all the little cool things I like about it and i
still think it makes a good first or second language for people.

Having the reinvent the wheel isn't necessarily a bad thing when you're
learning. That hacky prototype system I made helped me understand OOP far
better than just using classes in other languages had. Even if it didn't
really work all that well in the end. It really made me appreciate what a
built in class system actually gives you.

~~~
spc476
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.

~~~
tpxl
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.

~~~
spc476
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.

~~~
ebg13
> _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.

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

------
nightowl_games
This looks interesting but the documentation needs more information.

I dont want to "mess around" for a few days to learn what this thing is good
at. I want to read the docs and be ready to make stuff.

eg)

[https://www.planimeter.org/grid-
sdk/api/networkvar](https://www.planimeter.org/grid-sdk/api/networkvar)

[https://www.planimeter.org/grid-
sdk/tutorials/Getting_Starte...](https://www.planimeter.org/grid-
sdk/tutorials/Getting_Started)

~~~
andrewmcwatters
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 started faster.

Thank you for pointing this out. If you're so inclined, sample game code comes
with the engine for the time being to understand how it works. I realize this
isn't completely ideal, but feedback like this is critical to the direction I
take.

~~~
mmlkrx
If you're looking for inspiration on how to organize your docs, I found this
resource really valuable:
[https://documentation.divio.com](https://documentation.divio.com)

You can see the documentation system in action in this project:
[https://www.brachiograph.art](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.

~~~
andrewmcwatters
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.

------
lostgame
I would appreciate more examples on the web site - it seems like there are
very, very few details on e.g. capabilities, etc.

~~~
andrewmcwatters
I will prioritize this based on your feedback.

~~~
cabyn
That would be awesome, going to tinker with this tomorrow!

~~~
andrewmcwatters
Thank you for saying so! I will be available if you need anything at all.

------
jmaa
Apparently the developers are reading this thread, so I have a request: Please
reduce your website's dependence on javascript. Doesn't leave a great
impression when I need to fiddle with noscript before seeing static text.

~~~
andrewmcwatters
I would do more of this if I had a simpler way of pulling documentation from
the GitHub Wiki repo.

I’m sorry the experience was poor, and I’ll consider this feedback as I make
improvements to our documentation and marketing collateral to make it nicer to
use. My apologies. I work hard to win over developers, many times one at a
time, and so your feedback isn’t lost on me.

------
_sidewalkchalk_
any examples of games made with this?

~~~
s_y_n_t_a_x
I'm making a mobile mmorpg using this engine.

We're currently in the early spriting & game mechanic planning phases but Grid
has been a perfect starting point.

It's the sweet spot in-between LÖVE (Grid extends LÖVE) and a heavier engine
like Defold, the multiplayer features are killer.

If you're wanting to make a tile-based multiplayer game, I highly recommend
it.

~~~
cabyn
Are you posting anything on GitHub publicly? I'd be interested in seeing some
sample code!

~~~
s_y_n_t_a_x
Unfortunately, not. Parts of the game I may open-source, but it won't be fully
open and it's nowhere near ready.

------
dang
Url changed from [https://github.com/Planimeter/grid-
sdk](https://github.com/Planimeter/grid-sdk), which points to this.

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

~~~
symmitchry
Does Python have any good game engines? PyGame project is a nightmare.

Lua's [https://love2d.org/](https://love2d.org/) is amazing.

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

~~~
symmitchry
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](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. I'm a total Python guy, but Pygame has always been frustrating.

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

------
panchicore3
For the record, Grid is also a racing game
[https://www.codemasters.com/game/grid/](https://www.codemasters.com/game/grid/)

