Show HN: Toy – A thin C++ game engine | Hacker News Reader

Show HN: Toy – A thin C++ game engine

hugoam.github.io

180 pointshugoamnov38 comments

"toy is under heavy development"

If your commits in the last week keep their pace, you may as well have this statement be a clickable link to the github activity page:

https://github.com/hugoam/toy/graphs/commit-activity

But if you slow down significantly, change wording to "active development"

Not knowing anything about game dev, your presentation page looks great. It's nice to see all the important pieces mentioned (3D, audio, physics, scripting). I think you did a good job on the page.

Note that the engine is licensed under GPLv3. Which means that any game must be licensed as such as well.

Hi, the license is a temporary choice. I wish to release it under a permissive license in the future, I'd just like to secure a tiny bit of funding before that !

Just a note that if you accept any merge from anyone else, when changing the licence, you'll have to have their consent to change the license as well. Sounds like it might be a difficult thing to switch, depending on how many contributors you'll have when wanting to switch.

Is that true though? I thought all third party contributed changes are licensed separately, with the contributor still having all rights, unless they explicitly say otherwise.

IANAL: My understanding is the same as @halfastack's.

> I thought all third party contributed changes are licensed separately, with the contributor still having all rights, unless they explicitly say otherwise.

That's true, but it prevents the project owner from changing the license unless either the contributed code's license is compatible with the new license, or all contributors consent to the license change. That is, going from MIT to GPL is fine, but GPL to MIT is not.

Projects concerned with this frequently require contributors to sign a CLA (Contributor License Agreement) where the contributor gives permission for the project to use the contributions and relicense them in the future. E.g., Ubuntu [1].

[1]: https://www.ubuntu.com/legal/contributors

I don't think that's quite accurate either. Although you can include MIT-licensed code in a project that is, as a whole, licensed under the GPL, you still must include the original license and copyright, rather than "going from MIT to GPL."

For example, if you have an MIT-licensed project and I contribute to it, my MIT-licensed contribution will remain MIT-licensed, regardless of what you do in the future. If you change your project license to GPLv3, and later can prove that someone used my code from your project after downloading your project's source, I do not think you will be able to successfully hold them to the GPLv3 and force them to release the source of their derivative work.

My understanding is a bit different, but also not a lawyer.

> going from MIT to GPL is fine, but GPL to MIT is not

AFAIK both are _not_ fine, eapecially because the licenses are totally incompatible.

When you publish a patch under a certain license (that of the project at the moment of the contribution), you _only_ allow using your code under that license. This is why dual licensing is a thing.

Except when you sign a CLA - mostly used by companies to gain copyright over your work. In that case the company can do whatever they want - even charge you later to use your own code.

> AFAIK both are _not_ fine, eapecially because the licenses are totally incompatible.

MIT licensed code can be relicensed under GPL with or without modification to the code. It is only the other way around that won’t work. The reason for this are the specific demands made in each license.

See https://www.gnu.org/licenses/license-list.en.html#GPLCompati... where the Expat license is listed as compatible. The Expat license is the same license that is usually referred to as the MIT license.

Also https://en.wikipedia.org/wiki/MIT_License:

> The MIT license is also compatible with many copyleft licenses, such as the GNU General Public License (GPL); MIT licensed software can be integrated into GPL software, but not the other way around

IANAL.

Personally I encourage people to prefer the ISC/BSD/MIT family of license over GPL, but anyone that is set on using a GPL license is within their rights to do so for code derviative of said licenses (and several others as listed in the above linked list of GPL compatible licenses).

Possibly true... but wehther it can be done without modification to the code is a separate issue from whether a license change can be made without the consent of all contributors.

What I am saying is that anyone can take MIT licensed code and re-release it as GPL licensed code. That includes anyone of the author without consent from the other authors, or even someone who was not an original author. Specifically because such a change does not violate the terms of the MIT license. Whereas for going the other direction; GPL -> MIT you need consent from all authors (either directly or via a CLA that permits such a change of license).

With incompatibility I meant copyright and patents et al. Not whether you can link MIT from GPL code.

Using a different license on the exact same code withoit consent is very different from linking to that code respeciting its original license.

Investor funding or patronage?

I need to investigate this question :) For now, I just setup a Patreon, but in the future, I might think of a more clever business plan.

License your work under GPL3 and if someone want to uses your engine in a proprietary game, then you can sell him your game engine under a permissive license. Just be sure that the other contributor are okay with it.

GPL has great provisions against hostile forks, but as is it's a bit too restrictive for games as final products.

I'd imagine that LGPL would give both an incentive to contribute to the engine, and a way to commercially release games based on it, without GPLing all the assets and all the game mechanics.

LGPL isn't great for games either.

One of the most celebrated changes in SDL2 was moving from LGPL to ZLIB license. All the linking requirements of LGPL are a pain for games and distribution.

Then how about “GPL with the static linking exception” (used by glibc, which is statically linked by zillions of non-open softwares).

AFAICT, that license comes down to “You only need to publish changes to our GPL code, not your own code that uses our code”. So, it’s non-viral.

I think you meant "Lesser GPL with the static linking exception". IIRC glibc is "stock" LGPL 2.1 without any linking exception, so I may have misunderstood your comment and you mean just LGPL.

The LGPL is not viral but it has some requirements that are inconvenient when distributing a game, specially it makes static linking impossible.

You are right glibc is LGPL. It's libstdc++ I was thinking of https://gcc.gnu.org/onlinedocs/libstdc++/manual/license.html

Looks like what I'm looking for can be found in MPLv2 https://www.mozilla.org/en-US/MPL/2.0/FAQ/

Ex: http://zeromq.org/area:licensing is currently LGPLw/exception, but intends to move to MPLv2 because it is legally more clear.

I like how many modules are designed to work in "immediate mode", it makes playing around with stuff very easy and satisfying.

Mud is an odd choice of name for a component of a graphical games engine, given that a MUD is a Multi-User Dungeon: the old-school style text-only MMORPG. (There are still a few active ones such as Alter Aeon and Miriani).

I immediately thought of MUD's as well. There's an active community on Reddit and still many hundreds (maybe thousands) online and playable!

If your game engine supports multiple scripting languages, including one that is graph-based, maybe it’s not that “thin” anymore.

Looks very interesting, but not what I expected a "thin" game engine to be, as it seems fully featured; Obj importer, physics, UI components and sound capabilities.

The second row of the main page states this: "The first concern of toy is to bring the thinnest and simplest stack of technology for making games directly from C++, instead of focusing on a monolithic editor, or insulating the user from the core systems."

So I think this is "thin and wide", instead of "thin and small". Having all the components you need and having them directly accessible counts as thin in my opinion.

Fair enough, my interpretation of a thin game engine is a thin abstraction over the mechanics of the game... but now that I think about it, this is exactly that...

It's thin in the way that all the goodies are in separate modules that you don't have to use, and also in the way that it still runs in the browser with all these goodies.

But it's also not so thin, you are right :)

Great idea, I recently did an opengl project and just getting TinyOBJLoader to work was a task in it self.

Thin & Batteries Included!

Look at the example code further down: the engine isn't a heavy framework with tons of abstractions between the big systems and the game code. You get to directly access and drive all the individual systems yourself.

The most common "big" game engines don't allow that. There you get a big, quite opaque runtime that somehow will do rendering, sound, physics and networking and occasionally call individual fragments of your game logic in between.

Tried it on my 2016 Macbook Pro. Has some performance issues, I don't know how many exactly, but I'd say I'm getting around 10 FPS or less.

The PBR pipeline of toy is not well optimized yet: I'll have more time to tackle this issue now that the heavy lifting work has been done !

Framerates are much better in the non-web version somehow: I suspect some unnecessary texture sampling ops are to blame, but I need to investigate.

Resizing the window to a smaller helps greatly improve the framerate, which tends to show that the bottleneck is in the fragment shaders.

Seconding the performance issues (at least on web). For comparison, https://kripken.github.io/misc-js-benchmarks/banana/ these demos run fairly smooth for me on their highest settings.

Engine looks good. Open source needs more projects like this.

That GPL3 in the license.txt is a fun document full of dark places where less experienced adventurers might get eaten by a grue. Certainly makes it easier for plenty of interesting times and exciting quicksand sidequests for those without a suitable guide.

Holy crap, yeah... "thin" huh. Might want to define your terms lol

But for real, this looks great, I'll poke around it a bit more on the weekend, but it looks pretty darn good as it stands

Those demos were amazing. Makes me want to learn C++ instead of Go. :)

Wow impressive, wish you the best of luck with this project

Outstanding concept, I like the thin&wide idea.

Reply on news.ycombinator.com