First off, I'm not a big fan of all this visual editor malarkey. It drives me nuts wading though a mass of GUI when creating games.
However...
I fancy doing an Oculus Go game ( VR headset for those that don't know ). As it happens there's a module ( from the Oculus team ) for Unity that has all the bits and pieces you need to support the Oculus Go.
So for that last couple of days I've been diving into Unity ( again ) and having a general play about. My play about has resulted in having multiple cubes spinning and bouncing off each other while having a spot light shine out of them, casting shadows and particles zooming out of each cube.
Yeah I know, stupid idea of a test but that's what I wanted to do :P
I've also been playing with uScript Pro which is a visual scripting plugin. I bought this many months ago but not done much with it. It's actually very clever in the way it works and I can see a full game could be done with it without any coding knowledge what so ever.
As in the past I'm still not getting the Unity bug but I want to keep on with it as I'd just love to do an Oculus Go game.
I can see the appeal of Unity and I just need to leap in head first and learn it. I think to have any enjoyment, you need to dedicate time to it. It's not a pick up and go environment but it's well supported and I think it could be quite a good fun change from pure source code game making. I doubt that I'd move over to it permanently as I much prefer the pure source code approach.
One thing that does shock me is the file size of such basic apps!!! - A few spinning cubes, lights and particles should not be pushing 50MB surely?. Perhaps I'm missing some optimisations options somewhere but I think that's just a pure crazy output size for what it is.
Very early days so I can't condemn it yet :P
@ file size
It's the runtime...
In godot you do not have the classic "source to binary application" approach. They pack your stuff and add their runtime. Think even GameMaker or RPGMaker 2000 did that 15 years ago.
Their runtime is precompiled and contains all-you-can-do. In Godot you are able to compile your own "export targets" and you can disable some stuff you do not need (no 3D? disable, No XML support? disable). Nonetheless their runtimes keep pretty big (someone shrunk the 25MB android runtime to 7-8MB for a 2D-only-game).
For me that is still rather big. Also the WebAssembly export of Godot is 20 megs or so - albeit people try to calm down by stating that it compresses to 4 MB.
This is one of the most "argghhhh" aspects of Godot and Unity I dislike: filesize for simple tools.
If they wrote it with modules in mind, they could auto-detect whatever is used in the code, and only import these modules. But seems it is easier that way - as it allows easier multi-target-development (no need to compile "ios"-stuff on Windows, just put "ios runtime" + "scripts" + "assets" into one package). I think that is ok for "rapid prototyping" (up to no "compilation/packaging" times) but there should be some kind of "advanced build" which does then analyze your code, create all needed module-packages, ...).
@ VR
So next competition is "VR only"? :-)
I cannot imagine why "Qube" enjoys "cubes" spinning around. Why not just do a VR-Pac-Man-esque game - could be played as simple "FPMG" (First Pirson Maze Game) even without VR.
bye
Ron
Unity is a Tool and even though I don't like it myself I think it does its job well. That being said I do not think it is a tool for all game types. I think for level based games in a 3rd or first person view its a great tool because by the 2nd or third level you will have most of your prefabs made and its just a case of drag and drop to finish the game(imagine making an unreal tournament style game with unity, it would be easy a 2D turn based rpg like final fantasy on the other end would be difficult)
I intend to use Unity one day..... Assuming I ever finish my Grimoire of Worlds first......
On the subject of Unity, Humble Bundle have a Unity bundle this month.
Includes a few add ons and games as well as media that might be useful
https://www.humblebundle.com/games/unity-bundle?hmb_source=navbar&hmb_medium=product_tile&hmb_campaign=tile_index_1
:o
Might've given unity a brief go ages ago, I think this dinosaurs went passed the point of learning New languages.
About 4 years I used Unity to make a tech demo using the Oculus Rift and it was dead easy. There is a library included in the Unity installer that allows you to have a VRCamera Object to be used similiar to a camera. In other words if you replaced your main camera with this VRCamera thing you could be up and running in about 10 minutes like I was.
Unity is great for VR dev, not sure about Oculus Go though, although a programmer sat across from me a few weeks had one on his head and he also had the Unity window up, so he was certainly doing something in Unity with it.
Quote from: ENAY on September 12, 2018, 07:59:43
About 4 years I used Unity to make a tech demo using the Oculus Rift and it was dead easy. There is a library included in the Unity installer that allows you to have a VRCamera Object to be used similiar to a camera. In other words if you replaced your main camera with this VRCamera thing you could be up and running in about 10 minutes like I was.
Unity is great for VR dev, not sure about Oculus Go though, although a programmer sat across from me a few weeks had one on his head and he also had the Unity window up, so he was certainly doing something in Unity with it.
Oculus have provided the same plugin for the 'Go' as well. It supports all the Go's features ( 72hz refresh and Fixed Foveated rendering ).
Qubes progress with Unity.....
I've managed to grab a few more hours to play with Unity.
Most of the time has been looking through tutorials, the API and general Google based coding questions. My God! this thing needs major time investment to even consider yourself a beginner with Unity.
I was going to go down the path of visual scripting ( via a plugin ) and while it was fun it very quickly became evident that it just wasn't going to cut it for the way I like to work.
So with a terrified expression I dived into C#. Turns out the basics of C# are pretty easy to pick up. Most of my current stumbling blocks have been the Unity API rather than the C# language. I did find it odd that parts of C# are similar to PHP?
Unity is a beast of a system and one that needs time invested to learn but I want to make and sell an Oculus Go game so here I am ;D - No doubt by the time I'm a little more proficient with it then the Santa Cruz version will be out.
Thought I'd post a video of my current testing app. It's full of AAA graphics :P - The tank *cough* is controlled via C# script and has acceleration / deceleration. At the end of the video you'll see it farts balls out of it's side. These are supposed to shoot out from the front but I don't know why they are farting out the side instead. I'm sure I've done something super stupid and no doubt I'll give myself a good slap when I've figured it out.
I've already figured out how to get the tanks bullets to fire with velocity but in the video they just appear and drop. Very early days, lots of things to learn and lots of noob mistakes to make. I'll continue onwards with my AAA test to learn as I go along ;D
The video also shows me messing around with Unity's post processing shaders which is why it looks a little funky.
Nice tank ;D
Looks like you've made some neat progress though, even though you don't exactly seem like you're enjoying Unity.
QuoteNice tank ;D
Thanks, I spent ages looking at reference models so I'm glad the accuracy and attention to detail is appreciated :P
QuoteLooks like you've made some neat progress though, even though you don't exactly seem like you're enjoying Unity.
I am enjoying it, mostly ;) - It's a completely different way of working and it certainly has it's wacky ways about it. Lots and lots to learn yet but I like a challenge ;D
Seems you are feeling the same than I with Godot: you do not learn the coding language, but the API/provides classes/helpers/...
bye
Ron
Yay, got the firing sorted out \o/
Got a better understanding of prefabs and spawning / deleting them. It's also finally twigged about aspects of game objects ( position / rotation etc ) and manipulating their values in other objects attached scripts. It's a wacky way to me at the moment but it's starting to make *some* sense at long last.
Some hair pulling going on but a big relief when you hit play and the compiler doesn't spit out red errors at me ;D
Another thrilling video :
One thing I've been wondering is if it's better to have one empty GameObject with a "main" script that controls the whole game (and imports your game library etc.), or setting scripts in each individual GameObject.
There's good points for both?
Use multiple scripts - as you can "reuse" scripts then. If scripts get "compiled" then it will be faster on recompilation if only certain parts need to get recompiled.
It is the similar decision when using "import" instead of "include" in BlitzMax.
bye
Ron
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 (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.
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 :P
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 ?).
@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.
... on topic but slightly off topic ;D
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.
:o
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...
@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.
GPU Instancing. Cool beans 8)
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 ;D
Cool!
QuoteSir, the possibility of successfully navigating an asteroid field is approximately three thousand, seven hundred twenty to one!
Quote from: therevills on October 29, 2018, 00:29:08
Cool!
QuoteSir, 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.
Cool demo!
I did a 180 on Unity.
Using it daily now...
Did you make any progress with VR games, Qube?
I'd love to hear the tips and tricks you discover.
Quote from: Kryzon on November 29, 2018, 12:37:03
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 :)