|
I had no real idea where else to ask this, but lately I've been wanting to get into Unity engine stuff and as is the case with idea guys, I don't know what I'm doing. That's ok though, I actually wanna learn. Problem is, the tutorials I've gone over all seem to assume some sort of familiarity with Unity's C# scripting and, as I stated, I don't know what I'm doing. I was able to get what little code I did write functioning, but I didn't understand any of the logic behind the code or just exactly what the functions I was writing were doing precisely. I don't wanna learn that way, I wanna actually understand what I'm doing. So anyway, I assume plenty people that post in this thread use Unity and plenty of you were once in my position. How do I start? I'm not looking to make the next big MMO and design the logo, I just wanna learn.
|
#
?
Dec 6, 2014 12:12
|
|
|
|
| # ? May 13, 2024 03:07 |
|
|
If you want to learn to program and currently know absolutely nothing about programming, it'd probably be easier to start by just focusing on the programming aspect, and ignoring games for the moment. Once you understand basic stuff like variables, functions, and loops, you'll probably find it a lot easier to get started with making things work in Unity. There are approximately a trillion "learn to program" guides out there in whatever language you want. It doesn't have to be C#, though it might as well be. Most languages commonly used these days are similar in their basic aspects, so knowledge you gain in one language will transfer to others, modulo differences in syntax.
|
|
#
?
Dec 6, 2014 12:51
|
|
|
TooMuchAbstraction posted:If you want to learn to program and currently know absolutely nothing about programming, it'd probably be easier to start by just focusing on the programming aspect, and ignoring games for the moment. Once you understand basic stuff like variables, functions, and loops, you'll probably find it a lot easier to get started with making things work in Unity. There are approximately a trillion "learn to program" guides out there in whatever language you want. It doesn't have to be C#, though it might as well be. Most languages commonly used these days are similar in their basic aspects, so knowledge you gain in one language will transfer to others, modulo differences in syntax. Well I'd be learning programming in order to make games, why not learn practically? Something like a beginner's guide to programming based in Unity or something. I've heard stories about developers making a game and learning to program alongside making it, which is something I thought would be a good fit for me. I've previously quite successfully taught myself how to play several instruments and some intermediate level audio engineering stuff, so I'm fairly adept at teaching myself poo poo. The simple games the Unity tutorials teach you to make are fine, and the programming they require you to do seems fairly basic, the only problem is the programming itself isn't explained or elaborated on. If those tutorials didn't assume I knew how to script in Unity they'd be perfect.
|
|
#
?
Dec 6, 2014 14:34
|
|
|
cat doter posted:Well I'd be learning programming in order to make games, why not learn practically? Something like a beginner's guide to programming based in Unity or something. I've heard stories about developers making a game and learning to program alongside making it, which is something I thought would be a good fit for me. I've previously quite successfully taught myself how to play several instruments and some intermediate level audio engineering stuff, so I'm fairly adept at teaching myself poo poo. I've been having the same problem with those tutorials. Since I've been trying to crash course my way through learning Unity, I've tried most every tutorial I could come across. With that said, it will be easier to understand why they do what they do in those tutorials if you watch their documentation overview videos first. There are several videos of theirs to take you through the basic concepts of scripting, and while at first it's overwhelming, you'll pick it up after being exposed to it for a while. I would also recommend watching Brackeys, a pretty good and pretty baby steps style YouTube tutorial guy, who covers both basic programming and unity specific stuff in his videos. Also, if you wanna push yourself a little at a time to try to test your brain on the unity full game tutorials, try making stretch goals for yourself to accomplish, such as adding health kit pickups to the survival shooter, or even camera controls for the ball rolling game. Seems to have been helping me so far.
|
|
#
?
Dec 6, 2014 14:54
|
|
|
cat doter posted:Well I'd be learning programming in order to make games, why not learn practically? Something like a beginner's guide to programming based in Unity or something. I've heard stories about developers making a game and learning to program alongside making it, which is something I thought would be a good fit for me. I've previously quite successfully taught myself how to play several instruments and some intermediate level audio engineering stuff, so I'm fairly adept at teaching myself poo poo. If you can find a tutorial for programming in C# based in Unity, great, but it sounds like you can't. There are dozens of tutorials floating out there for learning how to program in any given language and it's going to be the fastest way to figure out how it all works. It's pretty common to learn how to program while making a game (half of my entry-level CS course assignments were making games), but you need the basics first. You don't need to take a detour from game-making for a long time, either, an afternoon going through a beginner programming tutorial and you'll probably have enough of a base to start learning by doing.
|
|
#
?
Dec 6, 2014 14:57
|
|
|
Alrighty, I'll start with the programming specific stuff, seems the smartest way to do it. Is learning C# specifically a good way to go about it since that's one of the languages unity's scripting uses? Or should I learn something else and expand on C# stuff once I know enough? I don't really know much about programming language differences.
|
|
#
?
Dec 6, 2014 15:33
|
|
|
cat doter posted:Alrighty, I'll start with the programming specific stuff, seems the smartest way to do it. Is learning C# specifically a good way to go about it since that's one of the languages unity's scripting uses? Or should I learn something else and expand on C# stuff once I know enough? I don't really know much about programming language differences. C# is just as good as any and it'll be the most useful since you'll start learning the syntax as well.
|
|
#
?
Dec 6, 2014 15:47
|
|
|
Screenshot Saturday! Putting together a character creation screen, still gotta create the stats/attribute page down and get the colour/tint page in there. But all in all I'm happy with a little bit of personal customization. (Naming the character doesn't work on pc)
|
|
#
?
Dec 6, 2014 16:41
|
|
|
Oh man I gotta put one of these together some day.soon. Lookin good!
|
|
#
?
Dec 6, 2014 16:46
|
|
|
cat doter posted:So anyway, I assume plenty people that post in this thread use Unity and plenty of you were once in my position. How do I start? I'm not looking to make the next big MMO and design the logo, I just wanna learn. Well, I guess the big question is: do you know the basics of how programming works, especially in terms of data structures (functions, etc.)? That might be the best place to get started, regardless of what sort of language you're using. Programming can seem like a daunting task until you understand the essential building blocks of how code works. Once I figured out the general logic of coding (and I'm a total idiot when it comes to formal logic and mathematical functions), it became a thousand time easier, with the major difficulty then becoming finding creative solutions for problems and learning the actual language (its inbuilt functions, mostly). Vermain fucked around with this message at 19:11 on Dec 6, 2014 |
|
#
?
Dec 6, 2014 17:03
|
|
|
DeathBySpoon posted:READY Awesome, I used to play this lawn mowing game when I was a kid and I'd totally play one now, too. https://www.youtube.com/watch?v=ae5mJ9wI5aA Played a bit, it is hard a poo poo to control but I got the hang of it eventually. taqueso fucked around with this message at 19:02 on Dec 6, 2014 |
|
#
?
Dec 6, 2014 18:59
|
|
|
DeathBySpoon posted:READY Can you reskin this to a parking lot and give bonus points for hitting fat rednecks riding on Rascal scooters? 
|
|
#
?
Dec 6, 2014 22:02
|
|
|
|
|
#
?
Dec 6, 2014 22:08
|
|
|
DeathBySpoon posted:READY tehsid posted:Have a random event where a black dog chases the mower around and you have to not hit is because then you simulate my life once a month. https://www.youtube.com/watch?v=rluREbq7eMs
|
|
#
?
Dec 6, 2014 22:09
|
|
|
Swearing over destroying plants is really funny
|
|
#
?
Dec 6, 2014 22:53
|
|
|
GOTY.
|
|
#
?
Dec 6, 2014 22:56
|
|
|
 This is fantastic.
|
|
#
?
Dec 6, 2014 23:01
|
|
|
cat doter posted:Alrighty, I'll start with the programming specific stuff, seems the smartest way to do it. Is learning C# specifically a good way to go about it since that's one of the languages unity's scripting uses? Or should I learn something else and expand on C# stuff once I know enough? I don't really know much about programming language differences. C# is actually a perfect language to start with. It lacks the finnicky, weird poo poo that something like C++ has that makes it hard to learn. It's also a rather popular language and if you need to you can move from C# to other C or C-like languages rather easily. It's also probably the best language to learn in Unity so if you want to make games it's a fine choice. But yeah, like was said, don't start with games. Games are stupidly complex and not a good place to start. Just start by making a console application print "Hello world!" and go from there. Write a program that lets you put in a name and then says "Hello, *name*!" If you genuinely want to learn programming do it in baby steps. Also don't feel like an idiot if it's slow going. Learning to program takes for freaking ever and programming just never gets easy. Programming is awesome, though. Writing code is seriously one of my favorite things to do. Anyway, C# is actually the language that was used in most of the college CS courses I've taken. The other thing is don't obsess too much about languages. There are a lot of programming skills that are not language-specific. There are differences but you'll find as you learn more about programming that picking up a new language is actually not all that hard once you've gotten experienced. The other thing I'll recommend is that you start studying logic and math, especially boolean logic. The more you know about those subjects the better you'll get at programming in general.
|
|
#
?
Dec 6, 2014 23:01
|
|
|
ToxicSlurpee posted:Learning to program takes for freaking ever and programming just never gets easy. Well, to be more accurate, the more you learn to do, the more ambitious your goals become. The problems that used to make me tear my hair out are now piss-easy, but that makes them less interesting to work on.The endorphin rush you get from having your program work never gets old though.
|
|
#
?
Dec 6, 2014 23:14
|
|
|
Yeah you hit F5 and the game loads without errors and you try out that thing you planned up and it works even though you know it kind of shouldn't and you morph into Boris from Goldeneye
|
|
#
?
Dec 7, 2014 01:28
|
|
|
Then two months later you find the bug.
|
|
#
?
Dec 7, 2014 01:57
|
|
|
TooMuchAbstraction posted:Well, to be more accurate, the more you learn to do, the more ambitious your goals become. I get it, that and there is more to computer science than any one person can ever know. That's honestly part of why I like programming so much. There is always something new to learn. Thing is, though, how often do you end up coding the same thing more than once? I think that's why the phrase "software engineering" exists. Think of bridges; you can know all the skills needed to build a bridge but every new location has its own challenges and no two locations are the same. Every program is different. Yeah the techniques are often the same but all the things are different. But yeah, I'll definitely agree with that. After all the long hours of toil, frustrations, and bug fixing are done and you press "build" and you have a program that works and you can point to it and say "yeah, I made that..." One of the best feelings, to be sure.
|
|
#
?
Dec 7, 2014 02:02
|
|
|
Shoehead posted:Yeah you hit F5 and the game loads without errors and you try out that thing you planned up and it works even though you know it kind of shouldn't and you morph into Boris from Goldeneye
|
|
#
?
Dec 7, 2014 02:37
|
|
|
Shoehead posted:Yeah you hit F5 and the game loads without errors and you try out that thing you planned up and it works even though you know it kind of shouldn't and you morph into Boris from Goldeneye This is basically my entire limited and self-taught programming experience so far. I write code, I go "heck I'll just run it and see where it breaks down, then fix it." Then I'm completely baffled when I get no compiler errors.
|
|
#
?
Dec 7, 2014 03:45
|
|
|
MockingQuantum posted:This is basically my entire limited and self-taught programming experience so far. I write code, I go "heck I'll just run it and see where it breaks down, then fix it." I'm almost done with a computer science degree and I still code like that. Professors admit to still coding like that. And yeah, one thing we always got told is "never expect your code to work right the first time it runs." When it actually does I'm freaking out and hunting for bugs because I JUST KNOW they're in there. But sometimes...it all just works.
|
|
#
?
Dec 7, 2014 03:48
|
|
|
Hell, even my limited maybe 30 lines of code experience so far has been "I dunno if this works, just hit F5". The first couple of times it gave me errors I didn't understand so I just deleted it all and wrote it from scratch only to hit F5 again and it worked perfectly. Good to know it'll probably always be like that. edit: Oh, since I already have some experience as an audio guy, is anyone here an audio programmer or know someone that is? Is that something that's hard to get into? I've been thinking about going down that road even before I decided to learn Unity.
|
|
#
?
Dec 7, 2014 05:07
|
|
|
I tried learning a little audio programming earlier this year. It's not super hard to get the basics of but it has a pretty steep learning curve after that. At least if you suck at math like I do. Most of the info and articles I could find online, past the absolute basics at least, talked about audio programming in dense math jargon that would have taken me way too long to translate into something I could understand so I mostly gave up. This tutorial: part 1, 2, 3, 4. Is what I started with. I feel it's a pretty good introduction.
|
|
#
?
Dec 7, 2014 06:08
|
|
|
cat doter posted:Hell, even my limited maybe 30 lines of code experience so far has been "I dunno if this works, just hit F5". The first couple of times it gave me errors I didn't understand so I just deleted it all and wrote it from scratch only to hit F5 again and it worked perfectly. Good to know it'll probably always be like that. Yeah never be afraid to just mash F5 at random times to see if your program works or not. Running your code even if you know it's probably bad and won't work is a good idea in that sometimes you'll see exactly why it doesn't work after watching it run. Or fail to, be that the case. I'll let you in on another secret; all code is terrible. All of it. It doesn't need to be good it just need to work.
|
|
#
?
Dec 7, 2014 06:58
|
|
|
ToxicSlurpee posted:Yeah never be afraid to just mash F5 at random times to see if your program works or not. Running your code even if you know it's probably bad and won't work is a good idea in that sometimes you'll see exactly why it doesn't work after watching it run. Or fail to, be that the case. I remember hearing Jon Blow talk about this, he said something like "optimised code is mostly a myth" and that people spend years researching code that's faster than the easier way to do it only to come up with something that's maybe a few percentage points faster at the cost of massive complexity. His argument was writing functional code faster is more important than complex code that's faster. Good code is code you can write fast, basically. If that's all true then that's great.
|
|
#
?
Dec 7, 2014 07:39
|
|
|
ToxicSlurpee posted:I'm almost done with a computer science degree and I still code like that. Professors admit to still coding like that. And yeah, one thing we always got told is "never expect your code to work right the first time it runs." When it actually does I'm freaking out and hunting for bugs because I JUST KNOW they're in there. I was tutoring a course in software engineering last year. I was amazed by how many people would show me a block of code and ask if it was right, and I'd say, 'well, does it work?' To which they would reply, 'I dunno.' They hadn't run their code. They hadn't even tried to run the busted stuff. I think they just thought they'd be marked on code workmanship or something. No-one marking that course read more than three lines of anyone's code in any level of depth, but the students were still in the comp sci mode of making sure it was perfect before hitting the button. It's not comp sci. We don't mark on code perfection, we mark on making it work. Hit the loving button, people. See what happens. Break the code. Understand how you broke it and how that part influences other parts. Then make sure that part won't break that way. Repeat until you understand enough of the code base to do what you need to do. If you don't understand it, mash the run key and keep tweaking parts until you do. E: Also yes, the freakiest thing in the world is to code up a complex part, hit the run key, make the part do the thing and see it work perfectly. Because you know that it shouldn't. You know that was the simplest, most obvious solution in the world and that it shouldn't have worked. You get paranoid. You check the code. It should have broken the code here and- wait, no, that would work, wouldn't it- well it shouldn't have rendered properly because- oh, wait, no, that makes total sense- It takes a long time to realise that, just maybe, it worked the first time because, just maybe, you're not total shite at this. Somfin fucked around with this message at 12:54 on Dec 7, 2014 |
|
#
?
Dec 7, 2014 12:49
|
|
|
Somfin posted:It takes a long time to realise that, just maybe, it worked the first time because, just maybe, you're not total shite at this.
|
|
#
?
Dec 7, 2014 13:59
|
|
|
Welcome to the Imposter Syndrome Megathread!
|
|
#
?
Dec 7, 2014 14:14
|
|
|
cat doter posted:I remember hearing Jon Blow talk about this, he said something like "optimised code is mostly a myth" and that people spend years researching code that's faster than the easier way to do it only to come up with something that's maybe a few percentage points faster at the cost of massive complexity. His argument was writing functional code faster is more important than complex code that's faster. Good code is code you can write fast, basically. If that's all true then that's great. Rule 1 of programming: if it doesn't perform the stated task, then it is useless. Rule 2 of programming: all code is legacy code (a.k.a. "try to write in such a way that you'll understand the code two weeks later") Not to say that having good design chops is useless. If you're writing code that you know you're going to want to extend later, then writing it in a way that's incredibly specific to the thing you're doing right now is a waste of time -- you'll have to tear it all down when it comes time to extend it. One of the harder design skills is recognizing when you need to stop and come up with a good design, and when it's okay to just "code through it" with a simple, possibly dirty solution.
|
|
#
?
Dec 7, 2014 14:49
|
|
|
The Kins posted:Welcome to the Imposter Syndrome Megathread! New thread title spotted
|
|
#
?
Dec 7, 2014 15:07
|
|
|
cat doter posted:I remember hearing Jon Blow talk about this, he said something like "optimised code is mostly a myth" and that people spend years researching code that's faster than the easier way to do it only to come up with something that's maybe a few percentage points faster at the cost of massive complexity. His argument was writing functional code faster is more important than complex code that's faster. Good code is code you can write fast, basically. If that's all true then that's great. Yeah programming is ultimately a skill of tradeoffs. In an ideal world we would have unlimited time to test for every possible gently caress up. This is not an ideal world. The other snag is that sometimes a significantly more efficient algorithm is thoroughly irrelevant. If you write a program that uses 1% of a computer's processing power then it's not going to do you much good to cut its resource use in half. Plus basically all code can always be better, somehow, but you don't have infinite time to constantly make stuff better. An easy trap to fall into is related to feature creep and that is optimization creep. Sometimes it's a good idea to make stuff better, sometimes it isn't. Other times you break everything by removing that bizarre but functional cobbled together disgusting hack you slapped in. The only thing that really matter when it comes to a program is that it runs and does what it's supposed without crashing at an unacceptable frequency. What "unacceptable" means varies by what type of program it is. Sometimes you have a deadline looming and your slapped together mess that functions 99% of the time is good enough so you commit that and hand it in. Somfin posted:It takes a long time to realise that, just maybe, it worked the first time because, just maybe, you're not total shite at this. The times that I think "wow I'm a good programmer!" are the times that I let my guard down and gently caress everything up horribly. Constantly saying to myself "I am a bad programmer that breaks literally everything" makes me more inclined to code defensively. And let me tell you that has saved my approximately a billion headaches.
|
|
#
?
Dec 7, 2014 16:05
|
|
|
The first rule of optimization is don't. Unless you can improve your function asymptotically (which means improving the rate at which the function time grows with the size of the input. If your function is in n2 time, when given a list of 1000 things it will take 1 million "time" while in an n function it will take 1000 "time"), it's not worth the headache.
|
|
#
?
Dec 7, 2014 16:20
|
|
|
That being said, having code that's easy to change and relatively dynamic (such that you don't have repeats of basic functions like menus) will make your life significantly easier when trying to bugsquash or when adding in new features. "Optimization" is a bit of a red herring, but having easy-to-read code that you don't have struggle with to try and edit is never a bad thing.
|
|
#
?
Dec 7, 2014 16:53
|
|
|
Hey guys. So, me and a small crew of 2 people have started working on this classic 2d point n click adventure game, and I've hit a bitch of a visual roadblock. We're fortunate enough to use cintiq 21s at work, and I have a smaller 12wx at home borrowed from work, since I do a lot of the work from home, too. My problem is EVERY goddamned monitor shows completely different things values and color-wise and it's driving me nuts. Here'a sample of a background wip (apologies if it's huge, I don't know how to thumbnail the thing):  At the moment I'm seeing decent blacks and overall values but I really have no idea whether you guys are seeing what I want (nice blacks, hazy evening atmosphere but not exaggerated darkness) or or it's just my stupid monitors lying to my face. I'm handing over assets to our programmer that are dark and moody on my screens, and they look absolutely washed up and weak on his... I could just try and look at them on every monitor in the firm but where would that get me, really? It's known that big cintiqs overaturate everything, so when you drag the image to a normal monitor, the results are, ahem, underwhelming. Problem is, my work monitor is one of those watch-movies-on-it, so the difference ain't that big between them. My home monitor shows everything in a drab desaturated fashion (it's an ancient 2007 Philips, my guess is it's dying), aaand the small cinq shows everything SO god damned dark that images I make at work are barely visible on it. And, oh yeah, you CAN'T adjust anything on the small cinq, it only has a power on/off button. Very long story short - is there some kind of standard or reference or at least a predef in photoshop or some kind of way to correctly calibrate and align all these damned things? Or some kind of standard I should be taking into consideration so that everyone would be seeing at least approximately what I'm seeing? Because results are tragic to risible whenever I view my work on different monitors - and I'm aware that's to be expected, but not with such ridiculous results as I'm experiencing. Sorry about the convoluted wall of text, and thanks in advance to anyone who had the patience to read all that and who could enlighten me.
|
|
#
?
Dec 7, 2014 17:07
|
|
|
I just checked it on two monitors, ASUS and Dell, looks fine to me on both
|
|
#
?
Dec 7, 2014 17:24
|
|
|
|
| # ? May 13, 2024 03:07 |
|
|
Mr Underhill posted:
That art reads quite well, it looks great. What you need to do is buy a quality monitor and a colour calibration chart. Calibrate the monitor and ideally run it alongside your cintiq so that you can reference as art is made. To be honest, you don't even need that good of a rig. Get a half decent refurbished monitor (it's amazing what a hundred bucks can buy these days) and run it through Windows Display Calibration. It might only get you to 90% perfection, but frankly that's gonna be way ahead of what most users will be viewing your game on.
|
|
#
?
Dec 7, 2014 17:46
|
|
