If UT were to add a new programming language what one would be best?

F# ... it wouldn't even be that difficult.

(I considered listing elm, but I have a feeling it's a dead-end.)

 

Maybe if Unity realized how important Documentation was, and didn't slack on it like they have since the beginning, they'd be able to introduce new features, like a new langyage, without us having to worry.

But I'd have to agree. Unity isn't even capable of labeling their alphas correctly (they call them 'release') & their attention to their doc's are historically bad. It was only this year that they expanded the doc team beyond 1, I believe. And Idk if theres even been improvements afterwards. From the look of the forums, UNET is still awful.

I trust Johnathon Blow to make a new language by himself far more than I'd trust the entire Unity team.

I'm all for Unity postponing all new features until theyve polished all their current ones. You know... instead of fixing bugs 5 years too late...or never at all...

And yea, please dont do anything as complex as make a new language. That is far beyond what the company is capable of. Even if some employees could, the company would find a way to provide a lack of support, I guarantee it.

 

if you write F# and manually compile it with the same version of mono, unity can use the resulting assembly just fine.

 

Also have people not looked at UnityScript, or Boo, hell of even other engines dedicated languages of the past like UnrealScript.

This is a bit of a dead end.

 

Yeah I already use externally-compiled DLLs in my project pretty heavily, but "official support" would be nice.

And Haskell is just abusive, so I thought it deserved some response. From the thread subject I thought the OP really meant "add" a language, but from later replies it looks like he meant making up a new language, which is almost always a Really Bad Idea.

 

Agreed, they don't need a new language, they just need to extend C# with a visual scripting system. Blueprints is cool but sadly buggy and it hurts even further when you can't dive into the code behind the nodes to fix stuff. Nottorus seems to have taken a step in the right direction, just sad that the price became what it is. I think the best path is to develop a system that allows everyone to switch between traditional code and visual nodes as they like.

Oh yes, the asset store should contain extensions to features not extensions to the engine. The engine should pack everything a developer needs with the typical Unity flavor. Something is terribly wrong when everyone needs to purchase a plugin in order to get a missing feature in the engine. It also hurts freelancers and their like when you have to start every discussion with who is gonna pay for the plugins that the project is using?

Unity could also catch up by doing more open source projects (power of the masses) and reward contributors fairly.

There is also a need for a lot better documentation, more open features toward scripting and some bugs that needs to get fixed. The API documentation is especially a thorn in my eye...

 

Between this and another active thread now, it really gets me thinking...

Jonathon Blow wants a new programming language for games... Unity is neglecting their biggest strength & what keeps them afloat (community collaboration, a.k.a. the asset store)...

On the off chance my first project is majorly successful (hundred million $?), I'd love to return the favor to the community by investing in or creating a new game engine standard. An open source / full source engine with monetization like Unity (free, unless for bigger businesses) that works hand in hand to bring in the best community assets, polish them up through collaboration & quality control, and integrate them officially. Maybe an encouraging strategy like "If your plugin is amazing, we will buy you out!" to bring in competent/ talented developers.

Sounds expensive to maintain, but maybe it could work. Especially if the engine was heavily modular, very efficienct (performance), and maybe even had its own language just for video games.

Real interesting to think about, at least. That collaboration component is incredibly powerful. It just needs quality control & heavy maintenance. Along with the core. And enough money / big names pumped into it to give it a powerful jumpstart.

 

Nobody has mentioned Forth. (nobody ever mentions Forth). If we're going to add a language it should be that one. Interestingly one of my favorites games of all time, Starflight, was written in Forth - somehow I never knew that.

 

Do you know what would be far better than adding a single language? Easing the process of using alternative languages to compile your scripts. A quick search shows me that it's already possible just not the easiest process to go through.

 

The punch-card paradigm will live again! (No, I never throw anything away.)

 

I knew sooner or later this thread would turn into "when can we use C# 6 / .NET 4.x"... (and C# 7 is just around the corner, and it's actually pretty awesome...)

 

+1 for referencing Starflight in a technical thread.

 

this 100%, moving onto c#6 and 7 once its final will be amazing, not ot mention using a modern mono, or even moving to the .net core.

 

Finish that game already.

 

Apple's Swift programming language makes development Swifter.

• Swift has a simpler syntax, for instance it does not need the ';' to end a statement.
• It uses the '!.' operator e.g. "object!.subElement" in a similar way to Unity's object.getComponent<subElement>().

The question is simple could Unity create a dedicated language that makes it easier and faster to make games?

I think the Answer is Yes.

 

One keystroke. Besides it isn't like most of your time is spent typing. Most of your time is spent debugging. What debugging features does it bring with it?

 

This doesn't make it any better. That's like saying that removing full stops from books would make them easier to write or read. I still can't stand seeing bits of python code hanging around in the air like that.

Same with Java's var. When you look at the code, you still 'see' float or int or string or whatever, and writing it explicitly makes it clearer to see the history of what you're constructing. You know what you're writing, the compiler knows what you're writing, so who are we putting on this show for? It doesn't make any sense to me.

My opinion is, at the code level, everything that you do should be as explicit as possible. Code should not read like some sort of riddle where you have to reconstruct everything in your mind from a few vague and implicit symbols.

 

I think a more valuable direction to go would be to add a scripting language layer that functions more like an in-game asset. Leave C# as the main development language for heavy lifting while providing an in-game scripting asset for actual game logic - the same concept as Lua for example.

This language could be heavily customized to suit game development, would be runtime interpreted (since it's just running game logic this shouldn't be an issue). This would also provide a more flexible way of allowing modding in your game, which is a current Unity weakness.

Lastly, adding a visual layer on top of this a la Blueprints would be the icing on the cake.

 

Of course they can there are third party scripting languages for Unreal that are simpler if nothing else than C#, doesn't mean it's a good idea.

As @gian-reto-alig was saying, it takes years to properly document a mammoth API. The logic Sweeney used was that they didn't want to double up on work, hence making C++ more manageable.. Well, the logic was sound but the implementation not so much.

In today's environment, you'd be better off using a powerful high level language like C# and just building the rest of the engine in it. No conversions to worry about, holistic unification, more productive on the whole..

Paradox (or whatever they call it now) did it, they just lack the man power to move it quick enough. In games especially, between constantly improving hardware, the likes of next gen consoles (if rumours / info are to be believed) laptops becoming desktop replacements, C# becoming open / optimised and native compilation for math intensive systems (like physx, lightmapping). There's less and less reason to use C++ holistically, even the graphics API can be bound the only thing that needs something different is the shader architecture which we already have HLSL / GLSL for.

 

@gian-reto-alig I agree this shouldn't be something Unity does. I was thinking of it more as something each developer could and probably should be doing.

If a person is only interested in building certain kinds of games... say FPS... then it makes sense to build up a framework for creating such games. In this way just creating methods which basically can be seen as just extending C# with specialized FPS functionality. And eventually could even result in a language inside a language or if taken to the extreme... a scripted language perhaps as open source.

Unity game engine is quite capable but it is so generic I think it makes sense to consider such an approach. I think many of us programmers are already doing this to some degree writing wrapper methods for common set up stuff and often used functions.

Unity doesn't have the resources to tackle actually creating a new language. We've seen the struggle just in fixing the bugs in the game engine and documenting what it has in it. I hope they continue to focus on these things. Not on new things.

 

One solution to this problem would be exposing the C++ API in such way so that external developers could develop bindings for other languages. In such case you could always write code in the language and IDE you prefer.

 

Whichever way you look at it you're going to have to make calls to the unity API in some way.

So the language is going to be tightly bound to API function calls.

 

Not to mention keeping current with C# and .NET ... if they aren't doing that with a language somebody else is handing to them on a silver platter (more or less), it doesn't seem too likely a made-up language is likely to be satisfying. I'm sure you realize this but folks like Arowx don't seem to realize just how difficult it is to make up a language (well, one that is any good and has staying power).

Honestly I still think F# fits most of the things Arowx keeps mentioning -- assuming one can adjust to the functional approach to problem solving. (There are very good tutorials at https://fsharpforfunandprofit.com).

Edit -- here's a good example from that site -- a fully generic sum-of-squares function:

Code (csharp):

1. let sumOfSquares n = [1..n] |> List.map (fun x->x*x) |> List.sum

An integer-only C# equivalent (which could probably be reduced in various ways, but even so, there's still a lot more ceremony to get the same work done, and this simple example barely scratches the surface):

Code (csharp):

1. public static class SumOfSquaresExample
2. {
3.     public static int SumOfSquares(int n)
4.     {
5.         int x = 0;
6.         for(int i = 1; i <= n; i++)
7.         {
8.             x += i * i;
9.         }
10.        return x;
11.     }
12. }

 

Erm...

Code (csharp):

1.  
2. using System.Linq;
3. ....
4.  
5. var result = Enumerable.Range(1, 10).Sum(x => x*x);
6.  

You can also define your own extension methods like map, reduce, etc.

 

And this syntax is cleaner and much easier on the eyes. My eyes anyway.

 

It also works on lists/arrays and it is possible to do stuff like this:

Code (csharp):

1.  
2.         var tmp = new List<int> {0, 1, 2, 3, 4, 5, 6, 6, 6, 7};
3.         Debug.Log(tmp.Sum(x => x*x));
4.         Debug.Log(tmp.Distinct().Sum(x => x*x));
5.         Debug.Log(tmp.Where(x => (x % 2) == 0).Distinct().Sum(x => x*x));
6.  

All this is possible thanks to extension methods.
C# has plenty of its own quirks/weaknesses, but extension methods are one of its nice features.

Because of them even without linq it is possible to write your own extensions to aggressively reduce code verbosity/size and make everything short/compact.

 

Uh, drag & drop. Please.

 

Good point but what if a Line Of Sight check in Unity U# was...

Code (CSharp):

1. if player.LOS enemy
2. {
3.    show enemy
4. }
5. else
6. {
7.    hide enemy
8. }

as Opposed to (just quick example may not work)

Code (CSharp):

1. RaycastHit hit;
2. Vector3 rayDirection = player.position - enemy.position;
3.  
4. if (Physics.Raycast (player.position, rayDirection, hit))
5. {
6.      if (hit.transform == player)
7.      {
8.        enemy.gameObject.SetActive(true);
9.      }
10.      else
11.      {
12.        enemy.gameObject.SetActive(false);
13.      }
14. }

It would just need a LOS function built in and show and hide commands added, as well as the removal of if brackets and the archaic semi colon.

In theory these higher level Unity game development specific commands could also benefit from optimisation, as they could be running in the core engine as opposed to within Mono or IL2CPP.

The idea is to have simpler syntax and make common tasks commands.

 

Well played, sir. I figured somebody would out-LINQ it. But again, that was an extremely trivial example.

And, of course, your one-liner is not actually usable ... for that you need several more lines of wrapper baggage to declare it, which is built into the single line of F# that I posted.

 

Actually a type of language that would in theory be ideal for the future of games is Chapel a productive parallel programming language made for cray supercomputers. And before you complain check your desk and pockets you probably have a computer/mobile device way faster than the original cray supercomputer (160 MFLOPS).

So the previous example of summing squares could be run in parallel on the CPU or GPU!

 

@Arowx There is no doubt the Unity Basic you are showing would be more efficient to develop with.

I can't see it ever happening though. But this is the kind of thing I was talking about earlier where we can make wrapper methods to remove all of the "busy work" and make a streamlined method.

BASIC is probably the best language for raw productivity. I've been tempted a couple of times to switch to one of the relatively modern game dev oriented BASICs. The main reason I don't is because I keep thinking I will use the multiplatform support someday. I do for Desktop and web. The other reason is I have finally designed a way to use Unity that suits me better. And part of that is the process of writing these BASIC style methods like you have shown above.

 

I'm not sure what you mean here:

Code (csharp):

1.  
2. using UnityEngine;
3. using System.Collections;
4. using System.Collections.Generic;
5. using System.Linq;
6.  
7. public class ScriptTest : MonoBehaviour {
8.  
9.     // Use this for initialization
10.     void Start () {
11.         var result = Enumerable.Range(1, 2).Sum(x => x*x);
12.         Debug.LogFormat("Output: {0}", result);
13.  
14.         var tmp = new List<int> {0, 1, 2, 3, 4, 5, 6, 6, 6, 7};
15.         Debug.Log(tmp.Sum(x => x*x));
16.         Debug.Log(tmp.Distinct().Sum(x => x*x));
17.         Debug.Log(tmp.Where(x => (x % 2) == 0).Distinct().Sum(x => x*x));
18.     }
19.  
20.     void test(){
21.     }
22.  
23.     // Update is called once per frame
24.     void Update () {
25.  
26.     }
27. }
28.  

---------

//Rant about functional languages

Once upon the time I had brief interest in Haskell and functional languages in general. After some investigation I wasn't exactly convinced of their usefullnes. Actually, I once made a very costly mistake by selecting an erlang-based software. The software claimed to be very optimized for intended use due to amazing magic of functional languages (because "no state"), except in our particular case it ate ALL server memory it was allowed to use and kept crashing, and didn't scale for intended use. Whoops.

The biggest issue with functional languages is that all their introductions routinely fail to demonstrate any immediately/obviously useful real power of the language. Haskell tutorials tend to start with "See, our language has FILTERS! Think about possibilities! It is SO cool! Please say that our language is Cool!", which doesn't exactly work when you realize that a filter is probably a costly syntaxic sugar to the one-liner I posted before (I wouldn't be surprised if F# one-liner resolves into something very similar to C# one-liner). That gives negative impression from the start. Also, I'm not a fan of ML-like syntax, since I don't exactly understand why I need to type two symbols when I could use one.

In comparison to haskell introductions, something like gigamonkeys common lisp book (which I do not consider to be very good), very quickly gives you the meat of language, by throwing defmacro at you. If you dig deeper, then you get to CLOS, and once you're there you'll discover joys of having multiple dispatch via defmethod/clos type system. Usefulness of something like that is instantly obvious. Prolog introductions mess around for a while, but then finally throw at you something like graph coloring problem. Which quickly demonstrates what the language is good at.

People that recommend haskell and functional languages, however, often talk about something like enlightment. Which makes me even more skeptical. I mean, if you like the language, you should be able to explain in 10 minutes why it is good, right? If the argument amounts to enlightement, then there's a big problem here.

//End of the rant

Anyway, that wasn't directed at anyone in particular, just few thoughts I felt like sharing.

 

Python maybe

 

Full PICO 8 support.

 

Please no. The basic paradigm is actually incredibly hard to get anything complex done in. It's great for trivial stuff, but that's it.

I routinely have to drop into basic for work. I cringe every time I do.

 

Well, its not like you cannot do this today given you go through the C# API somehow. Which could be a no-go given you want to squeeze every last bit of performance out of the engine, but most of the time is not exactly a showstopper, no?

Given that is basically how many Asset Store assets like PlayMaker, or all the Visual scripting assets do their thing. So its not that anything is stopping you from it...


Are you basically just asking for lower level access to the engine? This I do support, I am not sure I want to see Unity waste to much time on it, but then there is the easy way epic took: Opensource most or all of the engine internals so devs can fork the engine to their hearts content.

I am not so sure how well this would integrate with Unitys business model, which I think is the sole reason why they haven't gone the way epic already did. But given you could opensource the important parts for low level access, while making sure nobody can use the engine without respecting Unitys license model, this seems a reasonable approach to give low level access to devs like you that want to customize Unity without ging through wrappers, while not asking Unity to waste their time with low level plumbing for features only a few really need.

 

Please do not clutter this engine with different half-baked and poorly documented scripting solutions.

Of all the languages I used so far (that includes Haskell!), C# was one of my favorite ones.
Like everything, it is not perfect, but it gets the job done nicely in Unity.
It's a reusable skill whose usefulness extends well past game development, it is well documented and supported.

I don't want to spend hours messing around with some obscure language someone thought was cool because they could save a few seconds while typing out code, but barely anyone uses.
I want to get work done and often this work involves solving problems to which I can more easily find solutions if I work with widely used technology. Not to mention what a pain searching through the docs could become if there were different scripting solutions. Compared to other engines, I believe the Unity docs to be way above average, but that could quickly deteriorate if there were different ways to do everything.

I do see some value in a visual scripting solution where programmers could make some higher level functionality available to leveldesigners from C#. But this should be as tightly integrated with C# as possible instead of being a separate solution.

Unity is about being simple to work with to me, not about some fancy and exotic tricks, whose novelty might become an annoyance when you actually have to work with it.

Disclaimer: I am not against new languages in general, but I currently see no reason to replace C#. Nor do I see a viable replacement.

 

Not quite sure that example works. Essentially what you're saying is why doesn't unity have a function or method player.LOS which is just what you've written in the second code snippet but wrapped in a function or method.

The problem with this is that it assumes many things. Unity is a tool for creating anything. The key word being anything, so that if you wanted to drill down to the mechanics (player line of site) and you wanted it to behave differently you could.

The language choice doesn't change anything.

Although scripting languages tend to be less verbose than dotnet languages or compiled languages. But at a cost it suffers in performance.

What we need is something expressively typed but compiled for speed (not java or dotnet mind you with their JIT IL nonsense) but compiled natively to that platform.

Enter-> golang

 

LOL look at the simpler syntax the commonly used game oriented features as built in commands. The reduction in complexity.

The problems you mention could be circumvented by LOS settings in the player, that's right data can be used just as it is now with the collision detection matrix but this time dedicated to a common task.

And if more complex behaviour is needed then a bespoke LOS check should be written using the Unity API.

 

Only that the one-liner you posted requires a lot of additional "stuff" around it before some other part of the program can actually call it as a function (versus the F# one-liner which is immediately usable as shown).

I initially blew off F# for a lot of the same reasons you listed based on encounters with other functional languages. I spent a lot of quality-time with lisp as a kid, it was fun, but I never really saw the point, it seemed like a weird toy. When F# came out I thought it was probably just meant to show off CLR flexibility (which is sort of true, except that they were already taking it very seriously).

But recently doing real-world work with a stream-heavy mindset using reactive programming styles led me back to F# and I'm finding it's a dramatically better experience than the older functional languages I've tried. If you didn't like ML (or more importantly SimpleML) though, you'll probably hate F#, it's based on a cleaned up evolution of OOCAML which you may know is ML-based. I don't know about "enlightenment" (a very loaded term) but it does require thinking about problems differently.

I see it as another tool. For instance, in my project I have a need to identify a series of locations based on a lot of complex criteria. In C# I've written a lot of complicated loops containing tests and setting flags everywhere -- the typical imperative style. In F# I can just define the combination of criteria I want and apply it as a filter -- declarative style. I also have a lot of complicated states that interact with one another in various ways, and F# has "sum" (or "union") types and related features which basically amount to built-in state-machine management. My problem is I don't want to commit to F# everywhere (especially without Unity support) so I've been trying to imagine a clean separation of some of that functionality so I can try moving the logic into an F# DLL.

Since they're both compiled to CLR, yeah they probably do compile down to something similar (especially given that LINQ is a direct result of functional thinking), but that's not really the point. As I wrote earlier, so far I'm seeing F# as a pretty good match for a lot of Arowx's wish-lists. I really meant it more as, "learn more about existing options" versus jumping straight to the drastic "invent yet another narrowly-specific language."

 

I meant the differences in the command set as far as productivity goes... the examples @Arowx showed where using a BASIC-like simplified syntax and structure cuts the number of lines needed nearly in half from the C# version. And a true BASIC version would not need the curlies reducing it down to only 5 lines. Straight to the point... each line / statement accomplishing a high level objective. That's the BASIC paradigm.

What I was saying is we can do this in C# by writing our own wrapper methods. Heck, someone could actually write a lot of wrapper methods and put it on the Asset Store even. Be nice to see more code API up there and not so much GUI stuff (IMO).

I have no problem with BASIC. C# reminds me a lot of the various BASICs I've used. But this more about streamlining dev. Typically BASIC languages provide the kind of high level wrappers @Arowx is describing as part of the native functionality. It's all about getting more done with less work spent on boilerplate and tiny details.

I actually maintain 2 legacy VB6 applications at work. Both are working with relational DBs, TCP/IP communication, XML, OO and a lot of other stuff. 700,000 lines of code in the biggest one. Both are currently being manually ported over to C#.Net and I'll be glad when they are. But... I find VB6 a very rapid development environment still to this day. It's just support is dead, a lot has happened since VB6 was prominent, and I suspect one day a new OS version will break it for good.

But the approach BASIC languages take is still very effective. It is just "get stuff done with minimal hassle". And that is powerful.

 

I would be curious to know how old some of you are and what your education background is.

As a Computer Science major we were pretty much taught that the language is not important. It's just a way of representing logic.

One course might be in C...the next in Java...and then we even had one asshole force us to use ADA if we wanted full credit on the projects. ADA actually turned out to be a pretty neat language with stuff like negative and offset array indexes.

Too much emphasis on language in this thread. Take ANY language and read 5 different peoples iteration of the same thing and you will see where the real complexity and difficulty comes from. 5 different minds approaching the same problem. Even the SAME mind over time will change the way they write the same thing creating situations where you cannot even easily understand your own code after some time.

Now realize that most (large) Assets on the Asset store are poorly engineered and bloated products built up over the span of many years. Now realize that everything you code that will integrate with these systems, must conform to their non-standard approach.

 

I was expecting this thread to devolve into a language flame war. Thanks for mentioning Starflight, such a fond experience in my memory and a reminder of why I love games and lurk in these forums

But personally...my vote is always for the language that is the most clear on its use and intent, while giving as much or more performance as expected, possible, whatever.

 

You may have a point, I mean that's the reason we have a first person template/controller to just drop in.

Trouble is these things bloats the initial language, and people start saying why isn't "this" or "that" function already in the language.

Who decides the LOS functionality? What about adding a parameter in there to ignore Players with certain tags. What about 3D? What about 2D? Does it function the same?

These are the questions that need asking. It's a similar argument with, when do I use a language or when should I use a framework?

To me, some of what you're saying falls into the "framework" bracket.

 

Unity, or any intelligent business is going to choose a language based on the Market. If C# is the preferred language, they will focus on that. It makes little sense to develop around obscure languages that only a tiny fraction of people even know about.

Thus you have C# in Unity...
C++ and Visual Scripting in UE4
and I think CryEngine has C#, C++, and their own visual scripting system but I'm not too sure about CE

 

I have to disagree with the language is not important.
Other than stability and performance, a language that is clear on its use and intent is critical for human beings to use effectively, especially over the long term and with systems that grow. I mean, we could all be using assembly, but there is a reason we aren't.

By the way, as far as my background:
Tought myself assembly on our Tandy COCO, ordered the assembly manuals for the disk and basic rom from tandy. Did more on Apple IIe, PC. Did Fortan, pascal, assembly, other stuff in school. Currently a .net/C# programmer. 45 year old sigh. I by no means have a massive range of experience, but I'm not a spring chicken

 

Yep of course language is important when examining the discipline involved.

Otherwise we'd all be using scripted languages for everything. There's a reason why c++ trumps python in a game engine where performance is paramount.

 

I took his comment to be more about "syntax" rather than "language" in the sense you're talking about.