4 ms·

I don't think so. If I remember it correctly, the Epic guys said something about switching back (for the Unreal Engine 4) from their own scripting language to C

by dan00 9y ago

I don't think so. If I remember it correctly, the Epic guys said something about switching back (for the Unreal Engine 4) from their own scripting language to C++, because multi language debugging was a nightmare, and working on a big Python/C++ project myself, I can comfirm this.

honestoHeminway 9y ago
Arr, the inevitable defeat by the core languages performance boost- lets allow for pointers to arrays in the core language, to not loose speed. The locks and non-locks, the fun of value changes while some variable holds part of a array in local memory of the script languages maschine, the problem of external data corupption, without having everything under assert all the time aSSERT(Not NaN, Not Infinity). Plus, the script languages garbage collection, making a custom allocator necessary- allmost like the one you allready have written. On and on it goes. If it where not for the artists ease of use and fast iteration, nobody would use the script languages.
- oblio 9y ago
  > If it where not for the artists ease of use and fast iteration, nobody would use the script languages. Aren't those core tenets of game production? :)
MaulingMonkey 9y ago
Without the right tools, multi language debugging is a nightmare. A mixed C/C++ callstack is so benign and common that it likely won't even register as being a "multi language" debugging experience. You get a single unified stack display, breakpoints, the works. There's a caveat or two around exceptions - that's about it. Everything just works. C#/C++ isn't quite as solid, but it's still ahead of Python/C++ IME. Namely, Visual Studio will again show you a single unified callstack. There are more warts - again involving exceptions, as well as crash dumps and after the fact debugging. I've occasionally needed to break out WinDbg to deal with this. Python/C++ is a bit harder. If you don't have a debug engine that can unify callstacks, however, there's still stuff you can do - dumping out both C++ and Python callstacks (and possibly locals) programmatically on assertions and in crash handlers, for example. I've done this for Java/C++, ActionScript/C++, Squirrel/C++, and probably more that I've forgotten. "Own scripting language"/C++ is harder still: you must build your own everything. Debug engines are big projects - I haven't even completed my standalone one for brainfuck. If you dump your callstacks, you not only have to use the APIs that let you do so, but write them in the first place.
- ska 9y ago
  "C#/C++ isn't quite as solid" is a bit optimistic, in my experience.

by dan00 9y ago

honestoHeminway 9y ago

Arr, the inevitable defeat by the core languages performance boost- lets allow for pointers to arrays in the core language, to not loose speed. The locks and non-locks, the fun of value changes while some variable holds part of a array in local memory of the script languages maschine, the problem of external data corupption, without having everything under assert all the time aSSERT(Not NaN, Not Infinity). Plus, the script languages garbage collection, making a custom allocator necessary- allmost like the one you allready have written. On and on it goes. If it where not for the artists ease of use and fast iteration, nobody would use the script languages.

oblio 9y ago
> If it where not for the artists ease of use and fast iteration, nobody would use the script languages. Aren't those core tenets of game production? :)

MaulingMonkey 9y ago

Without the right tools, multi language debugging is a nightmare. A mixed C/C++ callstack is so benign and common that it likely won't even register as being a "multi language" debugging experience. You get a single unified stack display, breakpoints, the works. There's a caveat or two around exceptions - that's about it. Everything just works. C#/C++ isn't quite as solid, but it's still ahead of Python/C++ IME. Namely, Visual Studio will again show you a single unified callstack. There are more warts - again involving exceptions, as well as crash dumps and after the fact debugging. I've occasionally needed to break out WinDbg to deal with this. Python/C++ is a bit harder. If you don't have a debug engine that can unify callstacks, however, there's still stuff you can do - dumping out both C++ and Python callstacks (and possibly locals) programmatically on assertions and in crash handlers, for example. I've done this for Java/C++, ActionScript/C++, Squirrel/C++, and probably more that I've forgotten. "Own scripting language"/C++ is harder still: you must build your own everything. Debug engines are big projects - I haven't even completed my standalone one for brainfuck. If you dump your callstacks, you not only have to use the APIs that let you do so, but write them in the first place.

ska 9y ago
"C#/C++ isn't quite as solid" is a bit optimistic, in my experience.