dbartolini

Why when code amount is small enough?

It is just a simple general-purpose, data-oriented, data-driven, entity-component based, lua scripted game engine written in sane C++ for my own game development needs.

Nobody's trying to sell anything here.

I already do so: https://github.com/dbartolini/crown/blob/master/src/lua/lua_...

All resource paths (.lua files are resources like any other) in Crown are unix-style and do not include the extension.

I have a custom loader that deals with it: https://github.com/dbartolini/crown/blob/master/src/lua/lua_...

Game Engine Architecture by Jason Gregory is a nice one.

Search for "Bitsquid" and "Our Machinery": pure gold IMHO.

Can you elaborate on this?

I started with game engines well before I put this project on github in 2012.

I find GENie/premake way simpler to read and write. Also, you have more flexibility since your build scripts have full-fledged Lua capabilities.

It is not "modern" C++. It uses GENie, a fork of premake.

Thanks, I'm glad you like it. :)

I guess they start over each time the requirements change? :)

Sensible usage of templates, operator overloading and namespaces is ok.

People are working towards that objective, see for example Jonathan Blow's Jai.

Hey, thanks. :)

Toolchain was initially written in C#. Vala simplified a lot the switch to GTK+3. Today I think an IMGUI-like approach is the way to go for game tools. Rewriting the editors should be rather painless due to their engine-decoupled TCP/IP architecture.

These are features and concepts kicked around by mainstream engines. In fact, this work is inspired by Bitsquid/Stingray.

When I started the project C++11 was not supported well on most compilers. I'm fine with new features when they don't limit my freedom.

I'm fine with nullptr, it is going to replace NULL very soon.

I do not use STL because I want consistent implementation across all supported platforms. Also, you have to care about memory management when you need performance or when working with memory constrained devices. The way STL deals with custom allocators makes no sense to me, hence my own implementation.

You can find demos in the `samples` folder. :)

Yep!