The same concepts for music production apply to game music and sound effects. The tools vary, and are largely dependent on preference. All DAWs (digital audio workstation) do the same basic thing, record and mix sounds, and it boils down to the sound engineer’s preference. Like there are different kinds of cars but they get you from point A to B all the same.

MIDI, like the other comment explained in depth, is just a standard communication protocol. For example, when I use my MIDI controller keyboard, the DAW records my keystrokes (what note I pressed, how hard and how fast and how long I pressed it, and if I wiggled my finger). But my keyboard doesn’t produce sound, it just sends all the keystroke data to the DAW, and I can choose whatever sound I want it to make using virtual software instruments/soundfonts or plug-ins. Compare that to traditional recording where you play an instrument (i.e. guitar) and you literally just record the sound it produces.

When making game sound effects, you can either literally just produce those sounds and record them with a microphone into your DAW (more authentic), or use virtual sounds controlled by MIDI (more flexible and sometimes cheaper but might not sound realistic depending on your sound engineering skills).

100% the same boat when I started! I actually deleted a paragraph that said when I was young I wanted to learn how to do things the right way. You eventually learn there is no right way us devs will agree upon. You won't have opinions on the better way until you've done it an objectively bad way.

Reading code helps with this. I'm always looking at my library's and framework's implementations. Half my dependencies I swear I patch to make them "better" (subjectively).

lol. Yes, this makes sense.

This is both encouraging and scary. Not getting stuff right just intensifies my imposter syndrome when it comes to programming. But I understand what you mean. Just have to keep trying things and learn from my mistakes.

Thanks, this is really helpful advice.

I presume that you have at least some vague idea of what you want your program to do. If not, maybe a good random writing prompt generator can help.

But if you do have something in mind, I usually start by thinking about how I'm going to store my data. That goes hand-in-hand with thinking about how to break up the top-level tasks into individual functions and sub-functions. Those two processes tend to feed into each other, and before I'm aware of it, I've got a basic framework hammered out, at least in my notes.

Start small. Solve one piece of the problem at a time. The project will grow over time.

For example, say you want to make a GUI app. The steps might be:

1. Show an empty window
2. Add some text
3. Add a button
4. Make the button do something
5. Add another button
6. Etc

For each step you might need to follow a guide or a tutorial.

Don’t worry if you do any step wrong. You can always make it right later. Nobody is designing the perfect software on the first go. It’s better to have something than nothing.

Don’t worry if you need tutorials, documentation or examples on the way. Everybody needs to use some reference. I recommend to start following a tutorial (e.g. how to make a GUI app), and use it as a starting point for the rest of the project. Go off track from the tutorial and explore on your own.

I normally start from some template my ide generates or by copying a project of mine that is similar.

Still tutorials, kind of. Also looking at existing software. A lot of what you learn in development comes from the things you analyze or do yourself, but I don't know if anything can beat random tutorials for project setup and boilerplate. And RTFM as always.

Eat your own dog food. Solve a problem that you have, even if it’s dumb. Build that thing out of the pieces you know like with Legos.

If you knew how to start, you wouldn't be learning anything. So, you are learning. What do you want to learn about as you learn how to architect and develop some software? Web, databases, 3d rendering, gaming, etc.

Chances are you are going to need a framework, library, or many of both. You'll be learning those too.

Back to architecture. Once you have an idea of what you want to build, we want to get something running fast. Because whats going to happen is you are going to make bad decisions. Lot's of them and that's good! You want to fail so many times you learn what not to do, how to debug to keep things moving forward, etc.

So start with a hello world. Serve a webpage. Connect to a database. Draw a square. Then add another and another.

There is some quote out there that the difference between a beginner and master is the master spent X,000 hours failing. At the end of the day its just time spent learning.

You may start over. You may switch tech stacks. You maybe give up when something more interesting comes along.

90% of my personal projects never get completed. I'm usually learning a tool. If I'm reasonably able to use a new tool I've learned something. Become really good at learning. Learn to read code. Learn to read type signatures. Learn how the tools you learn work. Learn how to make them do things they were not meant to do. Learn your build system. Learn to setup linting, document your project, setup CI/CD, and so on.

For reference I'm in my 40s. Started coding at 13. Work R&D and greenfield projects for the same fortune 100 for almost 2 decades. Done everything from web, data pipelines, network code, integrated firmware, etc. As you skill up it gets easier. My team usually picks up a new stack every project as I level them up just to expose them to different things.

Yes, you will be threatened with death.

The classic answer is, do research and try to find existing projects that fulfill similar functions. Learn the jargon and functional features in the space that you want to create a solution for. So what do you want to make? What exists that is similar? Why are these solutions falling short?

I made a PHP blog engine as a proof of basic relational database design, CRUD, UI and middleware concepts. I still use it, haven't changed the code in 14 years.

People will probably want to kill me for suggesting it, but if you are not sure where to start, this is a great use for AI. You can bounce your ideas off of it, and it can help you put together a plan to build out your project.

I have to do this because I have a hard time conceptualizing things when I'm staring at a blank page. I don't know where to start, so it helps.