I feel the statement "it does not require any Shader ... compilation" is a little misleading. I see elsewhere in the documentation that glsl is used, but that just means that the gpu driver is compiling it when it's first used. I assume you can cache the compilation for the next run, but editing the shader (I can't find anything saying you can) will need a recompilation. I only assume editing is available due to this line "The engine provides a Complete Editor and all the functionalities you may expect from a Commercial Game Engine"
Overall I think I'm just nitpicky since I work on rendering code all day so this just feel wrong to advertise. Last time I tried opengl first-render hiccups were still a problem. I've mainly been in directx/vulkan land since then so maybe all the major gpu vendors have already fixed this problem. But whether or not that makes the statement better I don't know.
Edit: I will note that I still think it's cool. Making a game engine from scratch is not an easy feat, so it's impressive none-the-less.
The first time I encountered Python was in 1999 when there was a desktop 3D engine scriptable in Python. The engine was presented in a local deadwood magazine. The engine was called Alice.
I have attended two conferences for educators using Alice in their Computer Science curriculum (back in the mid 2000s, I think). The Alice Team at Carnegie Mellon were great in their efforts to make something for educators teaching CS at the high school entry level. In fact, one of the workshops was shortly after Randy Pausch passed away. I remember it being a pretty somber time on campus at CMU.
Don Slater and Wanda Dann (two of the original Alice team members) were extremely approachable and helped me build a darn good high school CS curriculum that offered many classes for kids in a pretty low socioeconomic school on Colorado's front range. Don even was an old-school tabletop sports gamer who played a lot of Paydirt (an Avalon Hill title) back in the day.
I was a bit of throwback and taught kids text editors, SVN (they just wanted to use "Dropbox" to collaborate), and Linux (my classroom was a Linux LAN and it was pretty fun to teach kids how to administer it with me)--I appreciated Alice as a great way to get kids working on day 1 on programming concepts.
Using recursive methods to make a shark attack a person swimming in the ocean was one of the lessons I used to teach. In fact, if you want to pretend you're a freshman in Intro to Computing, my lesson (for the level 4 challenge: the advanced level) is still in Vimeo:
Be kind :-) I was stretched so thin. I basically created the entire HS CS curriculum (except for APCS), and I would create these screencasts just in time, adjusting them as necessary for my students that year.
You really want a higher performance language than python for things like games. C# is a decent compromise, since you can do some tricks to avoid garbage collection, but python? It'd have to be a situation like sklearn and numpy where all the actual functionality is implemented in c/c++ and you're just using it as a glue language to coordinate those pieces, and at that point it's basically c/c++ already with python acting like unreal blueprints or something
Even if you managed a good framerate, would you get good uniform frame pacing?
> It'd have to be a situation like sklearn and numpy where all the actual functionality is implemented in c/c++ and you're just using it as a glue language to coordinate those pieces
You've just described most game engines that use a "scripting language" - even those that use C# do it this way (barring maybe one exception I can think of)
The only thing we do is P/Invoke native draw calls. OpenGL, DirectX, Vulkan, they expose C functions that we call with pinned memory. That’s about where it stops. Everything else is in C#. Events, actions, game logic, networking, file system, all in C#.
I can think of MonoGame and Stride as examples/exceptions, though I suppose there are more out there, including peoples' own engines. Most popular engines that expose a C# interface officially or unofficially take the other route. But I grant you that the oft-given reason for this - performance - isn't impossible to achieve with pure C#, it just takes a lot more skill and knowledge, and that performance via native calls to a C++ engine aren't always more performant anyway due to marshalling.
In Unity you often use C# for some fairly performance critical stuff. That's one of the reasons they bothered with the Burst compiler, the Jobs system and native arrays.
Well, Unity is a good example of this, because most of their techniques involve transforming your C# code or assembly into something else that doesn't run on the .NET runtime, or else having you structure it so that it can be offloaded - directly into C++ code in IL2CPP, or using LLVM to turn the IL bytecode into machine code with Burst. I don't know much about the Jobs/DOTS stuff but I assume the restrictions around it and how you use it are either due to it being based on a strict call-out to C++ code, or else some underlying "unsafe" C# code that Unity is managing safety around via structure - from a little reading it sounds like probably both.
Do you really want your designers to have to learn python though? If they're learning python, they may as well learn c# or c++ and go all the way into programming. Unless it's a visual novel I guess, where renpy is popular
Why does it have to be used by designers? Programmers can get benefit from the faster iteration time and level of abstraction from the engine code. It's also really nice for onboarding juniors. My first game dev job was as a junior gameplay programmer at EA working mostly in Lua on top of a C++ engine.
A lot of people who are designers and artists already know Python because of its heavy use in 3D pipelines. Honestly I'd argue it makes more sense to also let them do scripting in something they already know.
> Python is used for scripting the editor only, not in-game behaviors.
> For implementing entity behaviors the only out of box ways are C++, ScriptCanvas (visual scripting) or Lua. Python is currently not available for implementing game logic.
C++, Lua, and Python all implement CFFI (C Foreign Function Interface) for remote function and method calls.
> You can use CFFI to generate C code which exports the API of your choice to any C application that wants to link with this C code. This API, which you define yourself, ends up as the API of a .so/.dll/.dylib library—or you can statically link it within a larger application.
Apache Arrow already supports C, C++, Python, Rust, Go and has C GLib support Lua:
> Sklearn-pandas: This module provides a bridge between Scikit-Learn's machine learning methods and pandas-style Data Frames. In particular, it provides a way to map DataFrame columns to transformations, which are later recombined into features.
> By default, these functions and all other IO reader functions return NumPy-backed data. These readers can return PyArrow-backed data by specifying the parameter dtype_backend="pyarrow"
> [...] Several non-IO reader functions can also use the dtype_backend argument to return PyArrow-backed data including: to_numeric() , DataFrame.convert_dtypes() , Series.convert_dtypes()
> glue language ... at that point it's basically c/c++ already with python acting like unreal blueprints or something
Yeah, I mean that's pretty much the main role of a game engine's scripting language - gluing the lower level pieces together in the game-specific way. We use Python for all of our runtime application logic in UnrealEngine and performance is far beyond good enough and significantly faster than blueprints.
It depends on what you're doing. Computers are fast! Like, really fast! And not every game is an AAA, fully 3D title with ray tracing and etc etc. Games are such a broad topic and I believe people can absolutely make games in Python without spending all of their time fighting GIL monsters and garbage collectors.
If you're talking about people doing things because they want to, then yes, go for it, have fun.
But performance does matter. The technical state of the art (ray tracing etc) is largely irrelevant. If you make a game with cutting-edge technical features, the performance of it will be judged accordingly. If a game with a modest feature set demands resources in excess of its apparent need, it's wasting those resources.
In other words, a washing machine that uses more water than others is a worse washing machine.
To be clear, this isn't to say that you're wrong. Everyone can continue doing what they're doing -- really.
IDK Python was used by Disney with two of their mmos in the early to late 2000s and those were targeted towards super low end family computers and they didn't seem to have issues with performance.
>> It'd have to be a situation like sklearn and numpy where all the actual functionality is implemented in c/c++ and you're just using it as a glue language
It sounds like this engine is not implemented in 100% python.
See also Panda3D https://www.panda3d.org/, which was used in commercial games back in the day, and is exactly what you are describing!
Look at it from the point of view of someone that wants to make something without having to devote considerable time to learning a language as complicated as c++ or c# relative to python.
Hate to be that guy, but there are too many typos for me in the Readme. The rushed landing page makes me think the tool may not yet be ready for use, but again, maybe it's just me.
Overall I think I'm just nitpicky since I work on rendering code all day so this just feel wrong to advertise. Last time I tried opengl first-render hiccups were still a problem. I've mainly been in directx/vulkan land since then so maybe all the major gpu vendors have already fixed this problem. But whether or not that makes the statement better I don't know.
Edit: I will note that I still think it's cool. Making a game engine from scratch is not an easy feat, so it's impressive none-the-less.