How much easier would games be to develop in Unity if it used Python instead of C#?

Just curious

Kinda strange there is no Python support in any of these game engines.

 

Ren'Py exists.

Also Python's interpreted, so it's of course slower than C# or C++. Game engines are at least as concerned with speed and power as they are with accessibility (arguably more so).

 

Python is included with Unity, it's in various build pipelines e.g. WebGL.

In theory it looks possible as there are Python compilers that convert Python code to C++ so Unity could put together a Python build pipeline similar to the IL2CPP one in theory. But it would be quite a bit of work to do for Unity and the question is what would they gain?

I'm not sure why one language would be easier to program games in than another as most languages have similar features and only differ in syntax and semantics with a few features that stand out.

What do you think Python brings to the table that would make it easier to write a game?

 

If we're talking languages, then honestly when it comes to the code you write for unity you are basically left with the option of either ditching most of the features you get from using the inspector (In which case you might as well just use a framework over an engine) or writing code that is so tightly coupled to the game engine that your options for loose coupling become very limited. I honestly think unity would be better off with something like GDScript. But the scripting interface is written for C#, so that's what we get. I have no idea what the reasons for this are. I don't really grok performance being one though. Python is no more or less interpreted/compiled than C#, that assertion is total nonsense. Both are compiled to bytecode which can then be interpreted or JIT'd depending on your runtime. Unity itself is written in C++ and is taking care of most of the heavy lifting for you. I've never encountered a situation where the actual game logic itself has been enough to melt my PC unless that's what I was intentionally going for, no matter how high the level of abstraction. I think it's more likely because a lot of developers already know C# and the skills are (somewhat) transferable.

 

Unity used to support writing code in Boo, which had a very Python-like syntax. When Unity started dropping it in 2014, 0.44% of scripts created in Unity were created in Boo. Make of it what you will.

 

My guess is that it wouldn't be any easier at all except for people who only know python and are unable to use other languages.

And yeah, as @Baste mentioned, Boo was a thing and almost nobody used it seriously at any point in Unity's history. It couldn't compete with either UnityScript or C#.

If I recall correctly in the early days most code was in UnityScript, but once Unity started to target mobile phones they started requiring developers only to use C# for those mobile targets, and this is why C# overtook UnityScript so strongly and so quickly.

 

There wouldn't be a meaningful difference in difficulty because the language itself was never the hard part. Learning your first programming language is difficult because the concepts and the way a computer functions is foreign to us. Our minds don't solve problems the way a computer has to solve them.

Once you've learned the concepts and the way a computer functions everything becomes much easier and this is reflected in the fact that your second language is picked up in a fraction of the time it takes to learn your first and your third will be yet again much faster. C# was my third language and it only took me a week to learn the basics.

 

Unity used to try to be multilingual and it was a nightmare.

 

People still manage to use Python:

https://mikalikes.men/use-python-with-unity-3d-the-definitive-guide/

 

This ^^^

It was maddening for several reasons. Firstly getting help on the forum or following tutorials was irritating because whatever you are looking for always ends up being in the "wrong" language. Also you couldn't communicate in both directions between scripts of different languages in the same project. This was a problem whenever you got 3rd party assets.

It was a dark time. Never forget.

 

Does python support object orientated like cprogramming?

 

Python is NOT better then c# in any way and it's syntax is disgusting.

 

Furthermore UnityScript and Boo weren't truly JavaScript and Python. Unity's implementations had very subtle differences which meant code written in JavaScript and Python had to be translated to function properly. Meanwhile Unity's C# was the same C# as everywhere else. It was out of date but otherwise it was identical to actual C#.

 

Also, do not forgot the engine's api is tightly coupled to language of choice so this negates the ease of understanding (languages like python ectera)

 

Yup!

I started in js and ended up with a bloody scalp trying to figure it out. Learned C# almost immediately after starting to try it.

Seriously, just learn c#.

It’s SO much better in every regard.

I know it’s super chic to hate on Microsoft, but development tools and languages they are top of their field.

 

It's tightly coupled to the .NET framework not C#. UnityScript and Boo weren't truly JavaScript and Python because they had to support the framework which clashes with the way those languages function. Adding another language to Unity is not impossible and can be done by anyone. You just need to generate the bytecode that the .NET framework executes.

Just as an example here is a tutorial for getting F# working with Unity.

https://jacksondunstan.com/articles/5058

 

With how every new forum user never uses CODE tags in their threads here, can you imagine how dysfunctional this forum would be if Unity supported Python? It would just be thread after thread of python code with no leading white space.

 

I enjoy C#, but it's not necessarily only about how easy the language is, but also about what else the language supports out of the box (so packages). I was working on a project last year that involved ML from time signals...in C#. Goes without saying, but I had to do everything myself, from writing an elliptical filter to resampling to extracting EEG band powers. Never got around to actually building models, but they also would have been severely handicapped by the language choice. Would have been way, way less time consuming in Python (though in all fairness, I learned a lot).

 

It's not very hard to call out to python to run a script from C#. I do it a bunch to interface with Blender, and with git (since I had an easier time finding git libraries that were easy to work with for Python than C#)

It's way harder to do it in a way that works regardless of the user's Python installation, but that's a python problem in general.

 

Python isn't really a superior language. Its generally designed to be an "easy" language. Which means it makes a bunch of sacrifices of advanced features. By the time you add these features back in, you end up with a language that is no longer "easy".

This was one of the problems with UnityScript. It was sold as easier because it had dynamic typing. Except under the hood it did static typing in a way that looked like dynamic typing. And this caused a whole bunch of weird errors. So the standard advice around the forums was to use #pragma strict. Which turned off the fake dynamic typing and forced strict typing anyway.

Once you force python to work with the Unity engine, it will just be C# with a weird syntax. Anything "easy" about python will be ground away by the need to work with the existing framework.

 

Wouldn't be any easier.
You'd have to interface with Unity's API regardless when you write scripts; it would just in a different syntax instead. The overall workflow would still be the same.

One thing that Unity could make easier though (and I hope they do at some point) is writing custom inspectors.
Man, I really hate writing custom inspectors, but they're too helpful to just not write either.

 

Never forgetti, support was spaghetti.

 

That's part of what UIElements is for.

 

Did that release? I completely missed it if so.

 

It's still in preview.

 

I hope it'll address the data-binding issues that I frequently run into with custom inspectors.

For instance, if I have an abstract class that takes in a generic type:

public abstract class MyClass<T> : MonoBehaviour

,
and I wanted to draw a custom inspector for it, the type specified in the custom inspector attribute:

[CustomEditor(typeof(MyClass<T>))]

,
has to match exactly the type that a sub-class inheriting this script is using, otherwise the inspector will not draw, even if I abstract the type all the way up to

object

.

I haven't found any good workarounds for this.

 

I am wheezing from laughter. My god. Please don't lose that wit.

 

Great explanations thanks