# A raylib starter template for VS Code where F5 builds and runs

> This repository is a minimal C++ scaffold for Visual Studio Code on Windows, built around a raylib bouncing ball demo and a pre-configured build task. The interesting details are the mismatches: the badge advertises raylib 6.0 while the Makefile still defaults to 5.0.0, and the compiler path is hardcoded to a w64devkit install under C:/raylib.

**educ8s/Raylib-CPP-Starter-Template-for-VSCODE-V2** — Raylib C++ Starter Template for VSCODE V2

- Repository: https://github.com/educ8s/Raylib-CPP-Starter-Template-for-VSCODE-V2
- Stars: 1,037 · Forks: 88
- Language: C++
- License: not declared
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/educ8s-raylib-cpp-starter-template-for-vscode-v2

## Three steps and a window opens

The pitch is a minimal C++ project scaffold for Visual Studio Code on Windows, with a bouncing ball demo and, in the project's words, zero boilerplate friction.

The getting started section is three steps. Double-click main.code-workspace to open the project in VS Code, navigate to the src/ folder in the Explorer panel and open main.cpp, then press F5 to compile and run. That is the whole flow.

The F5 key doing the compile and run is the part that makes this a template rather than a repository of source files. The .vscode/ directory holds pre-configured build tasks, so there is no manual setup step, no terminal command to memorise and no CMake project to configure before the first run. For someone learning raylib, that removes the wall of tooling between installing an editor and seeing a window on screen.

The repository root is small and tells you what you are dealing with: a .vscode/ directory, a Makefile, a lib/ directory, main.code-workspace at the root, a preview.jpg, a src/ directory, and the README. There are no GitHub releases, and the repository is not archived.

The badges state the supported matrix plainly: C++ as the language, raylib 6.0, platform Windows 10 or 11, and VS Code as the editor. The feature table repeats the same idea with a clean folder structure where all source code lives in src/, a ready-to-run bouncing ball demo using raylib's core 2D drawing API, the pre-configured VS Code tasks, and the note that it is tested on Windows 10 and 11 with raylib 6.0 out of the box.

## The bouncing ball, in full

The demo is small enough to read completely, and it is the fastest way to see which raylib API shape the template targets.

```cpp
#include <raylib.h>
#include "ball.h"

int main()
{
    const Color darkGreen = {20, 160, 133, 255};

    constexpr int screenWidth = 800;
    constexpr int screenHeight = 600;

    Ball ball;

    InitWindow(screenWidth, screenHeight, "My first RAYLIB program!");
    SetTargetFPS(60);

    while (!WindowShouldClose())
    {
        ball.Update();

        BeginDrawing();
            ClearBackground(darkGreen);
            ball.Draw();
        EndDrawing();
    }

    CloseWindow();
}
```

The structure is the standard raylib frame loop. InitWindow takes a width, a height and a title, SetTargetFPS fixes the frame rate, and the loop runs until WindowShouldClose reports that the user wants out. Inside the loop, BeginDrawing and EndDrawing bracket the frame, ClearBackground fills it, and the ball is drawn by its own Draw method.

The interesting bit is the separation of behaviour from rendering. main.cpp never touches the ball's position, it calls ball.Update() to advance it and ball.Draw() to render it, and the ball class lives behind the ball.h include. That is a small lesson in structure delivered by example rather than by instruction, and it is the reason the demo is worth reading even if you copy the template for other reasons.

Note the file is main.cpp and the class is a C++ class, but the raylib calls themselves are the C API, with raylib.h included directly. The repository topics list raylib-cpp, so the C++ binding is part of the intended path, and the demo shown here is the plain C surface.

## The Makefile is raylib's, and it shows

The Makefile at the repository root is not written for this template, it is the one that ships with raylib itself, and the header says so. It is described as the raylib makefile for desktop platforms, Raspberry Pi, Android and HTML5, copyright Ramon Santamaria, and it carries the permissive notice that anyone may use it for any purpose including commercial applications, subject to three conditions: the origin of the software must not be misrepresented, altered versions must be plainly marked as such, and the notice may not be removed or altered.

That licence is the zlib style licence, and it applies to the Makefile. The repository's own licence metadata is not stated, which is worth knowing if you plan to redistribute the template itself rather than just use it.

The variables at the top of the Makefile are where the real configuration lives. PROJECT_NAME defaults to game. RAYLIB_VERSION defaults to 5.0.0. RAYLIB_PATH defaults to ..\.., which is a relative path expecting a particular directory layout. COMPILER_PATH defaults to C:/raylib/w64devkit/bin, which is an absolute Windows path expecting the MinGW-w64 toolchain to be installed in a specific place. And PLATFORM defaults to PLATFORM_DESKTOP, with a comment naming the other three choices, PLATFORM_RPI, PLATFORM_ANDROID and PLATFORM_WEB.

Two of those defaults are the friction the README does not mention. The compiler path is a hardcoded absolute location on a Windows machine, so if your toolchain lives anywhere else the build task will not find it without an edit. And the relative RAYLIB_PATH only resolves if you cloned the project into the directory layout the raylib makefile assumes, which is the sibling of the raylib source tree.

## Version numbers that disagree with each other

The README badge says raylib 6.0, and the feature table says it is tested on Windows 10 and 11 with raylib 6.0 out of the box. The Makefile says RAYLIB_VERSION ?= 5.0.0.

Both statements can be true at once, and the likely explanation is that the demo builds against a raylib 6.0 installation that the developer has, while the Makefile still carries the default from the upstream file it was copied from, which nobody adjusted because the variable is only consulted for some targets and the local setup already points at the right headers and libraries.

The point for a reader is that the two numbers are not interchangeable evidence. If you are following a tutorial that tells you to set RAYLIB_VERSION, be aware which one you are changing. The badge is a statement about what was tested, and the Makefile default is a leftover configuration value.

The same caution applies to the platform support. The README presents this as a Windows 10 and 11 template with a Windows compiler path, which is accurate for the tested configuration, but the Makefile it ships supports Raspberry Pi, Android and HTML5 as well, and a Makefile that can target a Raspberry Pi is not much of a Windows-only artefact.

So the template as shipped is genuinely a Windows-first scaffold, and the portability that the Makefile implies is available to anyone willing to set the platform and the paths themselves.

## What changed in V2, and what the project is

The name carries a V2, and the change log in the README is one sentence: the template now uses folders for better organisation, and all source code lives in the src/ folder.

That is a small change, and it is the kind of change that matters for a teaching project. A flat project with main.cpp, ball.h and ball.cpp in one directory is fine, but the moment a learner adds a second entity, a header folder and a source folder stop being optional. Moving everything into src/ at the start means the layout people end up with anyway, and it is also what makes the include of ball.h in main.cpp read as a deliberate decision rather than an accident.

The repository name itself is instructive. It is the second version of a starter template for VS Code, and the naming pattern of the repository, the V2 suffix and the folder reorganisation all point at a series rather than a one-off. 

The other resource the project points at is a video tutorial on YouTube, linked from the preview image at the top of the README, plus the author's channel. For a project whose entire promise is a three step setup, a walkthrough video is a reasonable companion, and it also means the audience is expected to be someone who has never built a C++ project before.

There is no further documentation in the repository beyond the README, no contributing guide and no changelog file, so the README, the Makefile and the source are the complete documentation.

## Conclusion

Adopt this template if you are a beginner on Windows who wants a working raylib program in the editor in a couple of minutes, and you are willing to read the Makefile variables before your first build. Do not adopt it as a production starter for a team, because the compiler path assumes a specific w64devkit layout, the Makefile and the badge disagree about the raylib version, and the licence metadata for the repository itself is not stated. Before you start, check that raylib and a MinGW-w64 toolchain exist where the Makefile expects them, adjust RAYLIB_VERSION and COMPILER_PATH to match your machine, and remember that the F5 task is a convenience rather than a portable build system.

## FAQ

### How do I run the raylib starter template in VS Code?

Double-click main.code-workspace to open the project, open src/main.cpp in the Explorer panel, and press F5 to compile and run. The .vscode/ directory contains pre-configured build tasks, so no manual build setup is required.

### What does the bouncing ball demo show about raylib?

It shows the standard frame loop: InitWindow, SetTargetFPS, then a loop that checks WindowShouldClose, calls the ball's Update and Draw methods between BeginDrawing, ClearBackground and EndDrawing, and finally calls CloseWindow. The game logic sits in a Ball class behind ball.h rather than in main.

### What do I need to change to build this on my Windows machine?

The Makefile defaults matter here: COMPILER_PATH points at C:/raylib/w64devkit/bin, RAYLIB_PATH defaults to a relative ..\.. path, and PLATFORM defaults to PLATFORM_DESKTOP. Set these to match where your raylib installation and MinGW-w64 toolchain actually live.

### Which raylib version does the template target?

The README badge and the feature table both refer to raylib 6.0, and it is tested on Windows 10 and 11. The Makefile, which comes from raylib itself, still carries RAYLIB_VERSION ?= 5.0.0 as its default value.

### Is the raylib starter template still being worked on?

The repository is not archived and the last push was on 2026-04-25, but the project has no GitHub releases, so there is no version history to follow. The README is the only documentation, alongside a video tutorial.

## Sources

- [educ8s/Raylib-CPP-Starter-Template-for-VSCODE-V2 on GitHub](https://github.com/educ8s/Raylib-CPP-Starter-Template-for-VSCODE-V2)
- [Issues](https://github.com/educ8s/Raylib-CPP-Starter-Template-for-VSCODE-V2/issues)
- [README](https://github.com/educ8s/Raylib-CPP-Starter-Template-for-VSCODE-V2/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/educ8s-raylib-cpp-starter-template-for-vscode-v2