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

What programming language do you think would be best for the future of game development and why?

Or if they were to build their own programming language what features would it need?

Update:

After discussing the issue with users on the forum I think that a bespoke Unity language could be the ideal way to go:

Like Chapel it could be built from the ground up to be parallel.
It could also be designed to run on CPU's and GPU's.
It could have a simpler and easier to understand syntax e.g. Swift
It could have more powerful frequently used commands built in e.g. Line Of Sight -> LOS
It could have more game oriented programming features built in e.g. Aspect and Agent Programming, FSM, Deep Learning System (ideally).
It could and arguably should be built hand in hand with a Visual programming system.

Many but not all of the above improvements could be added to Unity's existing API.

But just give it some thought or let yourself daydream for a moment, as you are typing in reams of boilerplate code to make your next great game.

If Unity had a bespoke language with a simpler syntax, how much code should this really take?
​

Update2:

You probably want Unity to provide a Visual node based programming solution, but really you are asking Unity to make a simpler programming language that is visual, think about it.

 

I honestly don't think we are going to build a new programming language.

What would be the benefit?

 

C++

 

• Reduced syntactic complexity.
• Tighter integration between API and code.
• Common tasks can be tokenized e.g. go.getComponent<componentName> could become go.<componentName>
• Higher level features could be built into language e.g. Multithreading / Design Patterns.
• Compilation to GPU code.
• Tailored memory usage and performance for games development.
• Designed to work with Visual Tools.

Are just some of the potential improvements that could be leveraged from your own programming language or using a different programming language.

 

LOL That's a really old and not a very nice syntactical language!

Surely there are better modern languages than C++ with cleaner syntax more features appropriate to game development.

 

My thinking is C++ is what Unity itself is written in which should eliminate the "gateway" overhead of callbacks from C++ to C# also C++ is a fine language in itself.

Maybe they can convert their C++ to Assembly and create an Assembly API and add support for writing games in Assembly. Macro assembler of course. That could be interesting.

I guess you are thinking of going the other way creating a language that does far more with less.

I think a new language is not really needed for that rather some wrappers around their existing API. Which basically is what we find on the asset store from other devs.

 

Out of curiosity, have you created your own language before? I never have, but was wondering what you are basing these estimations and statements on.

 

I would shoot for some form of BASIC (visual basic?) ... a language which is really simple and easy especially for newcomers, without all the curly-braces malarky of unity script and c# ... something like BlitzMax maybe. It could still have classes and stuff but just be generally simpler overall and easy to type and not so heavy on the picky syntax.

 

I have used a number of different programming languages over the years, ZX Basic, BBC Basic, Amiga Basic, MS Basic, Blitz Basic, Blitz3d, Turbo Pascal, Delphi, C/C++, C#, Java.

And found that sometimes the languages that were most fun/powerful to use had more direct platform/task/genre specific functions/commands, from easy access to graphics/sound hardware features or game specific features e.g sprites.

Imagine the amount of code you would not need to type if UT changed the 'getComponent<>' command to syntactical feature '.<>'

I'm not claiming to be a language developer but having used some very good languages over the years I can imagine a Unity specific game development language could be developed with some fundamental improvements for programmers as listed above.

I suggest that UT asks a language designer like Anders Hejlsberg who developed C# for Microsoft.

Who knows UT could develop G# (if G is not already taken).

 

Would have to be either C++ or Python if it was anything-

I agree with Gar about benefits to C++, and add that it would make it easier for devs coming from Unreal.

Stretching a bit, I've found that C++ and python experience are more versatile and marketable skills when it comes to software development in general. Granted, Unity doesn't care about that, but it's certainly a benefit- I know I'd have more resources to put into game design if I was making Software Development dollars.

I'm sure they would rather expand the Animator state machine into a Visual scripting tool before adding new languages. What with Unity Personal being free, catering to non-programmers is probably higher up on their list.

 

Well in theory UT could add any CLI language to Unity -> https://en.wikipedia.org/wiki/List_of_CLI_languages

 

Someone doesn't know some useful things about C#/.NET it seems.

C# has a System.Threading library that has methods designed to do this, including mutexes. I do not know whether or not the flavor of MonoDevelop that Unity has these, or how well they play with the rest of the Unity engine. Source: Archived Documentation

C# has some design patterns baked into the language, or their need mitigated by language features:

• The Command pattern is largely unnecessary in C# due to the implementation of function delegates/first-class functions/closures, and the .NET 3 delegate types, Action<T0...T15> and Func<T0...T15>. While certain cases can actually crop up in the development of an application where a Command pattern could be used, that type of need usually exists at a higher level of abstraction than hosting it in the language itself. Source: Game Programming Patterns by Robert Nystrom
• The Observer pattern is baked into C# with the event keyword, again using function delegates. Remember, a lot of "Gang of Four" patterns were designed to get around the inherent limitations in C++. Source: Game Programming Patterns by Robert Nystrom
• ...and probably more. I don't know everything about C#!

TL;DR: C# has limitations, but it has some of the very things you're asking for. To be fair, C# has its own limitations that other new languages like Rust solve - namely, getting rid of null ("The Million Dollar Mistake"), and language-native support for parallelization and other cool stuff. Seriously, research that language; it's not going to be a panacea, but no language can be perfect. It's just a matter of finding a language that is least offensive.

 

um... like with anything dealing with programming or computers, the benefits would be exactly what you need or want. The possibilities are endless (not so simple as can be stated or even known when thinking).

It's a lot of work, but no one would argue a custom language wouldn't be superior in every way if one were created by someone capable. The only argument is 'is it worth the effort?', in which you then begin arguing meta ideas (ways of thinking which suppress innovation, progress, and change through complacency. What a monstrous world we'd live in if in the year 2116 we still used C++).

To pretend like the current languages are perfect, or even fine as is, would be lunacy. There is always room for improvement, especially in that which is rarely altered.

And a custom solution is always better (assuming competence).

For anyone interested, https://www.reddit.com/r/programming/comments/2kxi89/jonathan_blow_a_programming_language_for_games/

 

Why? What could you gain from going with a different language besides some fanboys of a specific language probably feeling more comfortable in it?

I get the "C++ is best language for games!!!" Stuff if we talk about to-the-metal programming. But really, that is not the main goal of Unity, and neither do I think it should be. C# is quite a fine managed language.
I am not sure the speed up by going with C++ and ditching the memory management and other comfort features is worth the added hassles of header files, pointer magic and ... memory management. But I guess C++ fans will beg to differ.

And yes, I know many C++ engines abstract the most uncomfortable "features" of C++ away by using macros and whatnot. But at this point I really have to ask what people could gain by going with C++ over C#, especially as long as the engine is closed source and with a rather rigid development model (so if Unity manages the memory for you, you most probably cannot hack the engine to write that part yourself).


Sometimes I gotta wonder why some people are so focused on choosing the "right language" when they are all more or less "C with syntactic sugar".

 

No, it's not. That statement is a fallacy in that custom solutions require time and resources to develop, so you may well be better off purchasing or using an existing solution to do something.

Additionally, bringing competence into this means less than you'd think it would; a 'good' programmer with limited understanding of the problem domain (let alone competing concerns for other aspects of a work) can easily do worse than a team of 'mediocre' programmers who are creating a product specified to solve that particular problem domain.

Source: on-the-job experience in software development. It's my day job.

I will agree that there's always room for improvement. That being said, there's an axiom that engineering as a discipline has to hold close to heart: Perfect is the enemy of good enough.

 

I came from XNA and only switched to Unity because it supports C#. If C++ was the only option I wouldn't even be doing game programming - I despise it that much.

 

I wish most popular languages all supported nested block comments.. the lack of support for being able to do that pisses me off so much. As it goes it only seems to be a very tiny few scripting languages that have their own improved parser that support it. While the rest of the industry are stuck in the fcking 80's using S***y syntax and all kinds of crap language design dragged through the decades, thankfully java and then c# get most of it right. Computers have improved enough in speed and io to actually support this now with relative ease.

Commenting code in blocks like that is so much easier for workflow and trying new code..... Just you can only do it once.. if you want to block comment a chunk of code that encompasses an existing codeblock it just screws up.. Using multiple lines of this rubbish "//" gets messy and then you wonder, oh was this code commented out meant to be uncommented with the line(s) above/below or not.. why jeez if I had just been able to block un/comment it, it would be much more obvious.

Code (CSharp):

1.  
2. /*
3. code
4.       /*
5.       code
6.      */
7.       /*
8.       code
9.      */
10. code
11. */
12.  
13. F*** this S***...
14. /*
15. code
16. //code
17. ////code
18. ////code
19. ////code
20. ////code
21. code
22. */

 

@gian-reto-alig very good points. And although C/C++ were my favorite languages for many years and I resisted C# initially as a "toy" language over time my view changed. It is actually a fine language. Not perfect of course but no language is besides Assembly. And that only from the perspective of highly simplified CPU-oriented instructions.

I can kind of see where @Arowx is coming from. Because having used many other languages including those centered around game creation (AMOS, Blitz, DarkBasic, GLBasic and Monkey X immediately come to mind) game dev in Unity is much more involved than it should be in many cases. 2D game dev definitely stands out.

But only from the perspective of a programmer who has experience working in other languages. For most people I think the visual development style working in the Editor adding components, etc is more accessible. I mention the Editor because although that is obviously not a language with Unity it all goes hand-in-hand.

 

Good point just reading this article on how new programming languages can overcome new programming problems more cleanly and elegantly than old languages -> http://www.infoworld.com/article/26...ramming-languages-that-could-shake-up-it.html

What features could a Unity game specific language provide to make game programming easier and more powerful?

 

Just to make it clear, I also grew to like C++ a little bit more after I hated it during my time at university. Being forced to use it with some game engines helped there.

Well, if we talk about specialized languages for game development, I have to say I am not sure those are worth the potential gains.
Sure, they might bring nice features that might make some game development tasks easier. But then, that is usually what libraries are for.
Sure, they might be more intuitive to use for people used to that language. But then you will have to learn a new language with EVERY engine you start using, instead of just needing to have a grasp of some few big languages also used outside of the game dev world.
New programmers coming in from the outside would have to learn new languages, instead of bringing their knowledge with them (given C++ is not so widely used anymore outside of the game dev world, that is true to some extent already). Programmers trying to leave the game dev world would have to learn new languages, and fight more to get jobs without having C# or C++ on their CVs.

On the other hand, I am not 100% sure I understand what we are dealing with here. What kind of features do the mentioned languages bring to the table not possible today with C#, that coulded be added to the language with libraries?

 

Personnaly, i don't want to learn a custom language.
I prefer to use widespread languages so that my source code and my learnt skills can be reused.

 

You're arguing efficiency, which I already covered as the only valid argument. So you're saying I'm wrong, then using the very argument that makes me right? Well done. And your post purposefully removes my caveat about competence just to disagree? Who are you even arguing with then? Why argue just for the sake of arguing? Straw man Carter ftl? Weird.

There is nothing new in your post that I didn't already cover, so you're not even disagreeing with me...

You're just spouting the obvious. Such needless noise. Please spare us such arrogance.

Your arrogance was obvious earlier, but I didn't want to point out how pretentious you seem to be.

I mean, really? Are you this insecure about your own ability to program that in one post you belittle another and then in the next you make sure everyone knows you 'do this professionally'? No one cares you have a day job that taught you something that has no real relevance to a hypothetical conversation.

I do hope someone is 'wrong' enough some day to cure us of archaic languages like C++.

Hell, I could argue like many do that even in the context of time, money, and efficiency, the lack of better language costs us billions every year in inefficient use of time & money.

I bet you think J.Blow is an idiot too. At least scoff at his thoughts, perhaps? pft.

I won't argue. Just pointing stuff out. Mostly because the biggest thing I can't stand is pretentious arrogance when it's combined with being wrong. If you're going to be an ass, at least do us a favor and be right... /ignored

 

To answer, let's talk about why you'd need a new language at all. I propose we do this by doing what we're already doing: griping about an existing one. Enter PHP: A Fractal of Bad Design (It goes on for a while, I'll just put the relevant bits here.)

In the post, Eevee asserts a few things about a language:

1. A language must be predictable, so that people understand what we're telling the computer to do.
2. A language must be consistent, to aid predictability and to help the person learn the language, or extrapoate what a language can do more easily.
3. A language must be concise, to remove annoying boilerplate that gets in the way of actually solving a problem.
4. A language must be reliable; if a language is full of glitches, it prevents us from actually solving a problem.
5. A language must be debuggable, so when the person inevitably screws up, we can figure out what went wrong and fix it, so we can get back to actually solving a problem.

So do we need a new language? Maybe, maybe not.

1. C# is generally predictable. Most of the library can be used with a degree of foreknowledge. Certain funny patterns like the bool TryDoSomething(ref refArg, otherargs) do a good job of telegraphing how something is used.
2. C# is mostly consistent. It's multi-paradigm, taking cues from C++, Java, various functional languages and more. While C# code usually looks the same across all of these competing ideas, there's a few cases of being able to write code that makes people ask, "What language is that?" (mostly Lambda Expressions. Use those when you want to freak out a newbie! Additionally, LINQ query syntax looks like off-brand SQL.)
3. C# isn't the most concise; you do a lot of typing to express a programming idea in C#, and I've found in my work that there's usually some boilerplate required to make most code work. It's not as bad as C++, but it's there and noticeable.
4. C# itself is generally reliable. In Unity, we have less reliability, due to the Mono implementation being a knock-off of the Microsoft implementation, and thus having some bugs (foreach and the boxing problem reported by some developers is the biggest, clearest problem, which also introduces yet more boilerplate.)
   
5. C# itself is mostly debuggable. While there are always unhelpful exception messages in any library, the exception system is customizable with the ability to set inner exceptions, custom messages, and more. It's not the best, but it could be worse.

On that list alone, #4 is due to a bug in the virtual machine used to run C# in Unity. Remember, at all times, that Unity is not representative of all C#. It has boilerplate problems, and it has some unhelpful exceptions here and there. Other than that, it's generally consistent and predictable.

If the problem points (again, excluding #4, a known bug in Mono) are bad enough, then you would need a language to overcome them. The problem is, this is all subjective - Programmer A might find C#'s boilerplate manageable because "It's not C++", while another might be used to Brainfuck or something (note: please do not use that language within proximity of me. Cursing, or Brainfuck as a programming language? Yes.) A new solution would be needed if a majority of programmers decide that these problems are in fact problems.

I do not see that consensus. That's not to say that C#'s issues are not problems, but that they're probably not bad to justify Unity Tech sinking costs into fixing these problems when there are others (like the Mono thing) that could be more meaningfully fixed instead.

 

I like this way of thinking. Unity should use its strengths, and one of those is how it caters to less experienced users or non-programmers.

Much better, IMO for Unity to go higher than lower, in this context.

 

In the context of making game creation easier I think the best thing would be to create highly specific languages. Although as @Shorinji mentioned this also adds a learning curve and becomes useful only in this domain. Although I think the way most people are developing in Unity with tiny C# sharp files the latter is mostly true currently too.

Anyway... if we look at things like making a graphic adventure game for example back in time we'll find Sierra's Adventure Game Interpreter language.
http://www.agidev.com/articles/agispec/agispecs.html#toc3

Something along those lines could be done for every genre. A 2D shmup language, a 3D FPS language etc.

Of course, we're basically just talking about making our own scripting languages at this point which was pretty popular at one time and I don't hear much about it these days.

Due to the large number of languages needed it would be more reasonable for us (game devs) to create these and only if we intend on making many different games in the same genre that can all use the custom language.

If you know you will only ever make FPS or RPG games it probably makes sense to create a very high level highly specialized language and use it.

 

That would probably be a good way to cut out a good deal of the boilerplate from existing game programming, especially given that it's the rare game that makes its own new genre.

 

I actually think that there should be two levels of 'programming', C++ and some kind of unreal style blueprint system - basically what they've got. To be clear though I haven't really used the BP system at all, but it seems nifty.

The issue I have is that once you know how to program, it's not a bother to do it in C++ rather than C#. And if you can't program in C++, C# may be slightly more accessible but it will be a slog. Because the two of them expect rather the same sort of skill from the developer in the end, just that C++ is a little more intimidating to look at.

I think people expect that an easier language is going to make programming in itself easier. In fact I think it's the opposite. I'm programming in python atm and I find the fact that it is so implicit to be a bother, I have to keep reminding myself of what the computer 'knows' about what I'm writing. Fact is, I know all the gritty details about what I'm writing, so for whom is this implicitness useful? Some third party I'm not aware of?

There's a case to be made for something like blueprints though, but it would not be anywhere near the level of control of any useful programming language. It would simply be a chunk of code in an easy-to-deal-with format that people could trade around and non-programmers might find useful.

 

Unreal got Unreal Script. They ditched it and went for Blueprints. Go figure. Personally I would prefer a very clean C++ API.

 

Yes that is exactly it. Remove needing to deal with all of the common code bulk and also wrap up everything as much as possible into high level methods.

Basically the kind of things most of us programmers are already doing I'd guess.

Like if someone is making an FPS or 3D RPG I'd expect they'd at least have a method that performs line of sight checks, basic inventory management, NPCs, interactions with objects and NPCs, navigation etc. But it would look nothing like what Unity api provides and be much simpler.

Probably much like using the various assets on the asset store only designed from the gound up to all use the same conventions, same basic signatures and perhaps even to work together.

Ultimately what we need is something like drop an enemy into an area and define a roaming radius and it just does it. At startup it stores current location and uses that to keep within its patrol radius.

Every object allows a way to easily associate interactions to it such as take, move, walk on, etc. Then it "just works". If you try to move something and it doesn't support that action nothing happens. If you try take something and it supports it the thing goes into your inventory.

This kind of thing would highly streamline game dev. However, despite these kinds of things probably already being available on asset store the odds of them being implemented in a way that is natural for any given programmer to use is very slim.

I find hardly anything useful on the store. Of course, that might be due to me disliking all of the GUI stuff and preferring code api.

 

In day to day development I use a platitude of languages based on what needs to be done, it's far more efficient to use Skookum for level scripting and simpler than C#. I use BP's for character controllers and some world event triggers. C++ / HLSL for the rest..

Noticing a pattern in the trend above it's becoming noticeable how things are shifting slightly. Like IL2CPP and BP's doing native conversions so they incur no runtime speed penalties..

If I was to make a recommendation, it wouldn't be create a new language potentially invalidating decades of documentation and references to specific applications. It would be to continue the fundamental shift, as Epic and CE (branches) have shown you can take something like C++ and add it's own abstraction layers without "re-inventing the wheel".

A component based C++ with dynamic memory allocation and GC in games would be ideal. I'm sure there are many other things you can do to ease the complexity burden. Epic already have GC and Mem Aloc with C++, also let's face it most 3D games are pretty similar, it's either a matter of camera perspective or character types (something relatively trivial). For most types of games, effective base frameworks upon a very high level scripting language (either core or re-route to C++) / VS system can take care of that.

I do often wonder if the above would of been a better approach than IL2CPP, potentially less work holistically. Especially now as Mono is in easy reach for existing C# users..

Everything of course can always be improved.

 

Well we have UnityScript for that and look how it turned out....

 

Sounds like what I was talking about a few months back on dat thread. Though I think at this sort of level (waay above coding) a visual editor would be more useful. Unity's component system already does a decent job of separating functionality and exposing it in a 'high-level' way, but I think it could be improved, especially with a better system of showing how components interact with eachother.

 

Don't forget inability to do Inlining . There is absolutely no inlining with the C# we use with Unity, not even the compiler does it... source (43:00):

This can be kind of a problem when doing complex algorithms and you still want the code to be readable and well designed.

 

AS3

 

What if a Unity language added Agent based programming, which is much more applicable to AI programming as it was invented to make AI programming easier.

Or Aspect Oriented Programming which allows behaviours or Aspects to be used by objects, which sounds very similar to Unity's Component based system.

So U# could add Aspect Oriented Programming for easily adding behaviours and Agent Oriented Programming to make AI programming easier.

 

Well, AI is one of the main area's where VS flow scripting makes a lot of sense. Because mainly you'll be using a behaviour tree or finite state tree.. Again Unreal has a BTFST, which in Unity something like Mecanim would be ideal for a conversion, using blend states to transition through various phases..

I link it to the TOD timer so NPC's do different things at different point of the day, the BTFST just does a look up for the AI profile and NPC / Timer state..

It's a simple way of doing things, but it works well.

 

We need Quantum Assembler™ now

 

We need semantic parser: "Build a game just like <X> but with features <Y> and <Z>". In pro version you could write "Build a game BETTER than <X>...

 

I actually think speech recognition has a lot of future in game development.

 

Only valid if you have a big, round, red, "Make Game for me Nao" button.

 

They should add a properly integrated Visual scripting system (like Blueprints) that works uniformly across the entire platform.

C++ isn't super necessary, but it's not that difficult within the confines of an Engine API. Where C++ is annoying, is in project compilation. Pointers and such are tedious at times but the compiler is usually pretty good about correcting you while you learn.

Unfortunately for Unity, their position is such that they need to deliver more fully featured functionality OUT OF THE BOX and not lean so heavily on the Asset store. This reliance on the Asset store makes Unity far more complex than it initially looks. Having loads of different plug-ins that all operate with their own workflow and standards makes everything about Unity harder to use as your project grows.

Unity is exceptionally easy to pick up, but if you don't design your project around certain required Asset workflows, (that you may not have yet) you can hit some seriously annoying brick walls. This all could be remedied if Unity would acquire these plug-ins and integrate them into base Unity with the same "Unity way" style workflow across the board.

With this in mind, I think offering something other than C# should be the least of their concerns.

 

This. So much this.

Unity already did the multiple language things. We had Boo, which supported all of the python like camp. We had UnityScript, which supported all of the less boilerplate camp. We even have managed and unmanaged dlls, which supports the C++ camp.

Just look at how well those three options work before asking for a fourth. Let's not ask for new toys when we don't even play with the ones we have.

 

I would want C++.

Aside from C++ I would personally be interested to have common lisp and prolog bindings.

Python bindings could make sense too, although I wouldn't benefit from them.

 

At least C++ is still evolving to handle modern day situations.

https://kfrlib.com/blog/how-c14-and-c17-help-to-write-faster-and-better-code-real-world-examples/

 

I would hope that any additional language would be less work, less pain, faster results. I would even forego some flexibility if it made things easier and quicker to develop.

I don't know if a new language is the solution though, or a high-level visual programming interface. I'd prefer instead more niche-specific tools that cut out all the irrelevant noise and focus on making it really easy to do a smaller job, rather than trying to do 'everything' all in one tool. Even setting up variables and doing simple math in a visual tool is extremely long-winded compared to typing it.

 

what's wrong with LUA?

 

ArnoldC?

 

Sits with a blank stare, remembering many dark hours at University.

 

Well, all that talk of specialized languages is all nice and Dandy, but I don't want to see Unity involved in this.

I had quite a hard time getting my head wrapped around C++ programming for Unreal engine BECAUSE Epic let their APIs diverge too much from each other with Unreal Engine 4 so that they could no longer write ONE API for both Blueprint and C++.
Because they wanted to appease the newbies and artists, they decided to concentrate on Blueprint, letting the C++ API in the ditch. It is there, but the Blueprint API documentation often is the entrypoint referenced (and you need luck to find the C++ Page on the same subject from there), and oftentimes, the C++ API documentation on a certain subject does not exist, or is just extremly hard to find.

Now imagine if Unity adds yet another programming language, or god beware, multiples for different genres. How much time do you think Unity can spend on the documentation of each of those? Given that you need most engine features available to those languages (because not every RPG is the same, for example), and given you don't want to start mixing those languages (heaven forbid, that would be pure chaos!), the amount of work in keeping the API up to date would triple or quadruple because of all those new languages.
Unity currently has one of the best API documentations I have seen from any game engine. Its one of the first points I bring up about why Unity can keep up with engines like Unreal... sure, it has its problems, but it has that awesome documentation. Take that, Epic!
Even so, there are many holes in the documentation (for example I am trying to get stencil buffers to work in an image effect at the moment. Documentation on that is a single paragraph which does not really describe how to solve the problems... given how useful stencil buffers are ESPECIALLY for masking image effects, I would have expected at least one example on how to make it work), and some parts are quite outdated.

How much worse would things be if Unity would start adding new languages like candy? No thanks.