How should I start developing my first game?

Hello, this is my first post on the Godot forums.

I’m looking to learn how to make games, and of course I have a “dream game” in mind, but I know I need to work on my skills and build systems before I start on it.

I’ve completed the 2D game tutorial from the Godot docs, and I really enjoyed it. However, opening up a new project to start my first “real” game has me stumped. What should I make first? Mechanics? A player character? The main menu? How do I organize everything in the scene tree? Should I make artwork or just use some placeholders? I also don’t really know how I should go about learning how to code the systems and mechanics I want. Should I look for a tutorial to see if its been done before or think of what I want and figure it out from the docs and the forum?

I’m sorry if these are boring or repetitive questions, but I’ve got game dev writer’s block and watching a bunch of short youtube videos about getting started in Godot and easy mistakes to make hasn’t helped.

Thanks in advance if you comment!

Joe

Start by making pong

Some time ago a friend asked me a similar question and I decided to put together this guide: GitHub - viniciusgerevini/learn-godot-challenge: I challenge to help learning Godot from zero · GitHub . You might find it useful.

This was more focused on a recommended order to learn things (which I think you might have already done), but it might also help as an example to how to breakdown your project.

Each person has their own way of learning. For me, tutorials are usually not very effective, as I end either getting bored or not memorizing anything. They are good as examples though. I prefer to find an idea and break it down in manageable tasks, trying to solve them in my own way. When I get to a specific area, I search for docs and examples online and try to implement it myself.

When it comes to art, it’s better to not over commit from the beginning. I learned that the hard way hehe. Usually your skills and ideas evolve too fast and trying to polish from the beginning just ends in more rework. Either pick a free asset pack to start with or do the bare minimum to flash out your ideas at first, until other systems are in place.

I hope that helps. Good luck! Cheers,

Mechanics are a good place to start, if not the underlying systems (for more complex projects). You generally needs to have mechanics and systems in place for the menus to have anything to adjust in the first place.

The Scene Tree is pretty simple. Generally everything is organized based on ownership. Child nodes are implicitly positioned based on their parents, they inherit their parent’s pause state, visibility, etc. You want to take advantage of this inherited behavior whenever you can.

An enemy might have a CharacterBody2D for it’s hotbox, a Sprite2D for its image. Everything which should move or be instanced as a unit should be attached (directly or indirectly) to a common parent.

Organization in the filesystem is more subjective, but I generally like to place all the images and sounds that a scene uses in the same folder as the scene itself.

Artwork takes a considerable amount of time to produce, so I always reach for placeholders first, but do not delay too long on art design. Original sprites and tiles have a major influence on the vibes. Sound design (even with stock audio) is absolutely transformative. Don’t sleep on fonts and UI theming either.

This comes with experience. As you work on projects, you will become familiar with a number of design patterns and algorithms. These will become your tool chest, and eventually it will be obvious that when you have a nail, you need to reach for a hammer, or if you have a nut, you need a wrench.

It might be easier to start with a problem (e.g. how do people do destructible terrain in a game like Wormz) and research how the problem has been solved in prior art. Usually there are several approaches with benefits and drawbacks. You might learn what a quadtree is, and then recognize other situations where it might be applicable.

Another big part of it is learning mathematical tricks and shortcuts. Being able to describe some behavior as a simple formula can be a lot more concise than a bunch of nested conditionals.

Thank you all very much! I think I’ve got a better idea of what to do now. I appreciate the tips and resources, and I’m feeling much more confident. I didn’t expect the people of the forums to be so helpful, thanks again!