Would it be possible to Just code randomThing = ArrayOfThings[Random]; ?

Would it be possible to Just code randomThing = ArrayOfThings[Random]; ?

Instead of randomThing = ArrayOfThings[Random.Range(0,ArrayOfThings.Length)];

 

You could pretty easily implement something that would allow for randomThing = ArrayOfThings(Random)

 

Yes.

 

Would Unity providing a more declarative API improve things?

 

Why should they when this problem can be solved with a handful of lines of code?

 

Actually suprised that you're not aware of extension methods.

Code (CSharp):

1.     public static class ArrayExtensions
2.     {
3.         static readonly Random Random = new Random();
4.  
5.         public static T GetRandomElement<T>(this T[] array, out int index)
6.         {
7.             index = Random.Next(array.Length);
8.  
9.             return array[index];
10.         }
11.  
12.         public static T GetRandomElement<T>(this T[] array)
13.         {
14.             return GetRandomElement(array, out _);
15.         }
16.     }
17.  
18.     class Program
19.     {
20.         static void Main(string[] args)
21.         {
22.             var array = new[] {1, 2, 3, 4};
23.  
24.             Console.WriteLine(array.GetRandomElement());
25.  
26.             var randomElement = array.GetRandomElement(out var randomIndex);
27.  
28.             Console.WriteLine($"{randomElement} {randomIndex}");
29.         }
30.     }

Just a sample code.
It could be an extension method for the Random structure being used that receives an array as parameter. That would probably be better in a real use case scenario.

 

Improve for whom? Syntactic sugar like this is far too specific to be worthwhile. A beginner will be too focused on learning the important aspects and an expert won't have need for it.

 

Declarative programming just takes the API to a higher more domain specific level e.g.

• enemy.Chase(player);
• unit.FindTarget(enemyFaction);

Instead of telling your game exactly step by step what to do for domain specific actions the API does the heavy lifting making it easier for everyone to work with Unity but a bit more work (but interesting work) for Unity programmers.

In addition it could make the job of Asset developers and Unity developers easier as there will be standard ways to do higher level domain specific things.

Potential side benefits a more declarative API could use DOTS/BURST/JOBS under the hood to massively boost performance with way less code.

 

This is totally a thing, which IMHO Unity purposely does NOT do. Other game engines (and I think maybe UnReal today) have a built-in way of doing things and lots of dedicated commands like that. In this case, they'd be assuming you're using their one pathfinding system (for Chase), and enemy tagging system (for FindTarget) and so on.

Unity is the opposite, which I think is what helped make it popular. You can make the player lots of ways, use any sort of pathfinding, have jumping work however you want... . There's no way to make a Chase() command since there are so many ways you could have made things. So in UnReal you quickly make a generic "Made with UnReal" game, then spend time hacking the engine and tweaking to make your game. Whereas in Unity you go a little slower, but start-off making it how you want.

 

Or people could write this themselves because there are specific needs for specific projects and this is not something that requires an in-engine solution whatsoever. This is a solution in search of a problem.

 

probably not but
randomThing = ArrayOfThings[Random()]
Probably yes

That's unity path finding though

That's probably two (unoptimized) lines in unity

find with tag (faction)
https://docs.unity3d.com/ScriptReference/GameObject.FindGameObjectsWithTag.html
Then move to target with the given pathfinder

 

OK
enemy.Attack(player);

The idea here is to enable developers to work with Unity at a higher level without having to keep re-inventing the same game actions over and over (was going to say wheel but Unity does actually have Wheel components).

 

They don't need to reinvent them "over and over" because they can just use their old code that does this and adapt it as it fits their needs.

 

Let's assume that Unity has lots of new developers every year and they don't have your old code but they could have access to easy to use higher level Declarative code to get them started, faster and easier than old Unity coders.

Or imagine you take part in a game jam, just for fun and write all the code from scratch.

Would you prefer to write?

1. Low level code that takes more time and is more likely to have bugs (bugs you spent time on removing from your old reliable code library).
2. High level code that will get you up and running faster.

Actually with the big drive for DOTS and performance a Declarative API should be ideal for new developers.

 

This is a microoptimization at a ridiculous expense.

 

This is what bolt is for and the high level nodes they are making in there. If a user really cannot learn to do the simplest things like you are mentioning (which would not be considered low level at all by most coders even a lot of beginners), then they have bolt.

Same like in UE if a user cannot learn to use c++ they can use BP and all the high level nodes it comes with.

Adding this sort of nonsense to the unity c# API would be absolutely bonkers, especially when most users who struggle with this, would rather a visual based approach than code based anyway.

As has already been said this is just trying to find a problem where there isnt one.

 

Erhhh... nope. UE's C++ code is full of idiotic, completely randomly called, high-level, undebuggable macros. It is a poster-child why this should not be done. (IMHO, obviously)

 

Define attack!
Magic? projectile? area of effect? debuff? hitscan? knockback? should it move to player? avoid player? stay at distance? turn base? real time? coordinated with other member? rate of attack?

This isn't solvable at high level, nor at low level, it's brain level logic. At this point it's not high level language, but game template, therefore go to the asset store OR pay a programmer. Arowx is asking such a high level language it become a brain level language, aka make my game button.

 

enemy.weapon;

 

And how do you propose that is handled? And why is a system like this so desirable that it should be added to an engine that already did away with two other programming languages? Why does supporting a system like this, which would have a great deal of technical complexity driving it, benefit developers or Unity when most of the problems its solve end up just introducing overwhelming architectural difficulty the moment a project becomes even remotely complex?

 

lol, wut?

it was already posted here, you have to code what suits your game.
if you can make a high level interface and pack it into a library in order to reutilize it and just change the implementation, good for you. it can be done with multiple stuff, but gameplay behaviour often is just too specific...

and if this is your first Unity project, then good luck with your game and that's it.

with that said, I kinda like the gameplay framework that UE provides, with Controllers, GameModes, Actor, Pawn, Level, etc.
I think it's pretty game agnostic and makes it easier to setup some core functionality, at least after you've learned how it works.
but only for structuring things and the relationship between them, not for actually programming the gameplay unless it fits well with what's already there.

 

I mean he is following the logic of metaverse buzzword spreader

 

even better:

game.everything

 

Oh, just build the

42.exe

and call it a day.

 

This is all kinds of silly now. Magic buttons are fun to think about but for very obvious reasons not an practicable "idea".

For general jibber-jabber and silly stuff like this, please use the discord channel.
Closing and moving to discord.