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 with.
4. Effortless C interop. You can make lua bindings for anything written in c with minimal effort.
Now to this specific engine. lua has one of the simplest and most beloved game frameworks out there - Love2d. its almost a foundational game framework for so many people (like pygame in python, XNA etc), including yours truly. Its been a beginners choice for over a decade now. Grid is built on top of Love2d.
btw, just in case you are interested in a python game engine, you should try out Arcade. Its pretty feature rich and aimed at beginners.
Regarding the specifics: Lua is very simple, you can keep the whole language in your head easily, the table mechanism is very powerful, and the whole thing is easy to embed. Which is why it was used in commercial games and thus is industry/genre-relevant.
Lua's https://love2d.org/ is amazing.
https://pygame-zero.readthedocs.io
https://github.com/mjbrusso/game2dboard
Disclosure: I am the author of game2dboard
Never gotten a satisfactory answer.
Another reason for using Lua in games is that its garbage collection strategy is well-suited for the task.
Python uses reference counting (which has a predictable performance profile but can lead to long pauses if a large object graph is deallocated at once) and stop-the-world GC for reference cycles.
Lua is both easier to embed and allows you to have a strict interface. Look up the history of bastion/rexec in Python - with python there's no possibility of controlling untrusted code.
The cost is a less elegant syntax. I understand a lot of folks hate working with Lua, but it fits a certain niche.
Much like many people turn to Python for scientific scripting, for example, Lua has gained a reputation for being easy to use in the game development world.
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
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.
If so, it would be nice to list them on the homepage.
In Grid, I extend the package library, and utilize the implementation details of `module` which allow one to override or set new keys on subsequent loads of the same file.
It's one of the reasons I don't think I can use the newer module patterns beyond Lua 5.1.5, because as far as I understand, they require one to completely replace what's stored in `package.loaded` versus merging to any existing table.
I had also not given much thought to static typing with Lua until the last year or so working with Lua only because it makes generating documentation harder. Otherwise, I tend to share Roberto Ierusalimschy's opinions of dynamic typing.
I would read his most recent interview from Moscow in 2019. I think he's a very interesting person.
Planimeter was formerly called Team Sandbox, and we were a group of developers working on a game called Half-Life 2: Sandbox, which was a FOSS alternative to Garry's Mod that stayed Half-Life themed.
The team is comprised of mostly different volunteers now.
Astounding work as always. Thanks!
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.
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.
My pet peeve is that it's somewhat verbose in using keywords rather than single-character punctuation to mark blocks and clauses.
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/tutorials/Getting_Starte...
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.
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.
I suggest for the Tutorial sectiona that you walk the reader through making the type of game that you think this engine excels at making.
Would also like to know more about the networking capabilities.
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.
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.
