Bring on the hate - I'm playing with Unity

[Kryzon]

Thanks Derron. It seems in C# with Unity there's this "global" level where all classes are accessible (if they're in the same namespace), so it seems you'd just use "using" instead of import or include.
An example:
https://forum.unity.com/threads/call-function-from-a-script-not-attached-to-object.121862/#post-818848

"Script A" in that case is attached to a GameObject (because the class defined in it inherits from MonoBehaviour, a requirement), but script B is just some loose script not attached to anything, just used to separate/organize code in a logical way.

[Qube]

You've also got the new Entity Component System for high performance code https://unity3d.com/unity/features/job-system-ECS

Don't ask me any questions about it as I've not even looked at it yet and more likely won't for months yet

[Pingus]

Unity seems the gold standard for developping Android/IOS apps. I *need* to get into it but I hate the idea to have to trash years of bmax coding because it is object-centric and not code-centric. That means that most of my existing code must be totally rewritten in a totally different way.
I wonder tough if there would be some kind of possible 'cheating', like writing a 'drawimage' function to handle sprite drawing the same way as in bmax. Sure it would be at the cost of some efficiency, but seeing that there are visual scripts plugin, it can not be worse (or can it ?).

[Kryzon]

@Qube I didn't know ECS was coming to Unity. I know it's supposed to be like this super genious way of thinking about your game objects, different than the way we're used to doing things with inheritance from OOP.

@Pingus you can't make a game in Unity without programming it with scripts, even if Unity takes care of rendering your sprites for you.
Its supposed to let you worry about the things that matter: gameplay & UX.

[iWasAdam]

... on topic but slightly off topic 
I just hit the link you provided to the unity Entity Component System. I've not got far. say the first real slide about 14 minutes in.

Bloody hell!
- OOP is not optimisable
- data (things) should be not be built from defaults, but from clear things that are built to do one job really well
- data should be explicitly declared at the start
- 'stuff' should be able to be validated
- No Garbage Collectors
- streams of small data xyxyxyxyxyxy. NOT blobs of big data1, data2, data3

These are all really interesting observations how messy things have got and how to rewrite the concepts of doing stuff.

a good example would be something like a particle system.
1. lets assume the data is already small, just xyz locations
how Could we represent this?
3 arrays of x y z
an array of type xzy
a linked list of some sort

arrays are fast to access but limited in size as they should really be pre defined
arrays are slow to sort - as you are moving data around
lists can hold any number of items, but are slower to process. there is also no direct access of list objects
lists are better as sorting doesn't require data to be moved - just the pointer/ref

I think the reality here is we are talking about stream processors. Where we have a stream of little data and minimal interaction on this data.
E.G. think of a a defined array of xyzxyzxyz, stored in memory in that order
the stream processor starts at the beginning of the stream and eats data in 3 data chunks (xyz), then output (whatever the process is) the result
the other thing it seems is that (to keep things simple) you don't have access to other data chunks. so that the chunks in a stream could be processed out of order, or even process in parallel.

So...
the simplest extension of the particle system would be the data. there would now be a second stream of modifier data
from xyz to xyz + XYZ (where XYZ are modifiers - think small numbers of movement)
the process becomes new data = old data plus modifier data

The result could be fed into another processor that eats the entire voxel data for a level and the particle stream positions
if the voxel position[ particle xyz ] is occupied, kill particle

etc...

[Pingus]

@Kryzon,

My purpose is not to make games without scripting, it is the opposite. I would like to get rid as much as possible from the engine UI and loading assets and clicking on gazillion of checkboxes... I plan to find ways to 'translate' my bmax code so that I do not have to wonder about game logic, just focus on learning about specificities.
The code logic itself shall not be too difficult to translate in C#, after all theses are objects, methods, functions, globals, locals... but the whole game-display logic is based on Drawimage and Drawtext which is a non-sense in Unity as it handle the assets on its own.

[Qube]

GPU Instancing. Cool beans

This was one of the included demo's so I thought I'd whip up a quick video. 50,000 asteroids and the GPU fan didn't even move an inch

[therevills]

Cool!

Sir, the possibility of successfully navigating an asteroid field is approximately three thousand, seven hundred twenty to one!

[Qube]

Cool!

Sir, the possibility of successfully navigating an asteroid field is approximately three thousand, seven hundred twenty to one!

Lol, there's no navigating that one unless you go really really slow. Wonder if the whole GPU instancing allows for movement and rotation too? Hmm, something to look into tomorrow.

[playniax]

Cool demo!

I did a 180 on Unity.

Using it daily now...

[Kryzon]

Did you make any progress with VR games, Qube?
I'd love to hear the tips and tricks you discover.

[Qube]

Did you make any progress with VR games, Qube?
I'd love to hear the tips and tricks you discover.

Not yet unfortunately due to having to do real life boring coding. I'll probably be doing one or two more little games in Unity before diving into VR as there's still a lot of the basics I need to learn. Will definitely be doing a worklog when I get around to doing my first VR game