I love the article! It makes sense that after developing AR application on a game engine, I will identify the common functionality that would fit better for an "engine" that would fit the ideas I want to develop.

I am interested in developing AR applications that are not as much of a game, so I was worried that a game engine would not fit.

With both learning more about graphics and making my own games, it would make future engine development more clear.

> I guess. The question is why should I have to work around Unity?

When shipping a production-quality game there's almost always going to be something you have to customize or work-around with any engine. What often happens with home-grown engines is that the cost of tools friction or engine implementation is not properly accounted for, because it's kind of fun although it's unproductive.

> But that is not every game and every team.

Agree, but I'm fed up with the amount of FUD around Unity. I've watched teams burn money rather than putting up with some annoyances. I'm an older dev (40+), so I've seen many iterations of devs refusing to use existing tool X in favour of supposedly more convenient but less battle-tested tool Y. This is in game development, and software development, more generally.

There are also holistic benefits to Unity, like 1-2 second recompiles. This is a game-changer in terms of debugging and allowing you to try more iterations of things.

> We don't have to compare Unity to utopian engines and tool chains when we can compare it to its competitors like Unreal.

I think Unreal is a great engine, and I'm admittedly less familiar and therefore productive with it than with Unity.

That said, I would say that for mobile or small-footprint games Unity still has an edge. This is based on the experiences of several studios / devs that I've talked to. They make great headway with Unreal, but then the project bogs down when it's time to actually ship. That said, this could be Unreal FUD from developers who are new to that engine.

To get the benefits of Blueprints in Unity, just buy PlayMaker. It's $65 dollars a seat, and you'll never write another Finite State Machine.

If you're genuinely interest the developers of Inside have a great presentation on how they hit a stutter free 60fps on all platforms, PS4 included.

https://www.youtube.com/watch?v=mQ2KTRn4BMI

I don't know what projects you're referring to specifically on the PS4 but I'd suspect the difference comes down to hardware spec on the PC masking the issue, it probably being the primary platform and/or lack of time to work on optimisation for the port.

It's the use of C#, which generally written in a manner that creates garbage and lack of experience with programming games that causes many people who use it to go wild with allocations. Both intentionally and by accident. These days you can actually get pretty far before it's ever a problem on a gaming PC. Unity is also incredibly accessible so more people with less technical chops are programming games without even opening the profiler.

That's because D's standard library doesn't use templates in the same way as the STL (No iterators, less policies). Also, D has is actually vaguely modern and has proper static reflection, static asserts and static if: Writing template constraints is easy, unlike C++ (even with Concepts/-lite)

Yeah, similar sentiments in the PPT presentation here: https://onedrive.live.com/view.aspx?cid=171ee76e679935c8&pag...

CMake is "too complicated" and "you need to be an expert". Understandable, I suppose. There are certainly specific things in CMake which are pretty terrible, like the add_custom_command/add_custom_target dance, but from the perspective of someone who has had to become an expert in it (via ROS/catkin), I would be unlikely to give it up. There's just way too much stuff it gives you for free, especially when it comes to things like packaging, testing, etc.

Okay, the other thing I would say having examined this a bit is that GENie seems to be much more "project" oriented than CMake. CMake has a concept of projects, but its usual model centers around targets and directories as the main unit to reason about. That is, CMake's most native output format is a Makefile, with adapters to generate IDE projects.

GENie seems to be focused first and foremost on a project/solution-oriented IDE workflow, with the Makefile generator as the one that's tacked on. So I can definitely appreciate that if you're working on a project where everyone's in an IDE anyway, it would make sense to use a generator that has the IDE's concepts as a first class citizen.

> What do you do regarding collections? (Dynamic arrays, hash maps)?

I don't do anything!

I use the most appropriate data-structure and minimal transformation necessary to get the work done. I use maths and higher-level tools to verify my designs but the implementation, when required to be soft-realtime needs to exploit as much mechanical sympathy from my target platform as possible.

You might be interested in https://dataorientedprogramming.wordpress.com

Cheers!

Indeed collections are a stinky bit, but fortunately they are not the majority of the code. Generally i either do a "list of pointers" (for example http://runtimeterror.com/rep/engine/artifact/0a8bb29493c782f... from my own C engine) or i define `DECLARE_LIST(type)` and `IMPLEMENT_LIST(type)` macros which declares types and functions for handling those (note that with the word list "list" in both cases i mean a conceptual list of items, not the data structure, in practice it isn't a linked list but a vector). The latter can be faster, more flexible (e.g. you can specify how the comparisons are done so that you can use == for simple stuff, strcmp for strings, memcmp for structs or custom calls for more complex structures) and more type safe but on the other hand it can be very annoying to write, debug and extend which is why i rarely do it. Another way is to use an include trick where you do something like

    #define TYPE int
    #include "list_template.h"
    #undef TYPE

with `list_template.h` using TYPE wherever a data type would be needed and defining inline (C99) and/or static (C89) functions so that they can be redefined in multiple files (or have a dedicated C file that includes the above header with all data types and an additional macro that enables the implementation). This is basically sort of implementing templates in C.

The void pointer approach is the simplest and most macro free (despite me using macros here, i'm a bit macro happy sometimes :-P) but at the same time you are limited to pointers. In practice i've found that most of the time this is enough, which is why i still haven't replaced that yet. But there are cases where i'd prefer to be able to have a list of structs instead of pointers to structs, both because it is simpler (no need to define a custom free function) and faster (less indirections), so i'll most likely replace that code with another approach (most likely the macro that defines the types, not the include header).

But if there is a single feature i'd like to see from C++ to C that would be templates, even if they are single depth. I don't even care about classes or the other stuff (classes are nice to have, but not necessary as long as the compiler can figure out that the template parameters to structs and functions with the same name refer to the same type when used together).

I would recommend that you extend `package.loaders` instead. You risk breaking expected `require` functionality. Then you get the benefits of both!!

https://www.lua.org/manual/5.1/manual.html#pdf-package.loade...

Bingo. This helps restrict the fragmentation from dynamic strings to one pool of memory, allowing the others to remain nicely packed, aligned, etc (whatever your ideal for them is).

I wouldn't predict a lot of overlap. On the game dev side, Go offers nothing new, and the forced untuneable gc will be an instant turnoff for the usual reasons. On the Go side, my outside perspective is most of its users seem to be focused on web server backends, trying to justify async everywhere, and/or rewriting slow Python or Perl or Bash scripts and assuming that makes it a systems language.

Go users interested in diving in to SDL or OpenGL bindings to make a game shouldn't be discouraged. Lots of games are made in all sorts of high level languages, the heavy lifting is put onto a few native libraries. But if the goal is to make a general engine, I'd question its utility apart from fun/learning. Again there are game engines in high level languages (with dark native-level secrets in any that try to be performant) but they don't seem to get traction. Even an engine in e.g. C++ doesn't necessarily help your performance goals (http://www.yosoygames.com.ar/wp/2013/11/on-mike-actons-revie...) if your plan is to make it general instead of make it just support whatever sorts of games you're making and planning to make.

A slightly related note: you can get similar behavior in C (and C++) with compiler extensions. In GCC and clang marking function with '__attribute__((warn_unused_result))' will produce a warning if function is called without using the result. Equivalent for MSVC is '_Check_return_'.

Obviously this is not nearly as convenient as your Rust example, but enables some of its the benefits.

Not all language-level GCs are untuneable .

Also if one doesn't allocate like crazy on the heap, there is no reason the GC needs to work.

> Being able to opt in to GC where it's useful is great, being forced to use it everywhere can be a hassle.

True, but just because a programming has language level GC, it doesn't mean it must be used everywhere.

If one doesn't allocate like crazy on the heap, there is no reason the GC needs to work.

Also using value types is always an option.

One also doesn't call malloc() in such high-performance subsystems.

Right, but that was a long long time ago, 64 bits long. Even calling it "STL" nowadays kind of dates someone. I wonder how regularly EA currently does bake-offs between their stuff and the standard library. Not that it would matter at this point--they probably have so much legacy code depending on it that it would be painful to switch.

Of course I don't know--that's why I said "I wonder". I have, however, worked in non-game-developing companies who eschewed the standard library, and when pressed the argument boiled down to: someone who worked here long ago said the STL was slow and therefore we don't use it. I am _wondering_ if it's the same story at other companies.

Probably because exceptions are the biggest source of pain with RAII.

I mean it's kind of a smartass answer, but—don't fail during constructors. Move all possible code that can fail into an initialize method; check explicitly for allocation failure and/or put things on the stack instead of heap when possible; consider failing hard with a stack trace or core dump over catching and processing exceptions before (likely) failing anyway.

Instead of using a constructor you can use a constructor method e.g.:

    class Foo {
       public:
          static std::optional<Foo> create();

       private:
          Foo();
    };

Yeah, at some point it doesn't matter what language if the game is just game logic on a standard input and output layer that are already fast. Even high end engines like CryEngine often include a scripting layer in some higher level language like Lua that probably has GC, because it's nice to have for game logic that doesn't have the same constraints as other parts of the game. (http://docs.cryengine.com/display/SDKDOC4/Lua+Scripting)

As I mentioned in another comment a lot of fun games have been made in all sorts of languages. That doesn't really make any of them suitable for games though, and you'll still find far fewer examples of game engines in GC languages.

So, allocating memory for objects is not part of construction? Again, why not just stick with C?

I don't think this is the proposal. The proposal is that the object contains a genuine constructor that only does the bare-bones "safe" stuff, and then it has a separate non-static method that does the might-fail initialization. So:

  class Foo
  {
  public:
    Foo();
    bool initialize();  // returns success
    ...
  };
  ...
  Foo foo;
  if ( !foo->initialize() ) { // handle error }

This also means you can break up your initialization so that you drive the risky pieces from outside the object, rather than monolithically from within.

This has a further benefit for testing, since you can use your major objects without fully initializing the entire world that they depend on.

I agree that 2PI leads to all kinds of pain, but what I meant is not 2PI. Here's a more complete example:

  class Foo
  {
  public:
    static Foo* create()
    {
      Foo* result = new Foo();  //exceptions disabled so new can return nullptr
      if ( result )
      {
        //configure result here
      }
      return result;
    }
  private:
    Foo() {}
  };

  ...
  Foo* badFoo = new Foo(); // compiler error because Foo() is private

  Foo* foo = Foo::create();  //all good, no 2PI and can't forget to call initialize code
  
  if ( foo ) //check for non-null, note, if using an optional you'd also need a similar check
  {
    ...
  }

Now the only way to create a Foo object is through the create() function and there is no separated initialize - it all happens in the same place.

This pattern of using a static create method is explicitly designed to avoid 2PI and is very common, especially in codebases that disable exceptions.

Also note that I'm not personally advocating using it, just that it is commonly used to avoid 2PI.

There are lots of cases out there where the so-called "zombie" state is a perfectly valid one, and may for various reasons be preferable to representing that state externally (for example, with a null pointer). Such an object is simply a placeholder instance of the object that is ready to do work, but not yet actually doing anything. If necessary, it can check its internal state and throw exceptions when not-valid-while-uninitialized methods are called.

The examples that come immediately to mind are the Publiser, Subscriber, and Timer classes that are part of the ROS C++ API: http://docs.ros.org/api/roscpp/html/classros_1_1Publisher.ht...

I agree that there are caveats with it, but I get nervous when people toss around a phrase like "known antipattern" with such confidence.

> It forces heap allocation though, which is bad.

It does, and it can be, but in situations where it matters, the static create function typically returns a value from a preallocated pool of memory, so objects are all contiguous and cache friendly.