[HN Gopher] 3D desktop Game Engine scriptable in Python
       ___________________________________________________________________
        
       3D desktop Game Engine scriptable in Python
        
       Author : nurettin
       Score  : 61 points
       Date   : 2023-11-01 11:58 UTC (11 hours ago)
        
 (HTM) web link (unidaystudio.itch.io)
 (TXT) w3m dump (unidaystudio.itch.io)
        
       | Cieric wrote:
       | 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.
        
       | spandextwins wrote:
       | No sauce?
        
         | sidewndr46 wrote:
         | this appears to be a closed source project. I can't find
         | license info anywhere
        
       | barbariangrunge wrote:
       | 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's not that it's impossible, I'm just skeptical
        
         | lewispollard wrote:
         | > 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)
        
           | ensignavenger wrote:
           | See also, Panda3D https://www.panda3d.org/
        
           | barbariangrunge wrote:
           | 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
        
             | raincole wrote:
             | > If they're learning python, they may as well learn c# or
             | c++
             | 
             | No?
             | 
             | See: data scientists. And really any scientist whose daily
             | job involves statistics.
        
             | crustaceansoup wrote:
             | 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.
        
             | raytopia wrote:
             | 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.
        
           | reactordev wrote:
           | "even those that use C# do it this way"
           | 
           | 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#.
        
           | westurner wrote:
           | https://www.reddit.com/r/O3DE/comments/rdvxhx/why_python/ :
           | 
           | > _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.
           | 
           | "Using CFFI for embedding"
           | https://cffi.readthedocs.io/en/latest/embedding.html :
           | 
           | > _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:
           | 
           | https://github.com/apache/arrow/tree/main/c_glib/example/lua
           | :
           | 
           | > Arrow Lua example: _All example codes use LGI to use Arrow
           | GLib based bindings_
           | 
           | pyarrow.from_numpy_dtype: https://arrow.apache.org/docs/pytho
           | n/generated/pyarrow.from_...
           | 
           | https://github.com/scikit-learn-contrib/sklearn-pandas :
           | 
           | > 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._
           | 
           | Pandas docs > PyArrow > I/O https://pandas.pydata.org/docs/us
           | er_guide/pyarrow.html#i-o-r... :
           | 
           | > _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()_                 df =
           | pandas.read_csv(".csv", dtype_backend="pyarrow")
           | sx = pandas.Series([1.0,2.0], dtype="float32[pyarrow]")
        
           | andybak wrote:
           | 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.
        
         | cuddlyogre wrote:
         | 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.
         | 
         | Everyone starts somewhere.
        
           | __loam wrote:
           | Godot has gdscript which is actually written with the use
           | case of game scripting in mind. It's a much better option for
           | this application.
        
             | city41 wrote:
             | And gdscript is very python-like
        
         | ensignavenger wrote:
         | >> 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!
        
           | raytopia wrote:
           | Panda3D while not perfect is awesome! Wish more people knew
           | about it.
        
             | ensignavenger wrote:
             | I always really liked the Panda3D Python API.
        
         | dbrueck wrote:
         | > 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.
        
         | raytopia wrote:
         | 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.
         | 
         | Python's slowness seems to be overstated.
        
         | m463 wrote:
         | It says "backend in c++". the game logic is usually not a
         | performance bottleneck.
        
         | cmdrk wrote:
         | 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.
        
           | qwery wrote:
           | 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.
        
       | miohtama wrote:
       | 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.
       | 
       | Looks like Alice is still around
       | 
       | http://www.alice.org/
       | 
       | Last update from September.
        
         | miohtama wrote:
         | Also looks like they have ditched Python for Java
         | 
         | https://wiki.python.org/moin/BeginnerErrorsWithPythonProgram...
         | 
         | Everyone has riding Java hypetrain in 00s. Long term and as a
         | hindsight, might not have been the best choice.
        
         | sidewndr46 wrote:
         | interesting, that predates the commercial Dune game that was
         | Python & Renderware. I did a bit of investigation into this a
         | few years back
         | 
         | http://www.hydrogen18.com/blog/reverse-engineering-frank-her...
        
           | miohtama wrote:
           | Some other notable games based on Python
           | 
           | - Civilization (one of them)
           | 
           | - Eve Online (Stackless Python)
        
             | sidewndr46 wrote:
             | any idea what Civ game is based on Python?
        
               | nurettin wrote:
               | Civ4 was scripted using python
               | 
               | https://en.wikibooks.org/wiki/Civ/Civilization_IV/Modding
               | /Tu...
               | 
               | I faintly remember seeing boost.python dlls in the
               | install directory 15 something years ago.
        
               | Elucalidavah wrote:
               | > Civ4 was scripted using python
               | 
               | Same for sims4
        
       | apetresc wrote:
       | It seems like they're just unnecessarily poking the bear by
       | calling themselves "Uniday Studio".
        
       | actinium226 wrote:
       | It's come up in a few other comments but this seems similar to
       | Panda 3D
        
       | karteum wrote:
       | "for windows" only ? then it's a no-go for me...
        
       | raytopia wrote:
       | For open source 3d engines that use Python check out Panda3D or
       | Ursina. They're both a blast to use and let you write your code
       | how you want.
       | 
       | [0] https://www.panda3d.org/
       | 
       | [1] https://www.ursinaengine.org/
        
       | batch12 wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2023-11-01 23:01 UTC)