Heads up! With over 1,000 pages of textbook material, Learn 2D Gamedev From Zero outgrew the original Early Access plan. Through iterations and based on your feedback and questions, we ended up packing most of the topics we had planned for Early Access in the first 10 modules.With longer, denser modules than initially planned, by module 9, you should already be able to create a perfectly playable game. That is why we inserted M10. Path of Sorcerers, for you to practice the concepts you learned in a final game project.The course's promise was to teach you the foundation and take you to the point where you can keep learning independently. Many of you are already coding games alone, without any tutorials whatsoever, and we're really proud of you and happy for you!So, what now? Do we stop here?No!Thanks to your trust and support in Early Access, we will be going further and taking you to Level 2 in a new course that helps you practice what you've learned across 4 game genres: tower defense, platformer, turn-based RPG, and action-adventure (2D Zelda style).This module marks the beginning of the new course: Practice 2D Gamedev with Godot 4, a course that you will get, in full, at no extra cost.This new course will, of course, cover the few remaining topics we didn't get to in Learn 2D Gamedev From Zero: tilemaps, saving and loading, the side-scroller view, and debugging tricks.But that's not all. You'll also learn extra concepts and techniques that were not in the Early Access plan, like:
Code structure and organization to support growing projects
AI pathfinding with the AStar algorithm
How to place and find objects in a top-down grid
How to use pixel art graphics and keep them crisp
How to code turn-based gameplay
We're temporarily including the first module of the new course in the current course so that you, Early Access supporters, can easily see the new content before we split it. Soon, everything past module 10 will be split into a separate course that will be automatically unlocked and accessible from your course dashboard.After this long announcement, it's time to introduce the new course and start the first game project: a tower defense game that will teach you how to create modular and upgradable turrets, enemies that walk to the player base using the AStar pathfinding algorithm, and more.
Nathan
Founder and teacher at GDQuest
Welcome to Practice 2D Gamedev with Godot 4! This course is the second part of our curriculum to become a game developer using Godot. It directly builds upon what you learned in Learn 2D Gamedev From Zero.In Learn 2D Gamedev From Zero, our focus was on learning the foundations of coding and game development. Every module and project was designed to introduce new programming concepts in a specific order and build the foundations you need to code and keep learning independently, without having to rely on tutorials for everything.Whether you learned with us or you're already experienced with game development and Godot, in this course, we will build upon the foundations and focus on applying them to four game demos in four game genres.First, you'll code a Tower Defense game where the player can place turrets to defend against waves of enemies. In this project, you'll learn to code a modular tower system, a mob spawner that sends waves of enemies, pathfinding for the mobs, and upgrades you can buy for the turrets by clicking on them.This is a great project to practice code architecture.
The next project will be a pixel art Side-Scroller game. This is an opportunity to explore the specifics of working with a side-scrolling view, setting up tilesets, designing levels with tilemaps, using rigid body physics, and working with pixel art graphics.
NOTE:
The following projects' graphics are subject to adjustments and improvements as we create the modules. The final projects may look a bit different from video and image previews.
In the Turn-Based RPG project, you'll learn to code turn-based combat as in classical RPGs like Dragon Quest, Final Fantasy, or Suikoden. You'll create a battle system where you can select actions for your characters and a simple AI for the enemies. You'll also learn to transition between the overworld and battle scenes. We'll use this project to learn how to transfer data between scenes and code savegames.
Finally, you'll create an Action-Adventure game inspired by the 2D Zelda classics. In this game, you'll learn to code different types of tools the player can select and use, two types of enemies, keys and doors, and a simple inventory system.
In the final project, you'll revisit Path of Sorcerers and apply the new techniques you learned in this course to improve the game with procedural content generation and more complex mobs to turn it into a more complete game demo to put in your portfolio.
We'll cover the essentials of each game genre. By the end, you can expect to feel more confident with how to approach coding different kinds of games.Keep in mind that this is apprentice-level material: you shouldn't expect weeks-long deep dives into a single game genre. The purpose of this course is to help you strengthen your gamedev foundations and help you become more independent.
Nathan
Founder and teacher at GDQuest
What to expect from this course
In this apprentice-level course, we assume that you have all the coding, gamedev, and Godot knowledge necessary to create simple game demos by yourself. You should be comfortable with concepts and techniques like:
Reading and writing common GDScript code, including lambda functions
When and how to use built-in processing functions: _process(), _physics_process(), _input(), _ready(), etc.
Creating, connecting, and handling signals
Creating, loading, and instantiating scenes in the editor and at runtime
Creating classes, extending them, and using them in your projects
Handling and filtering physics interactions and collisions
Assuming these foundations means we can spend more time focusing on the big picture, on game mechanics and code structure, rather than breaking down small pieces of code. We can spend more time on the "How" and "Why" and less time on moment-to-moment instructions.As you practice, deciding on the individual bits of code that make up your game should become less of a concern, and you should start to see the overall structure and how it supports your game's design. That's the goal of this course: to help you see the forest for the trees.
Overview of the Tower Defense project
Over the course of two modules, you will create a Tower Defense game where the player can place turrets to defend against waves of enemies. Let's look at what you'll create.
In this project, waves of enemy mobs walk across the screen towards the other side. When a mob makes it across, the player loses one heart. And once the player's health reaches zero, it's game over.
The player can purchase turrets that fight the mobs by clicking empty grid cells. Each turret comes with a weapon that automatically detects, targets, and attacks any enemies that come within its range.
Players can also upgrade existing turrets by clicking on them if they have enough coins to afford the upgrade cost. Upgrading a turret increases its stats, like its damage, its range, or its fire rate. After a couple of upgrades, a special upgrade can also change the turret's weapon entirely.
In Godot, an autoload is a node or a scene instance that is always present in your game. When you register an autoload in your project settings, Godot automatically loads it and creates an instance of it when your game starts.The editor allows you to access the autoload from anywhere in your project's code. So you can use the feature to store global data that you want to access from anywhere in your game.
to store global data accessible throughout your game project
Create an upgrade system that allows improving turrets
Detect when the player can buy a turret, place it on the game grid, or upgrade it
Use a resource to separate stats from turrets to preserve stats when upgrading turrets and changing their weapon
Make mobs automatically find the path to the end of the level using the AStar pathfinding algorithm
Save the game state in the simplest and fastest way possible, perfect for prototyping (you will learn other saving techniques to use when releasing your game in later modules)
In this first module, we'll lay the foundations for the game. You will:
Code weapons that target and shoot at enemies automatically
Create mobs that walk along predefined paths and take damage when hit by a weapon
Spawn mobs in waves
Create turrets that you can place on the game grid
This is a good stepping stone before shifting to the more complex mechanics like upgrades and pathfinding.This project is a great opportunity to practice code architecture. You will learn to structure your code in a way that makes it easy to grow the game and add more features to it on your own.
The project files and structure
Let's start by looking at the project files and structure.In Learn 2D Gamedev From Zero, I prioritized accessible code and simplified projects to help you learn the fundamentals and build complexity step by step. While you can use all the code you learned as a foundation for real game projects, I intentionally kept things simpler to make learning easier.In this course, we're taking a different approach. I'll show you how to structure code as you would in a professional environment
Code structure should change with your game
When working on longer projects, remember that requirements and game mechanics often evolve over time because, as you code, you're figuring out what your game will be. You cannot plan everything from the start.So, your code structure will inevitably have to change as your game evolves if you want to work efficiently. This means that:
You shouldn't overthink the code architecture early on, since your game will likely change a lot during development.
You shouldn't become attached to a particular code structure and force your game to fit within it. The structure is a tool to support your game's design and feel.
, based on each project's requirements at a given point in time.Here, the project only comes with the art assets, and you will write all the code yourself. Open the project Tower Defense (workbook) to get started.In the FileSystem dock at the bottom left, you can see a bunch of art assets in various folders. The folders already set a basic structure for the game:
We are going to work on a Tower Defense game and the game has turrets, so there's a turrets folder
The game has mobs, so there's a mobs folder
The game plays on a map where you place turrets and mobs, so there's a map folder
If it seems obvious and straightforward, that's the point! The folder structure of your project should reflect the game you're making and how you're going to break down the code into modules.In M10.L3: Organizing game files, we discussed two ways to organize your project files: by file type or by game system. In all the games you'll make in this course, we'll organize files by game system. It makes it easy to find the assets you need and the code that uses them as they're grouped in the same folders.
Nathan
Founder and teacher at GDQuest
The code structure
When starting a new project, it's tempting to try planning the code upfront. However, even experienced developers rarely get the architecture right on their first try. Instead, game development is an iterative process where your code structure appears and evolves as you implement features.How should we go about structuring the code for this project? Or for any project, actually? Since it's not something you can decide upfront, we'll come back to code structure repeatedly in the module and unveil pieces of the puzzle as we go.Here's what we know so far:
The game has turrets that shoot at mobs
The player can place turrets on the map
Turrets can be upgraded
Mobs spawn in waves and walk across the map
So, at least at first, we can think about organizing the code around these modules:
A map script that handles turret placement and perhaps upgrades (because you need to know where the player clicked to place or upgrade a turret)
A turret script that either includes the shooting code or two scripts to separate the weapon and the turret
A mob script that handles the mob's health and movement
A script that spawns mobs and places them on the path to walk across the map
This is a starting point to get coding. It's hard to decide beyond that until we start implementing these features and see how they interact.As you'll see during the module, we'll have to adjust the structure because of subtle issues that arise when coding the mechanics.Enough talking about code structure, Let's get coding! I'll see you in the next lesson.
Getting started on your own can be daunting. Do you feel like you can understand code and tutorials fine, but when it comes to starting your own project, you have no idea how to structure it?That's completely normal! Even professional developers, unless they've worked on a similar project before, don't know how to structure their code upfront. It's something you figure out as you go.Here are some guidelines to help you get started. First is mapping out the game mechanics:
Start by laying down the game mechanics you want to implement in your game. Things like "the weapon targets the closest enemy," "the weapon shoots at one enemy, one bullet per second," "the weapon has a limited detection range," etc. First, express these features from a game design perspective, without worrying about the code. And don't worry about future changes: just list the mechanics you want to implement in a first prototype or demo.
Group and order these mechanics. All weapon mechanics should be together, all enemy mechanics should be together, etc., because they will likely belong to the same system or scripts.
Prioritize these mechanics. What are the actions the player will do most often? What are the most important mechanics for the game to work? For example, in a tower defense, the player spends most of the time watching turrets shoot at enemies, so the weapons and how they damage enemies are very important. You could prototype the game with just weapons and waves of enemies to test the core gameplay loop.
Then, here's how to pivot to code:
Translate the mechanics into code requirements. For example, "the weapon targets the closest enemy" can be broken down into "the weapon tracks the enemy closest to it" and "the weapon turns towards the tracked enemy." In code, finding the closest enemy and aiming at it are two separate tasks.
Pick a couple of requirements and implement them in the simplest way possible. Don't worry about making your code feel smart or structuring it well at this stage; your first version is a sketch that you'll likely throw away or refactor later.
When a piece feels difficult or new, break it down into smaller pieces you can prototype separately. For example, if you don't know how to go about creating upgrades that increase the weapon's damage, you could make a test scene with just a weapon and a button that increases the weapon's damage when you click it.
Once you have working prototypes of the core mechanics, you can start seeing patterns and planning how different parts should interact. This is when you can start to make informed decisions about code structure, move code around, or rewrite parts as needed.
Finally, expect to refactor and sometimes completely rewrite parts of your code as you encounter constraints or discover better ways to arrange scenes and scripts. This is normal and part of professional game development. We all face it on the job.
Use this space for questions related to what you're learning. For any other type of support (website, learning platform, payments, etc...) please get in touch using the contact form.
No questions yet! It's really ok to ask the first question.
Lesson Q&A
Use this space for questions related to what you're learning. For any other type of support (website, learning platform, payments, etc...) please get in touch using the contact form.