Comment by git-pull | Hacker News Reader

Comment by git-pull | Hacker News Reader

This is a cool project!

- CMake, yay! These make generating build files for a variety of platforms (even Windows) a breeze. It also works with code completion stuff (CLion IDE, KDevelop both have CMake-based projects)

- I like how it splits stuff up as well (https://github.com/klaussilveira/qengine/tree/master/src/gam...).

- As for vendorizing SDL2, there is an opportunity for optimization: The shared libraries and header files can be scanned through CMake scripts. Example: https://github.com/tcbrindle/sdl2-cmake-scripts.

- I see the .clang-format file, nice! (This is for clang-format: https://clang.llvm.org/docs/ClangFormat.html)

Unfortunately, license is going to be a real barrier to most game developers. The ironic thing is this engine includes SDL 2 which prides itself on being on a permissive license. (https://youtu.be/MeMPCSqQ-34?t=405, 6:40 to 7:30)

If it's the intention to create an open source library to be helpful as possible to developers. If it's the intention to have a library just for use in the GPL ecosystem of games (which isn't bad: OpenTTD is GPL!) then this is okay.

The reason why is a private game developer want to retain control of their intellectual property, even throughout the prototyping phase.

As for open sourcing, I'd approach it in a different way: I'd release reusable components under a permissive license (e.g. MIT, BSD, ISC, zlib, etc.) and keep any creative work product code/source files private.

Similar SDL2 framework for 2D games (I made some CMake contributions a while back): https://oxygine.org/

> As for open sourcing, I'd approach it in a different way: I'd release reusable components under a permissive license (e.g. MIT, BSD, ISC, zlib, etc.) and keep any creative work product code/source files private.

I don't know how much the author has control here; it is derivative of id's Q2 engine which was open sourced as GPL.

The license can be a problem for some studios, specially ones with uncomfortable contracts with publishers. If you are in that situation, I highly recommend writing a LuaJIT integration layer.

The game code is very well separated from the engine, and qengine already removes a lot of non-generic game code from Q2. So all you have to do is delete a little bit more, write some glue code to tie in Lua, and you can write the entire game logic in a separate codebase, with a separate license. Also, you get moddability.

I think using Lua scripting like that still counts as "dynamic linking" from the point of view of the GPL.

https://www.gnu.org/licenses/gpl-faq.en.html#GPLPlugins

probably so.

https://www.gnu.org/licenses/gpl-faq.en.html#IfInterpreterIs... also seems relevant.

stallman's portion of https://lists.debian.org/debian-legal/2002/11/msg00217.html too

Never thought of that. What if code is compiled to VM bytecode first?

The examples in the FAQ imply that they consider separate binaries that share “complex” data structures to be parts of the same program, blurring the line for what counts as dynamic linking.

The Lua interpreter itself would still be under GPL but the code that the Lua interprets would not since as far as the interpreter is concerned the script is data. The GPL even has a section on this:

https://www.gnu.org/licenses/gpl-faq.en.html#IfInterpreterIs...

But the Lua scripts would be bound to the underlying game engine. I would all come down to whether or not a judge would see it as a derivative work.

Lua is MIT licensed. The point is that if you have a GPL game engine and use lua scripts to turn it into a full game then you also need to license the scripts as gpl if you want to distribute the game.

(As others pointed out , oif you are looking for a loophole, game assets might be a better way to go)

Another one for SDL2/Lua is LÖVE: https://love2d.org/

Reply on news.ycombinator.com