Tomi on 10/10/2020 at 20:27
I wasn't sure whether I should post this under the "What are you making?" thread or not, but I know that there are some Unity wizards here on TTLG who might want to share their experiences and tips, so a dedicated thread might not be a terrible idea.
So I wanted to ask you guys for some useful tips for a beginner! You see, I've got a bunch of very vague game ideas - nothing concrete at all - but making a game has always been a bit of a dream of mine. I thought that Unity might be a good choice to start with, but the problem is that I don't really even know where to start. I have a little experience with Java from years ago, and I'm really not an expert programmer or anything, but I've figured that with Unity I could still be able to create something, and with a little encouragement I might even get interested in coding again.
I've seen a bunch of guides on the internet - I even got myself something called "The Ultimate Guide to Game Development with Unity 2019" as it had got some good reviews and it promised to cover the basics. However, I also read that some parts of that guide were originally written with Unity 2018 in mind, and even some of the updated parts aren't totally up to date with the newest version (2020?) of Unity. :confused: Are the differences between the different versions really that big? Obviously I don't want to spend my time and energy on learning some wrong or outdated techniques.
Perhaps I should just get the software and see what happens when I dabble around with things, but right now the whole concept of Unity feels a bit overwhelming to me. Question for the Unity veterans amongst us: can you remember what your first steps in the world of Unity were like? :D Do/did you find the interface intuitive to use? For me the amount of dropdown menus and everything looks a bit scary, but then again so does DromEd for example, and I managed to create a little bit something with it.
Judith on 10/10/2020 at 21:16
As a content creator and mostly Unreal user, I hated the clunky navigation and axes messed up for no particular reason (Z is Y, and X is Z so you have to set up custom pivot for a model every time before export). The standard shader is also a bit odd, it has weird slots and naming instead of typical PBR roughness / metallic setup. But there's a more familiar mode (I think it was called Autodesk material or something), and the FBX support is very good. I used FBX game exporter to update models directly from scene in modelling app, and once I alt tabbed to Unity, they were updated in a sec. Same goes for any textures and code. You can use VS code for that, and the setup is really straightforward.
IMO the main advantage is that Unity is lightweight and fairly fast, you can easily make simple stuff for it on an older laptop. IMO Unreal always had much better UI and navigation, but it's also kind of a bloatware at this point (it has tons of subsystems, so it needs a fast workstation).
Pyrian on 10/10/2020 at 21:31
I started with the Roll-a-Ball tutorial, didn't take me long to get up and running, but then I'm an experienced professional programmer.
I find Unity kind of... Finicky? Like, there's a lot of weird bits and strange decisions and stuff to keep track of. But there are extensive tutorials and a lot of people using it to help.
Really, just do one or more beginner tutorials that are as similar to what you want to work on as available.
Yakoob on 11/10/2020 at 00:49
Definitely +1 to Pyrian's note about Unity being finicky and having a lot of strange "gotchas" (especially later on if you start digging into deep profiling or console porting). I also wouldn't worry too much about about Unity 2019 vs 2020 tutorials as there are content updates all the time and whatever you learn will likely be changing anyway - just get a solid baseline of understanding how the engine works and then go read official Unity docs for the most up-to-date features.
(Odds are half the new versions' bell and whistles are half incomplete, and potentially will ALWAYS be half incomplete. I wouldn't bet my money on using anything new just yet, unless just for dicking around. Unity has a bit of a reputation about introducing new features in lieu of polishing/stabilizing existing ones. Case in point: I've recently been playing with the Terrain system which has been in Unity forever and, while it gets the job done, it is just awful to work with)
One thing the Unity does have going for it is it's sheer flexibility - you can really do A LOT with the engine and create your own editor tools. Heck, odds are somebody already did it, so looking through the Unity Asset store can save you boatloads of time. Tho be careful to make sure whatever coding assets you get are a) recently updated and b) have responsive devs; again, with how fast Unity changes, it's not uncommon for older assets to be flatout broken (or just be awful in the first place, coded by a lot of other Unity newbies). So you'll need to do some research, but the more established and well supported assets (like Odin editor extensions, ProBuilder/Bolt which have been acquired by Unity, Playmaker etc.) are really solid
(Art assets are far more forgiving and usually age pretty well)
henke on 11/10/2020 at 05:51
Yayyyyy, Tomi is getting into gamedev! :D
Learning Unity is the same as learning anything, the hardest part is staying commited. For me, making a routine out of it helped. I woved that I would spend at least 1 hour every evening, Monday to Thursday, learning Unity or making something in it. I downloaded a Punch Clock app and started punching in around 18:00 every night. Tho when I got to the chapter on Rigidbodies and Joint physics I gotta kinda distracted, trying to attach 2 long poles at either side of a capsule and trying to make it walk around, before ya know it I'd made some kinda... fella on stilts? Anyway, I'm gonna second Pyrian's suggestion of doing the official tutorials at (
https://learn.unity.com/) Maybe start with (
https://learn.unity.com/tutorial/navigation-in-the-editor-2019-3) Navigation in the Editor and then work from there.
And don't worry too much about versions. I'm using Unity 2019.4.4f1 at the moment. I'd say just get the latest (
https://unity3d.com/unity/qa/lts-releases) 2019 LTS version. LTS stands for Long Term Support, which means everything should be hunky-dory if you wanna return to the project a few years down the line.
Tomi on 11/10/2020 at 22:17
Quote Posted by icemann
I'd recommend
Game Maker.
Ah, I always thought that Game Maker is a bit of a toy that can't be used for anything slightly more complicated, but looks like it's been used for a bunch of pretty good games! I don't necessarily have anything too complicated in my mind, but I think I'll want to check out Unity first. In a way I'm looking forward to a bit of coding, just to prove myself that I
can do it. :D There doesn't seem to be a free version of Game Maker either, not even a free trial. Thanks for the suggestion though!
Tomi on 11/10/2020 at 23:03
Okay, I've now taken my first steps in the world of Unity. It still does look a bit scary, but I've already learned a thing or two. I've been getting used to the interface, placed some objects and assigned attributes to them, played around with them a bit, and even made a script that makes a cube move to the right on the screen! :p Doesn't get any more basic than that, but it's been interesting so far and quite fun too.
So far I've gathered that Unity is capable of pretty much anything, but the fact that you can import certain ready-made things makes things much easier for the developer. Is it common practice that game devs import things from the asset store or whatever, and just tweak them to their liking? I mean, if I wanted to make some sort of a game where the player throws a bouncy ball against the wall, could I just simply import some set of physics, and then play around with the attributes to make everything feel right, without having to code in the laws of the gravity, collision detection, and so on?
Henke (or anyone else who uses Unity), what is it in the development of Stilt Fella that took the most time and effort? About how much time have you spent on writing actual code compared to making your magic in the... uh... editor?
Nameless Voice on 12/10/2020 at 00:43
One of the advantages of using a popular game engine is that a lot of things have already been done for you, either in the engine itself, or by third parties through its related marketplace, so you don't have to re-invent the wheel.
There's no reason why you shouldn't make use of third-party content to help you, especially in areas that you're not that skilled in.
The hard part is finding the good ones.
I'm not that familiar with Unity specifically, so I'm talking generally here.
Pyrian on 12/10/2020 at 01:54
Quote Posted by Tomi
I mean, if I wanted to make some sort of a game where the player throws a bouncy ball against the wall, could I just simply import some set of physics, and then play around with the attributes to make everything feel right, without having to code in the laws of the gravity, collision detection, and so on?
Physics is built in, and works great for most relevant applications. A good rule of thumb I promote is that if you're using physics, stick with physics, and do every interaction with forces and joints. The interface between hard-coded positions and physics is the source of most "physics" glitches, as it treats such interference as "physics, except with unlimited force" and putting infinities into physics calculations is just begging for some random piece to rocket off into the sunset.
Renzatic on 12/10/2020 at 05:07
I tried out using Unreal for scene creation here recently. It was strange, because no matter what I tried, I could not get rid of these spludgy artifacts on my imported models when I went to bake my lighting. I tried arranging my shadow UVs 50 different ways, and went through every bake quality option, but those artifacts were still there. I spent hours looking for a solution, but never could find one.
Tried importing my models in Unity's High Definition Render Pipeline, and they rendered perfectly, no shadow bake errors whatsoever.
...go fig.
