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.
this post was submitted on 20 Jul 2025
38 points (95.2% liked)
Programming
21831 readers
277 users here now
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
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
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.
- print to the command line
- take input from the command line
- dumb blackjack game
- dumb blackjack game and store session results
- Make a fugly UI but keep the operations text
- Make a fugly UI and add basic graphics
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.
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.
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).
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.
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.