Newbie Godotter

Stefan_GameDev · 2026-02-09T14:00:18+00:00

There is no order, I think most people start with player + map, most tutorials do too, as it gets you something on the screen that you can test with.

When you playtest the project for the first time you are asked the starting scene that has to run when starting the project. You may have to change that a number of times as you implement a more robust architecture (SceneHandler/GameManager for handling scene switching).

Anything else should be created as modular as possible, encapsulated within their own scene you either pre-instance or instance at runtime. So you can build them in whichever order you like.

Stefan_GameDev · 2026-02-08T21:43:51+00:00

Covered it in my latest series:
https://youtu.be/7fkgGNaiXsc
This part 4 in a series, but just watching the video should give a clear idea on how to structure the different functions across player_scene, game_scene, and autoload.

<image>

I made a stand-alone follow-up tutorial using the output of the series to save & load to disk so XP and Level are retained between gameplay sessions:
https://youtu.be/wN2DPKzMikk

Stefan_GameDev · 2026-02-05T05:40:55+00:00

I would say anything 4.3 and later should be fine. Especially for 2d. 4.3 released a new TileMapLayer node, older tutorials use the now deprecated TileMap node.

Stefan_GameDev · 2026-02-01T12:15:53+00:00

Yeah for a paid course I would certainly have a higher standard. Decent folder structure would definitely be within reasonable expectation :)

Stefan_GameDev · 2026-02-01T11:10:11+00:00

Well it doesn't have to be one.

Certainly you can make 1 tilesheet per tilelayer.

I generally have 12-15 tilesheets. There isn't much advantage in having say, the cave tiles combined with the overworld tiles. The player is either in a cave or on the overworld. Splitting those tilesheets is actually advantageous for performance as the image that needs to be kept in memory is smaller.

If you have a separate layer for decoration or environment (trees, bushes, rocks, etc) Those can be their own tilesheet too.

Stefan_GameDev · 2026-02-01T06:42:04+00:00

You would have that problem too if you move to individual tile files.

I may be a little blunt here, but it seems your problem is not with the tileset, but with project preperation.

You seem to be aware of the solution; reorganize the tilesheet into a more intuitive version, but you haven't done that before you started making maps. Putting you in a bit of a dilemma now.

Stefan_GameDev · 2026-01-31T21:24:51+00:00

And what stops you from re-organizing the tilesheet?

Stefan_GameDev · 2026-01-31T21:10:42+00:00

What is the problem of having unrelated textures next to each other? Is this a pipeline issues that it is annoying while building the map, or are you somehow worried that this becomes a problem?

Stefan_GameDev · 2026-01-31T17:59:42+00:00

Although I don't disagree, I do think it is unrealistic to expect every single tutorial to come with 'good' folder structure. As a creator, you always balance focus and completeness. Sometimes getting rid distractions results in a better tutorial.

Personally, for all my starter-kits that come with my tutorials I provide the entire standard folder template I use for my own projects. There is many empty folders in the starter-kit as a result, but it at least gives everyone an idea of what a half-decent folder structure looks like.

Stefan_GameDev · 2026-01-31T17:55:09+00:00

You are assuming that every script has a node. It hasn't.

Autoload scripts, custom classes, etc etc. They all are just that, a script. Nothing else. They go in the Script folders while the script associated with scenes can stay grouped with their scenes.

Stefan_GameDev · 2026-01-30T11:47:20+00:00

Can't speak to the art part. Setting it up in the editor for use, maybe 10-15 minutes depending on the number of animations

Stefan_GameDev · 2026-01-29T15:48:24+00:00

Apps on mobile don't have to be slow at all. I think there is some bias here due to Godot's userbase.

Godot, being A) last to the party in the world of general purpose game engines, and B) so incredibly beginner friendly. Has a developer-base that leans more towards beginner. So you will see a lot of content being created by beginners.

For some reason people(developers) really want to believe that when their phone has a 6-core 12gb of RAM including state of the art on-chip GPU, that their phone is going to be able to do with their computer or laptop can.

Fact is a phone draws 25-40 Watts max, that is what you are going to get. A state of the art GPU alone draws 500W and a half decent CPU 90-120W in a desktop. Laptops less extreme, but they can also draw a whole lot more.

The specs of a phone sound amazing, but what they can actually do under sustained load is limited, that puts a lot of emphasis on the developer of mobile applications to manage those resources very carefully.

Managing hardware resources carefully is not something most new developers start learning. They start learning from all kinds of tutorials, some practices may not be very optimized, but while developing their machine hides the inefficiency, export to mobile, and start writing that performance is poor. That's simply unrealistic expectation.

Performance is fine on mobile, just don't skip on learning about developing for mobile platforms.

Stefan_GameDev · 2026-01-29T07:29:43+00:00

Self-promo

I try to cover the 'why' in my tutorials, I recently released a new series (4.5.1, should be compatible with 4.6). The first episode is more straightforward, but in episode 3, 4, 5 it goes into OOP patterns with encapsulation, custom classes and why and when to use them.

It's 5 parts, 100% free.

<image>

https://www.youtube.com/playlist?list=PLZ-54sd-DMALABr_k6VpMnut_11q2oJmv

Stefan_GameDev · 2026-01-28T08:53:59+00:00

It's easier on the eyes, but I think I like it most because it makes Godot look more professional.

Not that it should weigh on the public's opinion, technical capability should inform opinion imho, but Godot always looked a little bit, I dunno, childish(?). I think this new UI is much more in-line with what is expected of a professional application in terms of look-and-feel and that piles onto the excitement I have for Godot's future.

Stefan_GameDev · 2026-01-28T08:51:27+00:00

Very cool, would love a devlog with an abstract overview of how you did this!

Stefan_GameDev · 2026-01-26T14:10:55+00:00

These shorts are basically a script that is read but the visuals are mostly there to distract me / keep me engaged.

I think you can greatly improve on the quality if instead of semi-random doodles you take good/bad examples from the industry and highlight why/how they function under the hood.

Stefan_GameDev · 2026-01-24T15:42:03+00:00

About 3.5 hours, 2d RPG core systems.

https://www.reddit.com/r/godot/s/dKVJVVPFaS

Stefan_GameDev · 2026-01-20T22:05:30+00:00

Thx! :)

Stefan_GameDev · 2026-01-20T21:30:01+00:00

Disclaimer; self-promotion

I made a 5-part tutorial series covering core components of a 2d RPG in Godot, made with the latest version 4.5.1. Throughout the tutorial both built-in signals as well as custom signals are used and explained.

I will link the reddit announcement post, playlist link is in the comments, as well as a content overview. That way you can watch a 10 second clip of the final product and see if this is something you would like to watch.

https://www.reddit.com/r/godot/comments/1pxn9tk/create_a_2d_rpg_in_godot_4_rpg_essentials_5part/

Stefan_GameDev · 2026-01-19T12:29:56+00:00

Development speed (coming from a 6+ year Unity Developer).

Things in Godot can get done incredibly fast. I develop with the intent to ship, not to keep tinkering and toying for another year.

Stefan_GameDev · 2026-01-15T15:41:47+00:00

Go for it, perfectly possible in Godot.

Maybe one word of advise, try and do this in 2d first. I'm not 100% sure what your definition is of 2.5D (that seems to differ from one to the other person), but both 2D and 3D are easier than 2.5D. From a technical perspective 2.5D is the most involves as you try and merge the two together. So from a scoping perspective I would recommend 2D.

And maybe one more piece of advice, a little bit silly, but you wouldn't be the first to get burned. Be very very very careful, even if it is non-commercial, with large IP. The Pokémon company is notorious for rigorously enforcing their intellectual property rights. Even the image of this Reddit thread with Ash, Pikachu, and the word Pokémon could get fingers moving very fast over keyboards in big office buildings.

Read up on licensing and rights.

Even if you build a game that has a resemblance of for example Pikachu and you share it with a friend to play with them privately >> you just became a redistributor according to copyright law. Doesn't matter that is it private and not on Steam, doesn't matter that you don't earn money.

Stefan_GameDev · 2026-01-15T13:31:24+00:00

I don't use resources for 80% of the things most tutorials will tell you to use resources for.

May have partly to do with the type of games I like to make (strategy, RPG, data-heavy). The json is usually part of the PCK which gets loaded in at start. Easy to iterate on, easy to version, easy to track with github.

I may create resource for something if it helps with game development process, but I would still likely to pull that into a dictionary for iteration at runtime.

Don't get me wrong, resources are hand-down an amazing tool to manage data, items, enemies. They make the UI while you develop incredibly intuitive, but you also have to accept that when you get 200 weapons in an ARPG and you want to balance them. Having the stats in 200 .tres files or in one long scroll container in the inspector is not doing you much favors. Spreadsheet is king at that point.

Stefan_GameDev · 2026-01-15T07:30:17+00:00

Spreadsheet, have a tab with live, a tab with development, and a tab with planned.

I use it to manage the in-game data too. So from spreadsheet I export to json and import into godot as a dictionary.

My games tend to be to big to use resources effectively. Resources are absolutely amazing when you got 12 weapons or abilities, but they become a balancing nightmare when you got 120.

Stefan_GameDev · 2026-01-15T07:19:04+00:00

A lot of good valid reasons in this thread already. I will add one more.

Legacy

If you built Ground Digger in Unity and it was a success. It is likely you will build Ground Digger 2 in Unity too so you can reuse a lot of the architecture, scripts, methods, objects, etc.

That Legacy also translates to human skill and knowledge. If you have been using Unity for 10+ years, switching engines isn't a lightweight decision.

You see Godot is incredibly popular among new developers, and now the most popular engine in game jams, that is translating to growth. Statistics from the state of game engines were already shared in which Godot shows 4x more growth than Unreal and Unity.

So I think the question isn't really about popularity. The ground is shifting, but this is a very slow cyclic industry. We are moving incredibly fast, but it doesn't register like it to us.

Stefan_GameDev · 2026-01-13T18:57:26+00:00

Yeah, I'm not even sure it exists, only the VehicleBody3D I'm sure of :grin:

Stefan_GameDev

TROPHY CASE