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

Well the likes of C++, C#, Java(Script), PHP, SQL and other languages have been built up and extended over time into what they are now to accommodate the demand in the market.

It doesn't matter one bit if F#, ADA, or any other language is "better" if the market is saturated with developers who demand something different.

In the end, it's all about cost and ROI to Unity and it makes 0 sense to funnel resources into implementing another language at this point. (source: I am a Business Analyst)

If you are a good programmer, you should be able to learn and adapt to any language (with proper documentation) within the limited API of a game engine, whether it's C++ in UE4 or C# in Unity

 

Haha, no flame wars here, just dry sarcasm. Forth was/is a pretty nice language for certain uses. I wouldn't want to program games in it.

But yeah, Starflight. My WIP is an attempt to recapture some of that feeling.

 

LINQ is a functional programming library for C#. I love that you used it to show how you can do a F# thing in 1 line.

The reason for talk about "Enlightenment" is that when you come from C#, and start out in a functional language, you are bringing a lot of baggage for how you program with you. The enlightenment comes from when, after dealing with functional programming for a bit, and you start leaving some of your C# baggage behind, it starts to click. You notice that how you wanted to do things, architecturally, is wrong when dealing with functional programming.

Let's circle back to LINQ. The code you had is really good functional code. C# has been adding Functional Programming things each iteration. Or really things that F# does really well. Lambdas, LINQ, Tuples, PTL, and now the next version will have better support for tuples and pattern matching. The more you like each of those things, the more you will like F# (and oddly, TypeScript/JavaScript).

My 10 minutes would focus on how F# is about approaching the problem differently. There's nothing that can't be done in both C# and F#, but that sometimes using C# is awkward to do certain things (before LINQ, you would have needed a for loop and if statements to do those sum, distinct, and filters), while functional languages focus on it. C# will have an "if" statement. But what is that really? Isn't it a filter most of the time? The Where function is a filter that you are replacing an if statement with. A switch statement in C# is another filter. Do something based on this value. F# calls that Pattern Matching (er... basically). And since F# doesn't have the baggage of a switch statement, you can pattern match based on different function results for each "Case" of the match, because pattern matching works based on the same filters as before, and filters can be functions, and their results. And now since a pattern match is nothing but a function, it too is a filter. So you can have a switch statement that uses FULL if statements for each of the switch cases.

Now that sounds cool doesn't it? That's when enlightenment comes in. There are really cool things F# can do out of the box that makes your life easier. The problem comes in that functional programming, as in really getting the most out of it, is a lot more of those small realizations. That each time you approach a problem, you will think of some C# way of doing it and get annoyed that F# doesn't like it. Things should be immutable in functional programming, that's really hard to wrap your head around, I just want to increment this variable. Having data objects instead of full classes is another one, people like their method calls. Eventually, you get over enough of this that you start to think of solutions that are based in F# instead of in C#. It's at that point, that they say "Enlightenment" happens. If you started with F# instead of C#, and used it for years, you'd have the same issue moving to C#. Think of how long you've been doing procedural languages, for me it was over 2 decades when I first started with F#. That's 20 YEARS of doing things basically the same way.

My favorite way to explain it is that it's like learning a language. If you can think in Japanese, it drastically changes how well you will use that language vs. someone who is learning it and trying to translate it in their head as they go. That thinking in Japanese is when you are "Enlightened" in Japanese, and part of why it's so hard to learn languages later in life. As they become more ingrained in how you think, it's harder to just up and replace it with another. BUT, if you can learn it well enough, being fluent in 2 languages makes either language you use better. You have more tricks that you know. You can use a Japanese word when there just isn't an English word that fits. You can solve a wider range of communication problems since there are 2 populations you can now talk with instead of just 1.

If Unity supported F# better, I would write 99% of my code in it. That last 1% would be the bits that interact with Unity and PlayMaker directly, but would call into F# as soon as possible. C# is better with events and the procedural nature of how Unity/PlayMaker expect you to act.

 

Nothing you said makes F# sound better or easier than C# in any way shape or form. I would say that a functional approach is better for certain things, but not necessarily as a base approach to an entire solution. For example, I do not want to code a function to sort an Array by object distance from player, but this can be easily accomplished through LINQ.

How on earth can a programmer say with a straight face that if and switch statements are "awkward ways of doing things". Number of lines has nothing to do with how complex something is. It's more important to be able to easily read, maintain, and extend AT A FUTURE TIME than it is to arbitrarily reduce line count.

Hell, when we were taught about conditional operators in C-based languages, we were pretty much told that you shouldn't over use them because they are HARDER TO READ than an if statement that does the same thing....despite being 1 line versus many.

Similarly, over-use of LINQ can be exceptionally difficult to read and debug in C#. Functional programming is widely considered to be "harder to wrap your mind around" which is precisely why it has not overtaken traditional imperative programming languages in professional use.

 

I think that Php is the best but I don't know why many people prefer Java Script

 

troll maybe?

 

You have lots of test data and debug projects why not scan that probably huge code base for common recurring patterns, that's if you are not already doing so to improve the API?

You should be able to run a script that uses regex to extract known token e.g. your API and C#'s commands and looks for recurring patterns?

 

Sure if it will steer us a bit further away from the language wars. I'm 33 years and some change. Started teaching myself programming at age 12 shortly after hitting middle school, followed by C++ at age 18 which was approximately when I got my GED and said I was done with the local school system, followed by C# about one or two years down the road.

 

31 here. Took 2 years of advanced placement C++ in Highschool. Went to college and entirely forgot about programming. Decided I would get a CS degree since it could get me a decent job. Worked with VB, Java, C, ADA, Assembly, and SQL (i guess this fits?0. I was a pretty hardcore slacker so I didn't take much seriously. Went into IT and currently performing Business Analytics for a living.

Most of my post-university programming has been independent projects in Untiy C# and Unreal Engine C++/Blueprints.

I firmly believe that there must be something psychological in nature, that makes the population favor an Imperative approach over a Functional one. Otherwise, programming languages would have evolved in a different direction. Where a Functional approach is more appropriate, we do have tools/languages developed for those tasks; HTML and SQL for example.

I also believe that when presented with a problem that we do not yet know how to solve, we naturally arrive at a solution imperatively. Think of how you respond when asked for directions to some destination. Your mind takes you through a mental journey to that destination and you verbalize the step by step instructions. However, when you personally need to make that trip or your "user" already knows how to get to the destination, it can be summarized in a functional way such as, "Go to Sue's House".

Everything boils down to something imperative in the end.

 

Well put.

I'm 48 and exclusively self-taught. Started at 12 when I was introduced to computers at school when they brought some in for a couple of weeks. Picked up a book on BASIC at the library, wrote and debugged my first game on paper (much of it actually worked when I finally had a chance to type it in on a friend's TI 99/4a).

BASIC, 6502 Assembler, Turbo Pascal, IBM 370 Assembler, COBOL, RPG (when it stood for Report Program Generator), x86 Assembler, C/C++, Delphi, Java, Javascript, Visual Basic, C#... uh, I guess technically SQL fits... that's the list of major languages I've used over the past 36 years.

Languages come and go. The concepts remain the same.

 

@Dave-Carlile I'm 49 and seem to have the same background as you. Right down to my first computer being a TI-99/4A. Used to enjoy playing Parsec on that thing. And Scott Adam's Pirate Adventure on either the TI-99/4A or a VIC-20. Can't remember which one now.

Playing those early games had me hooked. Wanted to learn how to make my own. So my journey into programming started. BASIC, Assembler (same one too... C64 although also 68000 on the Amiga), Comal, Pascal, and on and on and on. lol So many languages have come and gone over the years.

I agree with you completely... languages come and go but the concepts remain the same. I think any programmer with a fair amount of experience can easily move from one language to another. Unless maybe it is just something radically weird or little interest in like that MatLab or whatever it was called I was checking out once upon a time.

 

Seems to be a lot of us here in the forums . The first computer I owned was an Atari 400XL (Thanks grandma!). My last Atari was a 130XE boasting a whopping 64K of bank switched RAM - you'd flip some bits to map 4 different 16K banks into a common address space. My favorite project on that was a virtual memory system that let you access the memory as if it were a contiguous 64K while transparently swapping the banks around for you.

When it came time to decide on a PC or the Atari ST (the Amiga era Atari) I went with PC. I guess it was the right call but I kind of regret missing that final Atari experience.

Yes, this was my experience too. That 2 week computer experience in school hooked me for life.

 

One of my first real experience programming was building a simulation of a resin column in MatLab for a research paper. . Its pretty much overkill for run of the mill 3-D processing typical in games. But if you ever need to work in n-D space, MatLab is the way to go. From memory the resin column was about 7 or 8-D.

As to the rest: 30 years old. Chemical engineer by day, programmer by night. No real formal computer science training, my degree is in biochemical engineering.

My day job calls for the occasional VBA tool or a hacked together SQL database. I do some ladder logic for process control, and I'm passable in mechanical, pneumatic and relay programming. But the majority of my programming experience is as a hobbyist Unity developer.

 

Alright....

Few problems:

• I come from C++, not from C#. Also, C#/C++ are not the only languages I know.
• I'm fluent in two languages, and know bits of a third (which is japanese), so I'm familiar with language differences... and know that your analogy of a different langauges does not really work on functional/imperative.
• LINQ example I posted is NOT functional programming. The primary idea of functional programming is that "everything is a function" and that "state is evil". I'd expect you to be aware of that. LINQ ignores both ideas, and I'd expect you to be aware of that too.

The problem with your post is that you didn't ever say what makes functional languages or F# good.

You used methaphors, compared computer languages to human languages and talked how glorious it is to know multiple languages which "gives you more weaponry", then briefly mentioned woes of using switch-case in imperative languages.

Those arguments have zero value to a programmer, because they're philosophical and not practical. And ALL arguments in favor of functional languages I heard always sound like this. Lots of philosophy, and no practical reasons.

I want practical reasons and I want infinite cosmic power. If your language has significant advantage, you should demonstrate it, and it better not be something I can turn into a library/generic/template function.

A good example of such problems for prolog is "graph coloring" problem.
A good example of that for common lisp is defmacro, and to lesser extent common lisps defmethod.

In case of functional languages, the argument is usually "enlightment".... which does not really sound like a good practical reason to me. When someone is "enlightened", they should be able to demonstrate it. If they can't demonstrate it, then perhaps they aren't very enlightened.

 

Am I the only one getting REALLY turned on by this conversation?

 

God I hope so.

 

I don't know about that but I'm definitely amused by some of the responses in this thread.

 

I think I can make a guess at this. Of course I'm no enlightened computer scientist, so I could be completely off base.

The functional language paradigm is based on a program having no state. That means that if a function is given the same set of inputs, it will produce the same set of outputs every time. Regardless of what the rest of the program is doing. This totally eliminates side effects from calling functions. And in theory, less side effects mean less time spent debugging. In theory it also enables simpler testing of functions.

Now lets drop to a concrete example. Ladder logic is a language that I am familiar with the embraces many of the functional principles. Particularly the fact that the same set of inputs to a rung will produce the same output (a rung is the closest thing a ladder has to a function). In practice this means that if an output is different to expected, it is because an input is incorrect. Troubleshooting ladder logic becomes a simple exercise in checking if each input is correct.

Of course ladder logic is a language built to do a completely different job to C#. Its built to control machines. Its meant to be readable by people with no programming training. Its built to be reliable. Its built to be verifiable. None of these characteristics are even vaguely applicable to a language for making games.

TL;DR: Functional languages are useful for some problems. But not for making games.

 

I know that. No side effects means no unintended side effects. in theory it is supposed to be good for multithreating/parallelism, in practice I had that unfortunate incident with erlang-based server.

Languages like C++ allow you to exterminate side effect anywhere you want them gone (speaking of which C# could really use const methods and const arguments). You could declare all your functions as constexpr, mark all methods as const, or go further and invoke template metaprogramming voodoo, which is performed at compile time.

Basically, the whole "advantage" of functional approach seem to boil down to "no side effects", the thing is when you're already used to a language that has large array of tools for side effect extermination, functional approach doesn't look very revolutionary, and doesn't look like something that required the whole new language. If the whole "enlightenment" is about only that, then it is very underwhelming.

----

If you want to make it more amusing, imagine that every post is spoken by whatever or whoever is on poster's avatar. ^_^

 

I didn't say they were good arguments for functional programming. Just that there were arguments for it.



It's pretty hard to find anyone actually using it for anything real.

 

well.. dotnet core would be a train wreck... unless you want to write a PCL for every damn platform in existence.

 

I think I watched one of his videos showing the kind of language he'd either like to make or was making.

Although I don't know if I would focus on the language itself (other than perhaps removing the need for curly brackets) I definitely believe game dev can be much more efficient on the programming side.

I already see it as being much more efficient than GUI-based development. But... having worked in many other languages making games I have no doubt this can be much better. I'd focus on the API and underlying systems.... but we can't focus on the underlying systems directly and I imagine it would be way too much to deal with anyway.

So either we write wrappers for the API to create more BASIC-like API methods or we just replace parts of the API with our own more efficient systems. It's a better use of time I think.

I know that in my current game collision handling for example is so much simpler and faster to write because I only need to do this...

Code (CSharp):

1. if (BoxColl(v2Object1Position, v2Object1Size, v2Object2Position,  v2Object2Size))
2. {
3.     // handle collision
4. }

There is no messing with layers, no need to set up box colliders in the Editor, etc. Of course in 3D it would need to be CubeColl or more likely SphereColl.

It's definitely been another big step in the right direction to getting back to a more streamlined game dev environment like AMOS, Blitz and XNA had.

I just work on this aspect little by little iteratively over my game projects. The last two games still used Unity colliders and Unity physics methods to handle collision detection. Maybe another 3 to 4 games down the road and I'll finally have the rapid programming-centric game dev environment I want.

 

Language can affect how you think, so would a game programming specific language affect how much fun it is to make games?

On a side note the new Film arrival is based on a short story all about how languages affect our world view...

 

Spoken and written languages are not the same as programming languages.

 

I think it's probably a better/easier idea to enable the computer to better understand human language, than trying to create some programming language nirvana that people can ecstatically program in. If I'm directing a human programmer and I say "OK now let's shoot a raycast and check the tag of the first collision, and if it's an enemy call the damageable script ..." etc, they will know not only what to write, but also what information to ask of me if I forgot to specify something. This is how I think a compiler should become. But of course we're not anywhere near that yet.

One of the biggest problems with a very high level 'game dev' language is how to transition in and out of complexity as required. How to you access fine detail on an api call without having to specify some huge long argument list? An 'intelligent' compiler is needed, and it may be far easier to make something like this in the narrow sense of game dev, compared to trying to make a generic one for software development.

 

What I would like to see added is actually a much higher level programming language which even less experienced folk can get to grips with, which sits on TOP of something like C#. It should let the user accomplish tasks quickly and easily - you know, most of the common things people do, without having to dip into lower-level code. Maybe sort of think of it like a function library. Each command runs a small function to do a small job. Make it modular. Sort of like what the visual programming tools are trying to do, except not visual i.e. still typed. Keep it simple, make it friendly. And then give the option that if people WANT or NEED to, expose the underlying c# function and allow it to be 'customized'.

 

The problem is, once the compilers are able to do that they will spend all of their time arguing with each other about which one of them is best.

 

What's stopping you from building your own solution? You could design an interface similar to that of Script Inspector 3 for creating scripts directly inside Unity and silently convert the code to C# files.

 

[LONG sounds of creaking wood]

My first machine was an Olivetti Programma 101 that my dad the car dealer let me play with on Sundays when he was at the office. It had magnetic strips that had pre-coded programs from some vendor. I was able to write some simple stuff for it.

In high school hanging out with the local science fiction book club, a college kid had the night shift in the local university computer datacenter running card decks on an IBM360/mod40. He let me hang out there and use the keypunches and hand in decks. As it happens dad had me sign up for typing (in order to meet girls) so I knew how to touch type. A weekend later I had my first fortran program plotting some Hertzsprung-Russell diagram. Later, Conway's Game of Life as that had just emerged. Didn't work so well on folded fan paper.

In college, I took one comp-sci course, fortran, and only showed up for tests. I stayed away from computers (too irritating...not enough games) until I had to type my math thesis, done myself on that uni's Amdahl vs paying someone on a Selectric. That place didn't even have a comp-sci department until as I left.

As an asst prof teaching calculus, I got back into coding and for fun did planetary motions and predicting eclipses and what-not. That department was mixed math and comp-sci, so I got assigned to teach a course on formal programming. We pretty much all failed (but passed). The students didn't grasp constructions versus proofs so much, and the simple five-line program on the final exam took hours to prove.

Teaching was fun in Texas, but low paying. I was able to buy a Zenith Z100 (pre-assembled if you know what I mean) with two floppies (no HDDs those days). Another prof and I started a start-up and writing a game in assembly, and later pascal. It was to be a No Man's Sky in that it could produce a dungeon the size of Jupiter on an 8-bit machine. But...

The college kid with the keypunches had grown up and gone to Silicon Valley, and asked me if I wanted to help build a microprocessor and double my salary. First thing there I noticed was the pen plotter. It was hideously slow as it picked up a pen and drew one shape for a transistor, and then move back to the carousel and pick up another pen for the next shape on another layer. That's nuts, and so wrote a database that harkened back to some category theory for its core organization, and was able to easily optimize by layer the bloody thing. Those days were Vax780 running VMS and Ultrix and overhead serial lines.

That was all, still, in fortran. My last fortran project was a static timing analyser that told designers how fast their circuits were as they made changes to it. Modern tools still have issue with that last part.

The folks writing the OS and the compiler were all using C. They got us, the CAD team, programmers, to start using it. Something about eating your own dog food. Projects there included rewriting the categorical database in C, and doing circuit and logic simulators in C. There was an unholy number of polygon processing utilities to write. Those days there weren't many tools we could buy so we wrote most of what we needed. One tool we bought (actually owned the company so not much choice), a place and route system, was written in mainsail but we didn't have to deal with that so much. It did have a hundred knobs on it that nobody could figure out how to tune. We needed another AI program to figure out to turn the knobs.

We had to implement our own asynchronous language in order to describe how the actual machine's innards works. You may write synchronous code, but the machines aren't unless tamed. Nowadays folks use verilog and vhdl.

Once the first microprocessors were fabbed and dropped into an IBM/DOS desktop box, we were able to offload the vaxen and get more into unix (of course we had our own named flavor incompatible with everyone else). See above about dog food.

The cad team boss left, so I took the position and kept coding. But now I had folks I could hand parts off to. I had about twenty people split evenly between programmers and layout designers. The programmers had to have college degrees and were exempt. The layout designers, who drew polygons (aka circuits) didn't, and were non-exempt.

I recall one time when a compiler guru was going on about the barrel shifter, and I told him it was right outside his door for which I got an odd look. I had plastered huge billboard size plots of the chip on the hallway walls, and as it happened the barrel shifter landed right outside his office. He was amazed that one, he could actually see it as a physical thing, and two, that someone could point it out to him.

Those days had lisp lurkers upstairs in the AI department with their spiffy (but weird) lisp machines. That all went nowhere. Some mathematician I hired back from the science fiction club was into forth, but that went nowhere. We had to evaluate cool massively parallel boxes like MassPar to see if they could do logic simulation. Not those machines.

In one building the smalltalk folks' business was downstairs. We couldn't figure out how to use it. Another mathematician was into prolog. But it wasn't good for stuff like does-this-polygon-touch-that-polygon kind of thing we needed to know in order to find good stuff like shorts and opens. So I hired a mathematician from back in Texas to write the geometric sort code. In C.

Most of those "other approaches" like lisp/scheme, smalltalk, prolog, were all too weird to write code in and altogether too slow. We needed to be closer to the metal since we were actually making it. We have to deal with enormous data volumes in chip design. One simple rectangle for a circuit at the beginning of manufacturing may turn into a 50-point polygon with multiple assist features lying about it, all sliced and diced into trapezoids for flashing onto one of the chip's masks.

On the other hand, having a "high level" scripting language can be great. We took the categorical database and added one to it. We'd then draw diagrams of the data, and use the database operators to transform the diagrams. All pictorially. Once done, we'd transliterate the final diagram into the scripting language, and the program would work the first time with great speed. That way we didn't have to spend so much time debugging.

Later I got into C++ once it looked production worthy and started honing an interface centric approach to developing our products. Still there today. In the company I work for now, totally unrelated to the gaming industry other than making the chips that power it, there's no java I'm aware of. I think the last project died off ten years or so ago. There's python and tcl. No PHP. No real javascript. Well, I write some of my management tools using that stuff, but in the actual products the only javascript is in the docs to do a search function, but that may be something we bought. Standard corporate slide deck shows jquery code which amuses me no end since it's not part of any of our products.

Nowadays I've a hobby of writing a game in Unity, lurk here to see news, and have amusement at this thread. I learned C# to do a debugging tutorial for the Company in Unity so I could have better visuals, like just how should you visualize two's complement arithmetic or a translation lookaside buffer? C# is... interesting. But it still feels to me like an interpretive language, particularly given the advice I've seen in these forums on how to hand optimize your code.

I have a team now of about 20 split between programmers, QA, and a product engineer. Since our code is highly likely used to build the chips that you're using to view this message right now, and I don't like late night phone calls from the other side of the Pacific, my team has extremely rigorous production procedures.

To maintain our C++ code we've been basically doing continuous integration and devops before those terms existed. Not all around are such zealots, but this works well for us by maintaining code at a production pitch at all times so if need ever be, we can release that emergency patch very quickly so you can get your chips.

We use a lot of verification tools to maintain code quality. There's valgrind, Purify, PureCov, CodeCollaborator, Perforce, Coverity... Our release criteria say we must be 0/0/0. Across our thousands of source files and regression tests, that means we must have no compiler warnings, no Purify errors (memory leaks, uninitialized memory, array bound read/writes, ...), and no Coverity errors (a static code analyzer). We like to go one further to 0/0/0/0 and have no reported crashes from the field or ourselves. And code check-ins have to be authorized by an action request (aka bug or enhancement) and code reviewed. Regression tests are required, and those get code reviewed between qa and the devloper. A project has to have at least 80% code coverage to be production worthy. Lastly, the requestor validates before we push the code to the production branch.

While some might think the above process is a few steps beyond rational, our team is pretty happy with it and its easy to do with the right culture. We don't spend so much time debugging. When we do a customer debug, we almost never get a test case. Who's going to give us their chip? Besides, some of the files we can generate can be terabytes in size. They'd have to fly it to us for us to look at such a thing. As it is, we're lucky to get an encrypted stack trace back from the field (yes the symbol tables are actually encrypted).

In this C# environment, I miss my tools.

Most of all, that includes C++. I miss STL, const, C++##, ... Yes, I could do linq, but it doesn't look as bare metal as STL can inline down to with -O3.

I miss TBB and its excellent allocator. But maybe even with a C++ iUnity interface I'd not be able to replace the allocator or a threading model.

Still its the whole C++ pre-existing ecosystem above that I pine for in the C# environment. As coders, all we do is integrate. In C++, you can integrate a lot.

In my humble view and despite liking high level languages sometimes, C++ would be the way to go and most cost-effective for UT versus visual or functional or categorical programming what nots. Not that UT need do it, but it does seem that for their current project lineup they may be doing more C++ level integrations so they could be internally ramping up the C++ doxygen.

Moral of this story: Take the high ground when you can. In my story that's hanging out at the datacenter rather than the car dealer (I had to work in the parts dept anyways). Or touch typing versus touching girls. Or math versus comp-sci. Or C++ vs C vs .... Or microprocessors vs games. Or exempt vs non-exempt. Or vi vs emacs. Ok maybe not that one, but I got used to vi from playing rogue.

I'm thinking of putting that visual categorical programming thing into my game as a puzzle to find shorts and opens. With any luck at the rate I'm going you'll never suffer from it, like why am I typing this when I could be coding...

[sounds of creaking wood dim...]

 

vi for life emacs can go to hell

 

I avoided and regarded computers as very expensive typewriters and only went to college after cumulatively skipping high school or quitting high school often enough to have failed 3 years of it but learning I was not suitable to be a short order cook or could I ever expect to even rent my own apartment, LOL, forget a house, or buy a decent car making $3.35 a hour as a bus boy, although being a bus boy was fun.

So no, I wouldn't have expected to go to college or get a degree in mathematics or computer science but I did. It did let me afford those things that being a bus boy did not. Being a bus boy was more fun though.

i started with Fortran 77, then Pascal, Lisp, Smalltalk, Assembly, C and from it's a long list of special use cases...

I still can do C the fastest (as I know how to use ar/nm/man to figure out a relatively small system API) but I admit I like the C# and the VS IDE 8autosuggest) better for huge API that I know next to nothing about and don't intend to try and memorize anything soon, like the Unity and NET and so on APIs)

 

No offense, but this smells like sophistry or a rhetorical question.

Yes, languages affect the way you think. HUMAN languages. Computer languages are tools that come and go, you can drop one and pick another, and they are not THAT radically different from each other. There are roughly 3 fundamentally different types into which all languages can be classified, and beyond those basic types, the difference between languages often boils down to keyword names and what's available in standard libraries... plus sometims a language might have a cool feature or two.

With human languages you'll have to deal with some languages having/not having future tense, plurals, word construction facilities, formal/informal speech, and there are multiple systems regarding tenses. It is very different.

 

It's more likely the opposite is true. Languages are shaped by the thinking of the culture that produced them.

It's said some Eskimo languages had 17 different words for snow and ice. The language didn't shape that thinking. The fact that snow and ice are important shaped the language.

The same can be said of the French language and their concern with maintaining a distinct national identity. Or the English with our barstidised approach to stealing everything we could get our hands on.

The same principle is true of computer languages. C# didn't drive OOP. OOP drove C#.

 

Originally, I would have liked to have C++. Then you wouldn't have this situation with IL2CPP like we have now, which doesn't seem to be coming to some platforms anyway. I only say this because it is easy to criticize things in hindsight. As things are now, I prefer they wouldn't add any more languages. I'd rather they put valuable programmer time into handling other matters that need attention.

 

You're going with Chicken and Egg logic, sidestepping adaption and evolution.

Have you heard that the Chinese are great savers, and have you heard that Mandarin does not have a temporal tense. "I put savings away" as opposed to "I will put savings away" or "I have put savings away". The impact of not focusing on when something happens gives them a tendency to be less focused on the now and more on a longer time frame.

Or to put it in programming terms to think about and program with Objects we need OOP. But that brings it's own problems as in programming we often want behaviours e.g. a Dog Walks a Man Walks in OOP we tend to end up with Inheritance as the basic behavioural reuse pattern e.g. Walking Mammal branches out to Biped and Quadruped.

Which is wrong. We end up with design patterns to work around these language flaws e.g. Command Pattern, Strategy Pattern.

What I'm talking about is what if we instead of reaching for a pre-existing language we take a look at game development it's needs and requirements and build a language designed to make it easier to write games.

Is OOP helpful yes the ability to have a class or object represent something is amazing for games, why would you want to go back to limiting yourself to just functional programming. But do you want to be locked into only objects no, some things are processes they change data and work best as functional entities.

What about Aspect Oriented programming where objects can have many behaviours layered onto their default behaviours. e.g. Walking Dog, Man, Horse, Velociraptor. And it sounds remarkedly similar to Unity's component based approach.

Finite State Machines are very handy in game development should they be built into a game oriented language?

Agent based programming was designed to allow AI systems to be easier to work, this approach to developing games should definitely be considered.

Now a lot of people have complained that no Unity should focus on fixing, improving and adding new features before they go adding a new language....

Think about it if Unity produced Unity Basic, designed to make it simple to make a basic game, they would have to improve the other features of Unity as well. Without a fully working and feature rich game engine Unity Basic would not work.

Or if Unity Basic was launched how much faster would developers with a higher level language hit the existing problems it has probably taken us much longer to find.

e.g. The prefab problem could pop up if Unity Basic added Equip, Make, Pickup or Drop commands.

 

Is a Game a simulation?

I would say that yes they are, they are mathematical systems that abstract and reproduce a systems behaviour or simulation.

So should we look at programming languages that are designed to run simulations for inspiration?

I would say we should look at the features of good Simulation Languages, for inspiration on what a game oriented programming language could bring to the table.

DID YOU KNOW Simula a simulation programming language is classed as the first OOP language.

And the simulation programming languages are very big in business, so it could be a very lucrative area for UT to move into!

 

Do you know what problems a language is actually meant to solve? I get the fact that you want a language that is ready to solve all of your problems, but are those actually the domain of languages? How is any of this important for finding some portion of data that needs to be fed through some instruction?

Cutting corners is what APIs and frameworks are for.

 

No, and there's no reason to think this way. They could add "language" to the engine without changing anything else.

You mean, after 15 years developers will spend creating unity basic?

A lot of stuff you describe is usually dealt on library level, not on language level.

Your example from earlier is very similar to C#.

Code (csharp):

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

The differences are: No semicolon at the end of the line, and no braces around function arguments and if. And that's it.

If you want LOS and hide/show functions, you can write those.

 

Your right, just like JFK in his moon speech didn't know what was fully involved in making a Saturn five rocket system, I do not know fully how this idea will evolve and turn out in reality. However, I would like it to have some of the following features:

• Simpler syntax.
• More powerful common commands.
• Built for parallel programming on CPU and GPU.
• Built alongside a Visual game development system (both work together).
• More powerful game specific features built in FSM / Aspect and Agent Oriented Programming / TBC
• TBC

You have a point, but do you know that when programmers who were using punch cards started thinking and talking about how they could use a programming language make their job easier they were shot down for wanting to waste valuable computer time to do the job they were paid to do!

Sorry I don't understand the question?

You're right again, only programming languages can provide layers of abstraction that empower developers to think, design and write programs easier, faster and cleaner especially in limited knowledge domains e.g. game and simulation development.

 

I can only assume then that you don't know what the number one thing programming languages actually do is.

Who were these programmers and where did they work? Somehow I don't think these where the guys working at Bell Labs who got to do whatever the F*** they wanted for R&D. In case you're wondering, Bell Labs is second only to Xerox PARC in being fundamental to modern computing while also not making a penny (relatively speaking) on any of it.

All you want is candy. None of this will make a game better or more performant. It might speed up development, but that assumes the features are both desired and competent across the board. If anything, game developers don't want high level abstractions. They want to see what's happening down on the metal, and don't want a bunch of whizzbang features that don't fit their specifications in the first place.

Did you actually watch the Jonathon Blow video, or better yet the Mike Acton video that should be linked from it?

 

What you're doing is called daydreaming.

For each point you dislike in currently available language:

1. Identify and define the problem you're trying to fix.
2. Determine significance of the problem and impact of fixing it.
3. Look for possible solutions, evaluate them and their implementation cost.
4. From possible approaches pick one, or consider abandoining the problem if solutions are too costly or there are none of them.

Repeat for every issue you have with C#/whatever language. Chances are you don't need a new language.

Or, you know, make a prototype of the language and present it for people to evaluate.

 

Interesting. There was a lot about XNA that I liked. Such a shame it died, officially anyway.

On a different subject, but what I began thinking about after reading this...

I'm really interested in a game language that handles 'game containers' well. Arrays are too troublesome, Lists still need to be iterated on in an annoying way just to find data, and Dictionaries are better but even more annoying to iterate over. Then there's efficiency, and of course this is stuff just in the C# library I'm talking about.

But I've seen endless arguments as to arrays, vectors, maps, linked lists, etc. In C++. And there's a lot of arrogant programmers claiming things like 'maps are horrible for gamedev and should NEVER be used' (which is just plain wrong, but some users at stackexchange are massive idiots with enormous ego's). So I see a lot of arguments & multiple (contradicting) advice.

So I think a game language should try its best to limit misinformation (multiple opinions) on many things, as best is possible, Maybe one container to rule them all, so we can just get on with it. Sure, we could still have others for more control, but maybe a 'main' one that focuses more on ease of use than anything else, or a 'performance' second one or package to make even that easier.

And why stop there? Maybe an IDE that we could ask "What is the most efficiency method for this?" Something to both help novices and assist experts learn the language at the same time. Something smart, possibly even with tooltips with collapsible examples for literally everything? API with incredible smart docs / analysis built in.

After all, a lot of game code is similar. Repeated methods. Like iterating over a game container (array, list. Etc.)

 

Hehe, at their current rate? If Unity tried to add a programming language, we'd be stuck at 5.3 with no feature updates, no bug fixes, for 30 years. And upon release, it would be the year 2046, and Unity Basic would be released as a broken barely functioning language with bugs that fried your CPU. Meanwhile, we've all been programming in AR with our brain waves for the past decade.

In theory, if someone were to compete with Unity, they'd be able to quickly put them out of business if they didn't suffer the same weakness of 'takes forever to do anything at all'. (And no, Unreal is not already trying. It's not trying to be Unity. It's just trying to be Unreal in a slightly competitive market. Big difference compared to my hypothetical competition that tries to be Unity.)

I don't know the reason for their slug pace, but Unity is the last company I'd want making a new language. Because I'd want it before I died of old age.

 

If you think so little of UT why are you still here?

 

What are you talking about?

Spoiler

How do my thoughts about the company or engine's past or future, have any correlation with how effective it is at game development in its current state? In fact, my opinion about the company or engine is entirely irrelevant to the reality of what the engine is. How effective it can or can't be.

I love Unity Engine

Spoiler

& respect Unity and everything the company has currently accomplished (with the exception of recently unfinished "releases", like UNET). I just agree with the vast majority of everyone else that we should only use what we have at the current moment, because future updates are far far away & take up to years to fix up after release.

Also, I believe the number one reason to use Unity is not Unity.

Spoiler

It's all the wonderful Asset Developers. That Asset Store is, IMO, Unity's greatest strength. The engine itself is great for niche games, good-to-okay for most, and outright horrible for others. It also has a ridiculous learning curve that instantly makes using it for your project a very questionable decision.

However it is a game engine that uses collaboration to compile an enormous set of good-to-amazing third party assets that really speed up development, take a lot off your chest, and help prevent burnout in a burn-heavy industry.

Unity by itself, before the 4.6 UI update

Spoiler

, was IMO horrible.
I considered it trash, never to be used except for very niche projects, and only if you already have the knowledge to use Unity.

After the UI update & a few other updates (and a great year for them, where they upped their game, IMO)

Spoiler

it became a good engine IMO. However, it has always been a great, probably even amazing game tool for your own engine. When I was developing my own engine to test Unity's efficiency, I could see a lot that Unity could do for me as a game tool for any project. Especially now, with that awesome new UI. But that's also where I discovered Unity actually slows development time in a lot of cases. For one of my projects, anyway. And that's coming in from a perspective where I already had years of Unity experience but 0 experience making my own engine. And making my own engine was easier, faster, and superior in most ways. The only category Unity beat it on, was in setting up the core (Rendering, etc.) which only took two full work days since the game was just 2D. Now, I don't know much about making your own 3D engine, but from my limited experience & what I gather from other seasoned developers is that it isn't much different than anything else. People still create custom 3D engines for their games.

If this doesn't make sense or seems contradictory, then try this:

Spoiler

If I were to say Engine#42 was both a "horribly made engine" AND "one of the best", that isn't necessarily a contradiction. Because those are not mutually exclusive. It would just mean that everything else is far worse, despite its flaws. The best shaped, least foul turd among a pile of turds is still "the best turd". (Not calling anything a turd. Just a great example.)

Unity doesn't suck. And it's NOT bad.

Spoiler

That's why it's one of the best. Doing as well as "Not Horrible" is a pretty fantastic feat in the gaming industry. And to give more perspective: Most developers (especially AAA, but not excluding Indie) develop their own engines for a reason. They don't use Unity. And even with all the great updates, there are still plenty of reasons not to.

It's all based on the individual project.

Spoiler

Unity is saving me a significant amount of time in my project that is designed to take advantage of nearly all of Unity's strengths (as opposed to none of them). However, that Asset Store probably saves more time & headache than anything Unity will ever do. Then again, maybe I'm nuts? I found creating my own engine thrilling & fun, as well as fluctuating from "so much easier than Unity" to "oh my god, my head is going to explode". At the same time, this was years ago when I didn't know how to program as well as I do today.

And even after my first game is released, I may stick with Unity.

Spoiler

Because the more you learn Unity, the more you work with it, the more you can do with it. The easier things get. Thus the more time you save.

 

Is this your first Arowx thread? Read a few more of them and you'll start to see a pattern emerge. Just looking at the thread title, you might think that there is a valid argument to be discussed. Then upon opening it, it becomes apparent that OP has no idea how it's a valid topic, so from the word "go," the entire topic tumbles and falls off a cliff.

 

Really please find one of my topics that does not aim to improve Unity as a game engine. Topics I have raised in the past:

• C++ Version of Unity for direct to metal code -> Unity eventually brought out IL2CPP but not to standalone.
• Mantle / Vulkan / DirectX 12 as new graphical API's that take advantage of Multi-Core CPU's
• Adding C# to GPU programming features.
• Parallel programming features like SIMD and the above mentioned GPU programming, Unity added a multi-threaded task system to the core engine and optimisations.
• Hitting the limits on Moore's Law and its potential impacts on silicon chips and the future of game development.
• A new language with game centric features.
• The addition of Free Frameworks or templates to boost the ability of developers to get started, highlighting the lack of common and simple game objects like doors.
• The potential for the Mechanim FSM to be a component within the API opening the door to visual programming in Unity.
• Garbage Collection improvements or removal as a feature as it is a sub optimal solution for game development at the moment.
• 64 bit 3D space or infinite origin shifting built in (Unity is limited to about 10k from origin).

Unity cannot improve as a platform if it cannot be criticised for its fundamental flaws and weaknesses. I think the programming language and API could be greatly improved.

From the simplification of the syntax to the ability to write parallel code that can run on the CPU and GPU, to Agent/Behavioural programming paradigm features that can empower game developers.

And not just me but others have complained about these issues and others features, prefabs, terrain, speedtree, mechanim, 2D features, UI (now mostly fixed), Navigation Even going so far as to ask/beg Unity to stop adding new feature bling and just fix the old broken features.

But to counter my 'negativity' and creative criticism why not write posts that sing the praises of Unity and put it on a pedestal why don't you?

 

It's very simple. They shouldn't, at least not currently.

The investment of time and effort into supporting another language would detract from other features, in addition it would expand the support requests massively requiring more support staff (or spreading them thinner) and all for very little ROI.

If a new language came along that was so great it was rapidly adopted as an industry must have then sure, it would be worth it for Unity just to stay ahead of the pack but otherwise it's vanity stuff.

You can argue the merits or failings of various languages out there all day, but it doesn't change the fact that the languages Unity supports right now are more than adequate for the job in question. They're easy for beginners to get a hold of, and while not known for great execution speed or assembler output, they don't need to be for the majority of tasks that they are used. They're really ideally suited to the job. If you need more power at least with the Pro version you can build your own libraries in whatever language you desire and utilize them as plugins.

IMO the only things that UT should do better are inbuilt visual programming for rapid prototyping and for artists who maybe lack any ability or desire to program with a text editor, just to lower the barrier a little further. The current tools still force you into scripting when there are so many tasks that are identical between so many games and just don't really need it.

 

Look, to improve a software, you need to have a goal. Going in direciton of that goal will be improving the software.

Simply trying to stuff the engine with features is not necessarily an improvement, because features have implementation cost and maintenance cost.

What problem are you trying to solve by proposing to add a new language?

 

And after saying they don't need a new simpler language you say they need a visual programming language, why not build both together, one you hook up graphical components and the other you type code. Only they are both the same a new simpler syntax for writing games in Unity. Technically they could produce C#, Boo, Javascript, C++ code to build and run the games program but in essence you would have a new language for Unity.

You would have to make a simpler language, would you want the graphical 'nodes' count and complexity of C# code?

Let's count the nodes:

Code (CSharp):

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

Total potential visual nodes 9

Code (CSharp):

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

Total potential visual nodes 27

If you want a visual 'node' based programming language you are inherently making a simpler language with a lower complexity API. In essence you will want common tasks to become simple nodes e.g. LOS.

Would you want a visual language that needs a ';' at the end of a line?

Or a three node one parameter setup to show or hide a gameObject. When actually you could have a single node/command of show/hide with one parameter.