eigenbom

From their GitHub page: "ChaiScript is one of the only embedded scripting language designed from the ground up to directly target C++ and take advantage of modern C++ development techniques, working with the developer how they would expect it to work. Being a native C++ application, it has some advantages over existing embedded scripting languages:

It uses a header-only approach, which makes it easy to integrate with existing projects.

It maintains type safety between your C++ application and the user scripts.

It supports a variety of C++ techniques including callbacks, overloaded functions, class methods, and stl containers."

There's no implication there.

Life is way more complex than an isolated study might lead you to believe. Read research, but be aware of its limitations.

I was agreeing with him!

Oh yeah, no chance. The best outcome for me is to earn enough to keep making games.

The game is my life, but so are my wife and daughter. It's a life!

Hi Sam!

Sorry!

And so marks the end of the std::graphics era. I originally thought it was a good idea, but now agree that a graphics API like that has no place in standardisation.

In libcxx it's a few lines. Unless you also count the overloads for initialiser_list etc.

Americans invented the laugh track. ;)

Best joke I've heard all day.

I'm excited by this feature, along with all the other compile-time programming stuff (reflection, concepts). The downside I see is having to remember how a metatype works.. e.g., the default access type for member variables of struct, class, interface, value, .. and on and on. But if we keep the number of metatypes low, this may manageable.

Seems like a very broad definition that would place science, religion, and this comment within the sphere of art.

fixed point is often used for that case

Took a few rounds but the Angels were in on this one.. ;)

Thx!

I think she triggered an interrupt in my brain and now I'm running a deep hidden subroutine..

Haha with a constantly changing ABI right? Thx :D

You could definitely make them full entities, it would depend on your use case. If you're making a bullet hell shooter then maybe bullets need to be handled as a special case. Either way best not to get caught up in ideology or finding a perfect architecture, just do what works for you and your game.

It's a problem, but I'm not sure it's a big enough problem to seek out an alternative architecture altogether.

Bullets probably would be simple structs in a shooty game, not full blown entities.

The next step beyond that simple approach is to store the components outside the entity. E.g. using SoA that Jon's new language has support for.

In my game (http://moonman.io) i use an approach similar to that in the bitsquid engine, with static polymorphism and crtp and other nonsense. It works but i admit is probably overkill.

Have you written about this in more detail Jon? I'd love to read about it.

I'm not sure if there's an explicit definition somewhere, but i think an ECS could be as simple as an entity struct that contains an (optional) physics struct, that is then operated on by some physics module.

A good retrospective. I'm always inspired by Evan's passion and ability.

I think there's a distinction between prototypes of parts of the game and the full game.

I remember Carmack building a prototype of the texturing system for Rage to see if it would all work, so maybe the prototyping was always just an implicit part of JC's programming.