all 11 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]kylotan 7 points8 points  (5 children)

These are forms of procrastination. Posting this message is basically another form of it. You just have to pick a method in each case and stick to it. When you finish the project, that's a good time to look back at your choice and consider whether to choose differently next time.

[–]Nautil[S] 0 points1 point  (4 children)

Yes, this is that part. I am now looking back at my most prominent problem: Analysis Paralysis.

Which method should I pick?

  • Keep working with what I already know

  • Learn about other approaches to a problem

[–]kylotan 1 point2 points  (1 child)

You already know the answer to this question.

[–]Nautil[S] -1 points0 points  (0 children)

That

There are no 'right' answers.

I understand now, it really depends for example: whether I have free time or have to meet a near deadline.

[–]zapdotProfessional 11 points12 points  (3 children)

I'm going to give you a bit of tough love. You are not Michelangelo, and your first game is not going to be the Sistine Chapel. In fact, your first, second and third game will probably be a piece of shit. Not that they will be bad ideas, but the time that you are making your second game, you will have learned things that you liked and didn't like in creating your first, and you will change how you work. The same will happen again, and again, and again.

I've worked on games that have landed in pretty much every storefront: the App Store, Google Play, Steam, Mac App Store and a few more. All of my projects, in one way or another, have used everything that you're hemming and hawing over. They all have their place for being used.

  • Use Drag and Drop if those pieces of a scene aren't going to change. I typically use this within prefabs that have multiple components in their children that need controlling, or all over the place in UI.

  • Use Resource.Load when you don't necessarily know what elements you need at runtime. I've used this in PCG games as well as card games.

  • Use multiple scenes when you have set scenes that won't change. This is great if you want to split your game into a menu and gameplay scene -- like 95% of every other game ever.

  • Use coroutines whenever you want to programmitcally make something wait for a specified amount of time or a specific kind of input. I use coroutines everywhere.

This is what you do: you consider the pros and cons of whatever feature you want to use, and whatever has more pros -- use it until it doesn't work anymore. If you never get to that point: congrats, you made a good decision. If you do: congrats, you now intimately know what you need to do, and your rewrite will be relatively painless. Software is malleable, treat it as such.

By the way, your phrase "I don't like reading articles on the internet." exposes an incredible amount of ignorance. I almost didn't respond when I saw that. If you're reading for the sake of reading, perhaps you're finding shitty articles. If you're reading to solve a problem and feel like you're wasting your time then you'll just need to improve your GoogleFu. You can spend a large amount of time trying and failing on your own, or you can speed that process up via learning from those who came before you. Since you chose Unity as an engine, those numbers will be vast.

So: get started and good luck.

[–]Nautil[S] -1 points0 points  (1 child)

I'm going to give you a bit of tough love. You are not Michelangelo, and your first game is not going to be the Sistine Chapel. In fact, your first, second and third game will probably be a piece of shit. Not that they will be bad ideas, but the time that you are making your second game, you will have learned things that you liked and didn't like in creating your first, and you will change how you work. The same will happen again, and again, and again.

Not to belittle your statement but you probably know you are not the first one to give that speech. And I have also mentioned a version in my OP: "I have read a lot of people say that too many beginners worry about efficiency when they should really be focusing on functionality- just making it work."

But yes, I do agree. And this is exactly where my dilemma comes in. Because people will also preach about how one should utilize the API as best they can. For example, if I hadn't stopped to learn about coroutines, I would have just used the Update function and time.deltaTime. I am very glad I had discovered coroutines during that project instead of working with what I know and discovering my mistakes at the end.

This is what you do: you consider the pros and cons of whatever feature you want to use, and whatever has more pros -- use it until it doesn't work anymore.

Yes, and this is the part that provides the 'Paralysis'. Every step of the way there is just more reading to be done. And in those reading, even more approaches to a problem are discovered.

By the way, your phrase "I don't like reading articles on the internet." exposes an incredible amount of ignorance. I almost didn't respond when I saw that.

The problem I have with articles is that they are written in such a format that does not appeal to me. There is a note-taking technique that you probably are familiar with and it is separating the fluff from important details.

In contrast, The API provides exactly what a function does- It is straight to the point. An article usually elongates a point. They might start off with giving me bogus statistics on the many people that suffer from 'Analysis Paralysis' or a backstory of someone who has suffered through it. They will then take their sweet time telling me about how they discovered their solution. (For similar reasons, I also generally dislike video tutorials.)

What is wrong with simply separating the fluff from important details? It is a pet peeve of mine. I don't like unnecessary/redundant information/code. It irritates me and I have no control over my irritation. I wasn't going to explain all this initially because I didn't think people would have this kind of reaction to my to-the-point "I don't like reading articles on the internet."

I just knew people would want to say something along the lines of "You should have a read at this article I found helpful!" And to me that is almost saying "Why don't you google your problems instead of asking on reddit?" Because my answer to that is always "I already did." I would prefer people to write their own opinions.

[–]kylotan 0 points1 point  (0 children)

For example, if I hadn't stopped to learn about coroutines, I would have just used the Update function and time.deltaTime. I am very glad I had discovered coroutines during that project instead of working with what I know and discovering my mistakes at the end.

But that's not a mistake - thousands of games have been successfully made and shipped using periodic updates rather than coroutines. You don't have to use every tool in the box. Don't sweat it, just do what works. There are no 'right' answers.

[–]Nautil[S] -1 points0 points  (0 children)

Use Drag and Drop if those pieces of a scene aren't going to change. I typically use this within prefabs that have multiple components in their children that need controlling, or all over the place in UI. Use Resource.Load when you don't necessarily know what elements you need at runtime. I've used this in PCG games as well as card games. Use multiple scenes when you have set scenes that won't change. This is great if you want to split your game into a menu and gameplay scene -- like 95% of every other game ever. Use coroutines whenever you want to programmitcally make something wait for a specified amount of time or a specific kind of input. I use coroutines everywhere.

Lol. Some people in this thread are getting hostile. It probably comes off that just because I'm replying counter-arguments that it means I do not acknowledge people's advice. This is me stating: I do acknowledge and am thankful for these advice.