Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Follow the wormhole through a path of communities !webdev@programming.dev
The only "wrong" way to start something is to not actually start.
Some people might toss you at whatever pet interest they have in the broad skillset which is gamedev. Tell you it's fundamental.
I won't.
Take The Frizz approach. Take chances, make mistakes, get messy!
You can download a FOSS game engine RIGHT NOW (Godot). Start small. Fuck with it until your questions become specific. Once you know what you don't know, but need to know, that's what you should learn.
Start small
This is my strategy whenever I learn a new language. Start easy, escalate in complexity.
Etc.
The basic game itself doesnt matter - make it hangman if you want. The idea is to get used to a language.
Keep doing that sort of thing, experimenting and learning, find ways to break things, find weird ways to solve problems, figure out ways to write even less lines of code. Find elements that you can make a function instead. Sanitize inputs excessively. Whatever.
Play around, and keep playing around. You'll learn in no time.
For the record, this is how I learn, by doing. I have a really hard time sticking to tutorials, and I find examples far more helpful than a manual entry explanation of what something does. YMMV.
Start with designing a physical card or board game. Play test it until it’s fun.
For artwork practice drawing on paper.
For writing write stories and dialogue.
Make or choose some music.
Use the above to make a video.
No programming required.
“Making a game” involves many different subjects. Since were in a programming community I guess things like storytelling, worldbuilding, writing lore, writing characters or missions/quests, designing ingame or promotional art, etc. is ruled out.
Depending on the game you want to work on, you should learn how to use the game’s engine. It’s always good to know C/C++ well, Lua is also pretty common for scripting. Game engines sometimes also come with their own scripting languages.
You should also learn 3D modelling, 3D design, GLSL for shaders, etc. Even if modern engines cover a lot of this for you, it’s always good to know what’s actually happen, so you can properly track down errors.
i cant really make out a different between the definitions of coding and programming, what is the difference if any?
How I see it: All programming is coding, but not all coding is programming. Writing markup (like HTML) or style definitions (CSS) in my world count as coding, too, but not as programming. I’d also say that writing code in any scripting language is not programming but coding. Whenever the code is meant to be compiled into a standalone binary – a program – it’s programming.
The difference between coding and programming is similar to the difference between geeks and nerds: difference without distinction. Programming is the act of giving a computer instructions and coding is the act of writing code. We give computers instructions by writing code, so no difference.
Godot is a great place to start. It is a free game engine with excellent documentation and a bunch of online content. It uses a programming language that is simpler/more abstracted then C/C#. It is also way more forgiving then C. The documentation has a couple of tutorials for you to follow as well. Godot also allows you to export your game to browser, android, or Steam.
If that is too much for you you can try RPGMaker MV (nade for nonprogrammers) or Scratch (made for kids).
Don't focus on learning everything at once. Pick one thing to learn / focus on at a time.
There are tons of free game assets out there for you to use to help you focus. For example when you are learning programming don't worry about the images and sounds, use premade ones.
You can always go back later and make your own assets for them when you decide to focus on that aspect.
Along the way you may find you really enjoy one particular aspect of it and zero in on that, but for a baseline.
Make tiny simple games so you can see progress and share. This one was/is the hardest one for me. I've long wanted to make games and had huge grandeous ideas for one and always itching to make it but I need to tackle things that are reasonable that I can finish.
For 2D assets you could use GIMP for free or Affinity. As a solo developer I don't recommend Adobe.
For 3D assets Blender is the best way to go and is free.
Based on personal experience, I'm a firm believer in that best way to learn and get good at something is to just do it and keep doing it.
So: download godot or such and try to make stuff. You'll figure it out as you go.
Check out Godot game engine. Watch a lot of videos about it. How to do simple things. How to do hard things. And things you wish you could do when the stars align. Start soaking it all up.
And practice using the engine (any engine). You'll get good at the basics by trying and failing and then doing it agian.
Check out Godot game engine.
Something like LÖVE would be much better for beginners. It's much more important for first projects to get results that keep you motivated than to jump on the deep end with features.
Fantasy consoles like PICO-8 or TIC-80 offer a simple engine with all the editors included. It's a great way to build a basic game idea before fully committing to an engine like Godot.
Start with pen and paper - no computer, because that'll just distract you.
Write down what kind of game you want to make. Sketch out what you want your player to see when they play the game (top down, third person, first person; which UI elements should they see? Health? Mana or power bars? Selected items?). Does it have a story of sorts? What kind of setting (future, past, fantasy, sci-fi). 2D or 3D? What kind of visual style are you going for (realistic, cartoony, abstract?).
This will be your Game Design Document. You don't have to get it perfectly at the first go - iterate over it, scratch things that you feel won't work.
Once you have something that looks like a minimally viable product (MVP), THEN you can start making something in Godot, Game Maker, or Love2D. Because now you have something to follow along. Try to get something out ASAP, because feedback from people who are not you is important. Maybe you made something that feels fun to you, but no one else likes it - you would want to know that as soon as possible, not after toiling away for 5 years.
Do not start caring about "what is the fastest programming language". Even the slowest of languages are fine, because you're learning how to build a game, not how to program like a pro.
I'd have to subtly disagree with this. It is really good advice, especially when the scope of your game is larger than what one could reasonably finish in a game jam; If you can't get to a fun game in a couple of days or less, you need documentation as to what your plan is to get there.
The problem is that this is the best advice for someone who has the technical "hard" skills to make a game (compsci, digital art, etc.), but lacks the "soft"er skills (software eng., scheduling, etc). To be fair that is super common, but the OP implies to me they're not confident that they have the technical skills either yet.
Without either of those skills you can't know what'll take a couple of days or what's actually weeks of work, and the value you get out of design docs becomes effectively random.
The common advice that I'd have to agree with is that your first few games should be as small of a scope as you can make them. Other comments to this post already go into detail, but the jist is that when you're starting the amount you learn is more per-project than per-hour, so get out as many small things as possible to get your bearings.
Once you've done that, this is really good advice for your first sizeable project.
Start small. Like, really small. Don't listen to the elitism about programming languages. Make stuff, fuss about the details later. Godot's cool. Love2D's cool. Nobody gives a fuck if you used a scripting language or an enterprise grade engine or if you wrote it in assembly like some cybermonk. Balatro was nominated for goty and was written in a "simplistic" scripting language (Lua with Love2D).
I would recommend starting with an engine--it doesn't much matter which and follow several tutorials. The exact amount will vary based on your programming experience and game design knowledge. Once you've followed some tutorials start trying to connect concepts from different tutorials to make something new that you weren't explicitly guided to. After you've done that a few times, start a new project and try to make something from scratch and use reference materials, documentation, and tutorials to help you when you get stuck.
Start small. Now even smaller. Tic tac toe is a reasonable first project. It will teach you how to use the UI library, user input, game state, scene transitions, basic AI for a computer opponent, etc.
Then do some game jams. There's a lot hosted all the time on itch.io. You don't have to finish, but it gives you good practice, let's you see what's possible in a weekend, and let's you connect with others that love game dev.
I've seen a lot of comments encouraging you to try out Godot. It's a great engine, and with its resource library and active community it can be a good choice, but it doesn't hold your hand. There's very little logic that is pre-produced and ready for you to tweak. You start with nothing and build what you want rather than starting with a template (though there are templates available in the resource library). I've used a lot of engines and Godot is my personal preference, but depending on your experience Scratch or Unreal may be better options for the easy of use and active communities/tutorials.
If you're getting started with programming the first resource I point people to is Scratch. It's the easiest way to get started, and teaches programming concepts with guide-rails. I recommend looking at a game someone else has made on the Scratch website, and "remixing" it to tinker, and understand how it works.
When you hit the limitations of Scratch, and want more I agree with other commenters that Godot or LÖVE are good next steps.
Learn unity or unreal, that is what's most prevalent in the industry. Making games is a lot of work so start small and don't expect anything of quality for a while. There are a lot of fun little youtube tutorials, just stay away from the one with like 60 parts to them.
