Okay. This is a tall order, especially if you want things to stay in layperson terms.
I’ll take your three questions one at a time:
How do I figure out what pieces I need, then how to apply them?
This is the one that’s really hard to understand. Your best bet is recursive searches. That is: a series of searches where the outcome of each search is to identify a better set of search terms.
For things like programming-language syntax and basic programming, you can use a tool like hackerrank.com. They’ll put you through a series of coding challenges, starting with the iconic “Hello, World” exercise and, game-by-game walk you through to some degree of programming competency.
For the .NET framework (the broad system of tools defined by Microsoft’s .NET platform, much of which is available in Unity), you can use msdn.microsoft.com (the Microsoft Developer Network, basically it has evolved into Microsoft’s documentation suite for developers). For the Unity framework (the special stuff, which is not a part of .NET that Unity offers to programmers), you can use docs.unity3d.com. That said, Google’s search is better and broader if you don’t know what you seek. Just ask your question, learn a little bit of jargon, ask a better question, learn a little bit of jargon, et cetera.
How should I think, logically, to accomplish these tasks?
Design Patterns help people think about their problems in a design-friendly way. The problem is that most of the books on Design Patterns are pretty technically focused. You might want to lay some groundwork with Alexander’s A Timeless Way of Building while you teach yourself the basics of coding. Then, once you understand things like classes, methods, et cetera, you’ll have a nice foundation of cross-domain knowledge about design that can be applied to learning Design Patterns as we think of them in the software development industry.
Design Patterns give you good analytical tools for decomposing large, intractable-seeming problems into many small ones. I still think that ATDD is a great way to focus your efforts, though, because it drives your whole design and development process from the outcomes you want to see rather than from technical details.
So, you start by defining an high-level behavior, such as the following (my best guess at your first requirement):
Scenario: Keep an object's position fixed r
Given a phone with a camera and a gyroscope
And an augmented-reality object (O) visible on the camera
And O's "up" is visually aligned with the user's up
And O is being touched
When the phone is rotated 90-degrees clockwise
Then O's "up" is visually aligned with the user's right
From that, you can identify a litany of other “sub” behaviors, by asking yourself what you need to do to make it happen:
- How do I know that an object is visible on the camera?
- How do I detect the rotation?
- How do I rotate the object?
- How do I detect the object is being touched?
- How do I stop rotating the object?
- et cetera
Each of these things will drive your analysis and decomposition efforts further and help you organize what needs to be done while defining how you will tell that it actually is done.
Keep in mind that it doesn’t matter if that’s the right definition of your requirement. It’s just an example of a non-controversial definition of a behavior: everyone who sees it at any point in time is going to interpret the behavior of a system to either match that description or violate it the same way.
So, as a developer, you need to familiarize yourself with Design Patterns (along with the basics like syntax and code quality) and as a product designer, you need to familiarize yourself with ATDD. As I’ve said in my comment, Unit-Test-Driven Development will help you evolve your designs over time but let’s just keep the most important things in focus, for now.
Even if one understands the basic fundamentals of C#, like methods, variables, bools, etc, – How does one learn to build, write, and structure the code accordingly?
Um. Practice? I mean. There are guidelines. For instance: everything should be kept as private as possible until you have a reason to make it more public. These are just a starting point. You’re going to have to practice, practice, and then practice some more. Over time, you will incorporate these guidelines into your process, then into your thinking, and then they will become something you do instinctively.
The number of things that are available to learn is vast. Depending on your rate of absorption, you could spend years or even decades studying them all. So don’t bother trying to learn everything. Just pick the few most important things: Syntax, Code Quality, and the parts of the Unity and .NET Frameworks you absolutely need to accomplish your objectives. Get good those things and, when you are comfortable with them - when there is almost no chance that you will abandon them if the going gets tough - add one or two more. Repeat that process until you are writing these answers for the next generation of programmers.
Sorry I can’t give you a simpler, more concise answer but you basically asked “How do I get good at something that some people choose as a life’s work.” The simple answer isn’t any more comforting than the long one: Make it your life’s work.
Failing that, make it your most prominent hobby.