Capítulo 01 — Seu primeiro programa C++ começa agora

Da instalação do ambiente ao primeiro código compilado e executado no Visual Studio

No capítulo anterior definimos a direção desta jornada.

Falamos sobre C++, Engenharia de Software, SFML, Game Engine, arquitetura, testes, Game AI, Machine Learning, performance, produção e sobre o jogo que construiremos ao longo da série.

Mas existe uma diferença fundamental entre conhecer o destino e realmente começar a caminhar.

Hoje essa diferença desaparece.

Neste capítulo vamos abrir o Visual Studio Community 2022, criar nosso primeiro projeto em C++, escrever algumas linhas de código, compilá-las e executar nosso primeiro programa.

Nada de SFML ainda.

Nada de Game Engine.

Nada de arquitetura sofisticada.

Hoje nosso objetivo é muito mais importante:

sair de um arquivo vazio e chegar a um programa C++ que nós mesmos conseguimos construir, executar, modificar e executar novamente.

Se você nunca escreveu uma linha de código, este capítulo foi feito para você.

Se já programa em outra linguagem, acompanhe mesmo assim. Algumas decisões tomadas aqui serão a base técnica dos próximos capítulos.

Vamos começar.

1. O que vamos construir hoje?

Nosso primeiro programa será propositalmente pequeno:

  #include <iostream>

  int main()
{
    std::cout << "Game Engineering com C++ começou!" << std::endl;
    return 0;
}

Ao executá-lo, queremos obter algo semelhante a:

  Game Engineering com C++ começou!

Só isso.

Pode parecer pouco quando nosso objetivo final envolve uma Game Engine e um jogo completo.

Mas existe muita coisa acontecendo entre essas duas imagens:

  Código C++
   ↓
Build
   ↓
Programa executável
   ↓
Resultado

Hoje vamos executar esse processo.

Nos próximos capítulos começaremos a desmontá-lo para compreender como ele realmente funciona.

2. Nosso ambiente inicial

Nesta primeira etapa da série utilizaremos:

  Sistema operacional: Windows 64-bit
IDE:                Visual Studio Community 2022
Toolchain:          MSVC
Linguagem:          C++
Standard:           C++20
Arquitetura:        x64
Build inicial:      Visual Studio / MSBuild

Ainda não precisamos de:

  SFML
CMake
Conan
vcpkg
Game Engine
Frameworks
Bibliotecas externas

Quanto menos elementos tivermos neste primeiro momento, mais fácil será compreender o que está acontecendo.

3. IDE, compilador e linguagem não são a mesma coisa

Antes de abrir o Visual Studio, precisamos evitar uma confusão extremamente comum entre iniciantes.

C++ não é o Visual Studio.

C++ é a linguagem.

O Visual Studio é uma IDE — Integrated Development Environment, ou Ambiente de Desenvolvimento Integrado.

De maneira simplificada:

  C++
│
└── linguagem que escreveremos

  Visual Studio
│
└── ambiente utilizado para desenvolverMSVC
│
└── toolchain utilizada para transformar nosso C++ em programa executável

O Visual Studio reúne diversas ferramentas em uma única interface.

Por exemplo:

• editor de código;

• gerenciamento de projetos;

• integração com compilador;

• debugger;

• ferramentas de build;

• gerenciamento de configurações;

• análise de erros.

Isso facilita enormemente o desenvolvimento.

Mas não significa que Visual Studio e C++ sejam a mesma coisa.

Essa distinção ficará cada vez mais importante durante a série.

4. Instalando o Visual Studio Community 2022

Caso você ainda não tenha o Visual Studio instalado, utilize a edição Community 2022.

Durante a instalação, o Visual Studio Installer apresentará diferentes Workloads.

Para nossa jornada, precisamos principalmente de:

  Desktop development with C++

ou, dependendo do idioma da instalação:

  Desenvolvimento para desktop com C++

Essa workload instala os componentes necessários para desenvolver aplicações C++ nativas no Windows.

Entre eles estará a toolchain que utilizaremos inicialmente.

5. Por que não instalar tudo?

Quando estamos começando, existe uma tentação:

“Vou marcar todas as opções para garantir.”

Evite isso.

Não precisamos instalar desenvolvimento mobile, .NET, Azure, Python, Node.js e dezenas de outras ferramentas para escrever nosso primeiro programa C++.

Instalar somente o necessário possui uma vantagem didática:

sabemos qual ferramenta entrou no ambiente e por quê.

Esse princípio será repetido várias vezes durante a série.

Não adicionaremos dependências apenas porque talvez sejam úteis algum dia.

6. Criando nosso primeiro projeto

Abra o Visual Studio.

Na tela inicial, selecione:

  Create a new project

ou:

  Criar um projeto

Dependendo do idioma da sua instalação.

O Visual Studio exibirá diversos templates.

Procure por:

  Empty Project

em C++.

Podemos utilizar os filtros:

  Language: C++
Platform: Windows
Project type: Console

Nosso objetivo é começar com um projeto vazio.

7. Por que um Empty Project?

Poderíamos escolher um template que já criasse arquivos e código automaticamente.

Mas existe uma razão para não fazermos isso.

Queremos saber exatamente o que existe no nosso projeto.

Se começarmos com:

  CppGameEngine/
└── main.cpp

sabemos que main.cpp existe porque nós o criamos.

Não porque um wizard decidiu criar vários arquivos para nós.

Esse controle será útil quando começarmos a estudar organização, headers, translation units e linking.

8. Nomeando nosso projeto

Vamos utilizar:

  CppGameEngine

Esse nome pode parecer ambicioso neste momento.

Nosso projeto ainda não é uma Game Engine.

Na realidade, ainda não é sequer um jogo.

E isso é intencional.

Estamos dando nome ao projeto que evoluirá durante toda a série.

Não criaremos um projeto diferente para cada capítulo.

O mesmo código será progressivamente transformado.

Hoje:

  CppGameEngine/
└── main.cpp

Muito mais adiante poderemos encontrar algo semelhante a:

  CppGameEngine/
├── Audio/
├── Core/
├── Engine/
├── Farm/
├── Game/
├── Input/
├── Math/
├── Physics/
├── Resources/
├── Scene/
├── SaveLoad/
├── Tools/
├── UI/
└── main.cpp

Mas não crie essas pastas.

Ainda não precisamos delas.

9. Onde criar o projeto?

Como definimos anteriormente, nosso projeto acompanhará a série dentro do repositório:

  projetos_praticos_c_cpp/
└── 07_Game_Engineering_na_Pratica_CPP_SFML/

Dentro dele ficará nosso projeto C++.

Uma estrutura inicial possível será:

  07_Game_Engineering_na_Pratica_CPP_SFML/
│
├── CppGameEngine/
│
├── README.md
├── CHANGELOG.md
├── CONTRIBUTING.md
└── ROADMAP.md

Os arquivos de documentação já representam o projeto no GitHub.

Agora começaremos a adicionar software de verdade.

10. Solution e Project

Ao trabalhar com Visual Studio você encontrará dois conceitos importantes:

  Solution
Project

Ainda não precisamos estudar profundamente a estrutura interna deles.

Por enquanto, pense assim:

  Solution
   │
   └── Project

Uma Solution pode organizar um ou vários projetos.

Um Project contém arquivos e configurações necessários para construir determinado software.

Neste momento teremos apenas um projeto.

Mais adiante essa distinção poderá se tornar muito mais interessante.

11. Não precisamos resolver tudo agora

Você poderá encontrar arquivos como:

  .sln
.vcxproj
.vcxproj.filters

Não precisamos abrir cada um deles e estudar seu formato neste momento.

Essa é uma regra pedagógica importante desta série.

Saber que algo existe não significa que precisamos aprender tudo sobre aquilo imediatamente.

Hoje precisamos conseguir:

  Criar
  ↓
Escrever
  ↓
Compilar
  ↓
Executar

Quando precisarmos compreender melhor o sistema de projetos e build, voltaremos a esses arquivos.

12. Nosso projeto está vazio

Depois de criar um Empty Project, observe o Solution Explorer.

Você provavelmente encontrará categorias semelhantes a:

  Header Files
Resource Files
Source Files

Mas ainda não existe nosso programa.

Precisamos criar o primeiro arquivo.

Clique com o botão direito em:

  Source Files

e escolha:

  Add
  ↓
New Item

Selecione um arquivo C++ e dê a ele o nome:

  main.cpp

Agora temos algo concreto.

13. Nosso primeiro main.cpp

Digite exatamente:

  #include <iostream>

  int main()
{
    std::cout << "Game Engineering com C++ começou!" << std::endl;
    return 0;
}

Não copie apenas olhando rapidamente.

Se você está começando, digite.

Digitar código ajuda a perceber detalhes que passam despercebidos quando apenas copiamos e colamos.

Maiúsculas.

Minúsculas.

Símbolos.

Parênteses.

Chaves.

Ponto e vírgula.

Espaçamento.

Todos esses detalhes começarão a fazer parte da nossa linguagem cotidiana.

14. “Mas eu não entendi esse código”

Perfeito.

Você não deveria entender tudo ainda.

Existe uma diferença importante entre:

executar alguma coisa pela primeira vez

e:

compreender profundamente como ela funciona.

Hoje nosso objetivo principal é completar o primeiro ciclo.

No próximo capítulo desmontaremos esse código.

Vamos estudar elementos como:

  #include

  <iostream>

  int

  main

  ()

  {}

  std

  cout

  <<

  std::endl

  return 0;

Por enquanto precisamos apenas reconhecer que esse é nosso primeiro programa.

15. Salve o arquivo

Use:

  Ctrl + S

É um passo simples, mas vale criar desde cedo o hábito de saber o estado do arquivo que estamos compilando.

O editor normalmente indicará quando existem alterações ainda não salvas.

16. Antes de executar: configure x64

Na barra superior do Visual Studio encontraremos configurações semelhantes a:

  Debug
x64

Para nossa jornada inicial utilizaremos:

  Configuration: Debug
Platform:      x64

Se estiver aparecendo:

  x86

ou:

  Win32

configure a solução para utilizar x64.

Essa escolha poderá parecer irrelevante hoje.

Não será irrelevante quando começarmos a trabalhar com bibliotecas externas.

Imagine futuramente:

  Aplicação x64
+
Biblioteca x86

Essas duas coisas não podem simplesmente ser misturadas.

Erros relacionados a arquitetura serão estudados quando tivermos contexto suficiente para compreendê-los.

Por enquanto, padronizamos:

Windows x64.

17. E o C++20?

Também definimos C++20 como standard inicial do projeto.

No Visual Studio, abra as propriedades do projeto:

  Project
  ↓
Properties

Depois navegue para:

  Configuration Properties
  ↓
C/C++
  ↓
Language

Localize:

  C++ Language Standard

e selecione:

  ISO C++20 Standard (/std:c++20)

Observe algo importante.

Ainda não estamos usando recursos específicos de C++20 em nosso pequeno programa.

Mesmo assim, estamos estabelecendo explicitamente o standard utilizado pelo projeto.

Mais adiante veremos por que controlar a versão da linguagem é importante.

18. Debug e Release

Você acabou de encontrar outra palavra que aparecerá durante praticamente toda a jornada:

  Debug

Ao lado dela provavelmente existe:

  Release

Não vamos aprofundar as diferenças agora.

Como primeira aproximação:

Debug

Voltada ao desenvolvimento e investigação.

Release

Voltada à construção otimizada do software para distribuição.

Existem muitas diferenças técnicas por trás disso.

E vamos estudá-las.

Hoje utilizaremos:

  Debug | x64

19. Chegou a hora do Build

Agora temos código.

Mas um arquivo .cpp não é diretamente o programa que o Windows executará.

Precisamos construir nosso software.

No Visual Studio podemos utilizar:

  Build
  ↓
Build Solution

ou o atalho:

  Ctrl + Shift + B

Faça isso.

Observe a janela Output.

Se tudo estiver correto, deverá aparecer uma mensagem indicando que o build foi concluído com sucesso.

Algo conceitualmente semelhante a:

  Build: 1 succeeded, 0 failed

Esse momento é importante.

Você acabou de entregar código C++ para uma toolchain e recebeu como resultado um programa construído com sucesso.

20. Build não significa “apenas salvar”

Quando pressionamos:

  Ctrl + S

salvamos nosso arquivo.

Quando fazemos:

  Ctrl + Shift + B

estamos pedindo que o Visual Studio construa o projeto.

São operações diferentes.

Conceitualmente:

  Editar código
     ↓
Salvar arquivo
     ↓
Build

Ainda vamos descobrir o que existe dentro de “Build”.

Por enquanto basta não tratá-lo como sinônimo de salvar.

21. Nosso primeiro programa compilou

Se você recebeu:

  Build succeeded

temos nosso primeiro marco.

Mas ainda falta uma coisa.

Executar.

Podemos utilizar:

  Ctrl + F5

para executar sem iniciar uma sessão de debugging.

Faça isso.

Uma janela de console deverá aparecer.

E nela:

  Game Engineering com C++ começou!

Esse é o primeiro resultado observável da nossa jornada.

22. Pare por alguns segundos aqui

Não avance imediatamente.

Existe uma tendência muito comum quando aprendemos programação:

“Funcionou. Próximo.”

Mas vamos observar o que aconteceu.

Começamos com:

  um arquivo vazio

Escrevemos:

  #include <iostream>

  int main()
{
    std::cout << "Game Engineering com C++ começou!" << std::endl;
    return 0;
}

Fizemos Build.

Executamos.

E o computador apresentou:

  Game Engineering com C++ começou!

Pela primeira vez nesta série completamos:

  Código
  ↓
Build
  ↓
Execução
  ↓
Resultado observável

Nosso projeto agora está vivo.

Extremamente pequeno.

Mas vivo.

23. Vamos provar que somos nós que controlamos o resultado

Agora altere:

  std::cout << "Game Engineering com C++ começou!" << std::endl;

para:

  std::cout << "Meu primeiro programa C++ está funcionando!" << std::endl;

Salve.

Faça Build novamente.

Execute novamente.

Agora esperamos:

  Meu primeiro programa C++ está funcionando!

Essa experiência simples ensina uma relação fundamental:

  Código alterado
      ↓
Novo Build
      ↓
Nova execução
      ↓
Novo comportamento

Você modificou o software.

O resultado mudou.

24. Vamos fazer nosso primeiro pequeno experimento

Agora coloque duas linhas:

  #include <iostream>

  int main()
{
    std::cout << "Game Engineering com C++ começou!" << std::endl;
    std::cout << "Estamos construindo nosso primeiro projeto." << std::endl;    return 0;
}

Faça novamente:

  Salvar
  ↓
Build
  ↓
Executar

O resultado deverá ser semelhante a:

  Game Engineering com C++ começou!
Estamos construindo nosso primeiro projeto.

Agora já descobrimos empiricamente algo:

  std::cout

parece estar relacionado a colocar alguma informação na tela.

Não precisamos explicar toda a sintaxe ainda.

Primeiro observamos o comportamento.

Depois construiremos a explicação.

25. Experimente antes de continuar

Troque as mensagens.

Por exemplo:

  std::cout << "Meu futuro jogo começa aqui." << std::endl;
std::cout << "Ainda nao temos uma engine." << std::endl;
std::cout << "Mas agora temos codigo executando." << std::endl;

Execute.

Depois modifique novamente.

Não tenha medo de experimentar.

Enquanto estivermos trabalhando com um programa desse tamanho, o custo de quebrar alguma coisa é praticamente zero.

Essa liberdade é extremamente valiosa para aprender.

26. Por que estamos usando console se queremos criar games?

Porque neste momento a interface gráfica seria uma distração.

Para abrir uma janela usando SFML precisaríamos introduzir imediatamente:

• biblioteca externa;

• headers;

• libraries;

• linking;

• DLLs;

• configuração Debug/Release;

• API da SFML;

• eventos;

• janela;

• loop.

Tudo isso antes mesmo de compreendermos nosso primeiro programa.

Em vez disso, utilizaremos o console como nosso primeiro laboratório.

Ele permitirá aprender:

  C++
Programming
Compilation
Errors
Functions
Variables
Conditions
Loops
State

sem adicionar complexidade gráfica desnecessária.

Quando chegarmos à SFML, ela resolverá um problema que já estaremos preparados para compreender.

27. Mas já podemos pensar como desenvolvedores de games

Não precisamos esperar uma janela gráfica para falar de jogo.

Podemos começar a imaginar informações do nosso futuro jogador:

  Health: 100
Coins: 25
Energy: 80

Ainda não sabemos representar isso adequadamente em C++.

Tudo bem.

Em breve aprenderemos.

Depois poderemos criar decisões:

  Se energia > 0
    jogador pode trabalhar
senão
    jogador precisa descansar

Depois repetição.

Depois estado.

Depois funções.

Pouco a pouco estaremos construindo pensamento de gameplay antes mesmo de desenhar nosso primeiro sprite.

28. O que realmente aconteceu quando fizemos Build?

Talvez você esteja curioso.

Quando clicamos em Build, muita coisa aconteceu.

Uma simplificação seria:

  main.cpp
   ↓
Compiler
   ↓
Executable

Mas isso ainda esconde etapas importantes.

Mais adiante chegaremos a algo conceitualmente mais próximo de:

  Source Code
    ↓
Preprocessor
    ↓
Compiler
    ↓
Object File
    ↓
Linker
    ↓
Executable

Não precisamos memorizar isso hoje.

Na realidade, quero que surja uma pergunta:

Se escrevemos apenas main.cpp, de onde veio o .exe?

Essa pergunta nos acompanhará nos próximos capítulos.

29. Onde está nosso programa?

Quando executamos o projeto, o Visual Studio não interpreta magicamente o texto do main.cpp.

Em algum lugar existe um programa que o Windows consegue executar.

Um arquivo:

  .exe

Dependendo da estrutura e configuração do projeto, você encontrará diretórios relacionados a:

  x64/
Debug/
Release/

Não vamos fazer uma investigação completa hoje.

Mas procure.

Explore a pasta do projeto.

Veja quais arquivos surgiram depois do Build.

Compare a pasta antes e depois, se quiser.

Você começará a perceber que:

nosso código-fonte e nosso programa executável não são a mesma coisa.

Esse assunto será retomado em breve.

30. Nosso primeiro erro está próximo

Você provavelmente percebeu que o código possui vários símbolos aparentemente pequenos:

  ;

  {
}

  ()

  <<

Em C++, pequenos detalhes podem mudar completamente o significado do código ou impedir sua compilação.

No próximo capítulo começaremos a compreender essa sintaxe.

E também vamos quebrá-la.

De propósito.

Por exemplo, eventualmente transformaremos:

  return 0;

em algo incorreto.

Ou removeremos um:

  ;

E, em vez de entrar em pânico quando o Visual Studio ficar vermelho, faremos algo muito mais importante:

leremos o erro.

31. O erro não é nosso inimigo

Essa mentalidade precisa começar agora.

Durante sua jornada você encontrará:

  Compiler Errors
Linker Errors
Runtime Errors
Warnings
Crashes
Logic Bugs
Performance Problems

Eles não significam que você “não serve para programação”.

Erros fazem parte do processo de desenvolvimento.

O que diferencia progressivamente um desenvolvedor experiente não é trabalhar em software onde nada dá errado.

É desenvolver capacidade de investigar:

  O que aconteceu?
      ↓
Onde aconteceu?
      ↓
Por que aconteceu?
      ↓
Como posso confirmar?
      ↓
Como corrigir?
      ↓
Como evitar novamente?

Vamos começar a treinar isso desde os primeiros capítulos.

32. Nosso primeiro microdesafio

Antes de seguir para o próximo artigo, faça uma pequena alteração sozinho.

Partindo deste código:

  #include <iostream>

  int main()
{
    std::cout << "Game Engineering com C++ começou!" << std::endl;
    return 0;
}

faça o programa produzir:

  Game Engineering com C++ começou!
Meu primeiro projeto está funcionando.
Um dia isso será um jogo.

Não procure uma solução pronta.

Você já viu tudo que precisa neste capítulo.

Experimente.

Compile.

Execute.

Observe.

33. Uma possível solução

Depois de tentar, compare com:

  #include <iostream>

  int main()
{
    std::cout << "Game Engineering com C++ começou!" << std::endl;
    std::cout << "Meu primeiro projeto está funcionando." << std::endl;
    std::cout << "Um dia isso será um jogo." << std::endl;    return 0;
}

Execute.

Se o resultado for:

  Game Engineering com C++ começou!
Meu primeiro projeto está funcionando.
Um dia isso será um jogo.

desafio concluído.

Não foi necessário conhecer classes.

Nem ponteiros.

Nem arquitetura.

Nem SFML.

Usamos somente aquilo que já tínhamos experimentado.

É exatamente assim que os exercícios desta série deverão evoluir.

34. O estado atual do nosso projeto

No começo do capítulo tínhamos documentação e uma direção.

Agora temos código.

Conceitualmente:

  07_Game_Engineering_na_Pratica_CPP_SFML/
│
├── CppGameEngine/
│   └── main.cpp
│
├── README.md
├── CHANGELOG.md
├── CONTRIBUTING.md
└── ROADMAP.md

Ainda não precisamos de:

  Core/
Engine/
Game/
Scene/
Input/
Physics/
Audio/
Resources/
Tests/

Nosso main.cpp consegue cumprir sozinho toda a responsabilidade atual do software.

Portanto, ele continua sozinho.

Essa decisão também é arquitetura.

35. Registrando nosso primeiro código no Git

Agora temos uma alteração que merece entrar na história do projeto.

Antes de criar o commit, confira:

  git status

Observe os arquivos modificados ou adicionados.

Depois adicione os arquivos correspondentes ao projeto criado pelo Visual Studio.

Não utilizarei:

  git add .

automaticamente.

Quero que você veja o que está entrando no commit.

Por exemplo, para nosso primeiro código:

  git add CppGameEngine/main.cpp

O caminho real poderá variar dependendo de como o Visual Studio criou a estrutura física do projeto.

Confirme com:

  git status

antes de continuar.

36. Arquivos gerados não devem ir todos para o Git

Ao utilizar Visual Studio, alguns arquivos e diretórios são produtos locais do ambiente ou do processo de build.

Por exemplo, não queremos versionar indiscriminadamente tudo que aparecer após compilar.

Diretórios de build e arquivos locais da IDE normalmente devem ser ignorados.

Isso nos levará progressivamente ao:

  .gitignore

Não vamos transformar este capítulo em um estudo completo de Git.

Mas precisamos manter uma regra desde cedo:

não faça commit de tudo apenas porque o arquivo apareceu na pasta do projeto.

Código-fonte, arquivos necessários ao projeto e documentação possuem um propósito diferente de caches, binários e configurações locais.

Vamos aprofundar isso quando Git entrar formalmente em nossa trilha.

37. Nosso primeiro commit de código

Depois de verificar exatamente o que será registrado, podemos criar um commit coerente:

  git commit -m "feat: add first C++ program"

Esse commit possui significado.

Ele registra um momento específico:

o projeto passou a possuir seu primeiro programa C++ executável.

Daqui a muitos capítulos esse commit poderá parecer quase insignificante.

Mas será exatamente o contrário.

Ele será o ponto onde tudo começou.

38. Atualizando o CHANGELOG

Nosso CHANGELOG.md também pode começar a refletir a evolução real.

Dentro de:

  ## [Unreleased]

podemos acrescentar em Added algo como:

  - Added the initial C++ project;
- Added the first `main.cpp`;
- Added the first executable console application;
- Configured the project for C++20;
- Configured the initial x64 development target.

Depois:

  git add CHANGELOG.md
git commit -m "docs: update changelog with initial C++ application"

39. Atualizando o ROADMAP

Na fase inicial do ROADMAP.md, alguns itens agora poderão ser marcados como concluídos conforme aquilo que você realmente executou.

Por exemplo:

  # Fase 0 — Project Foundation

  🟡 **Status: Em desenvolvimento**- ✅ Criar estrutura inicial do projeto;
- ✅ Configurar Visual Studio Community 2022;
- ✅ Definir C++20;
- ✅ Configurar Windows x64;
- ✅ Criar primeiro `main.cpp`;
- ✅ Validar Debug;
- ⬜ Validar Release;
- ✅ Inicializar histórico Git;
- ✅ Criar README;
- ✅ Criar CHANGELOG;
- ✅ Criar ROADMAP;
- ✅ Criar CONTRIBUTING.

Só marque como concluído aquilo que você realmente validou.

Isso parece uma observação pequena, mas é uma prática importante.

Roadmap não deve ser uma lista de desejos maquiada como trabalho concluído.

Depois:

  git add ROADMAP.md
git commit -m "docs: update project foundation progress"

40. O que aprendemos de verdade?

Observe que este capítulo não tentou ensinar profundamente toda a sintaxe do nosso programa.

Mesmo assim, fizemos bastante coisa.

Agora você já teve contato com:

• Visual Studio;

• IDE;

• C++;

• MSVC;

• projeto;

• solution;

• main.cpp;

• Debug;

• x64;

• C++20;

• Build;

• execução;

• console;

• .exe;

• alteração de comportamento;

• primeiro microdesafio;

• estrutura inicial do projeto;

• primeiro commit de código.

Mais importante:

você não apenas leu sobre programação.

Você programou.

41. Onde estamos na nossa jornada?

Se representarmos nossa evolução até aqui:

  Capítulo 00
│
└── Entendemos a jornada
        ↓
Capítulo 01
│
└── Criamos e executamos nosso primeiro programa
        ↓
Capítulo 02
│
└── Vamos entender o código que acabamos de escrever

Essa ordem é proposital.

Primeiro:

ver funcionando.

Depois:

entender por que funciona.

Em seguida:

quebrar para compreender melhor.

Pouco a pouco nossa relação com o código deixará de ser:

“copiei e funcionou”

e começará a se transformar em:

“eu consigo explicar por que isso existe.”

Esse é o objetivo.

Conclusão

Hoje nosso projeto deixou de ser apenas uma ideia.

Criamos um ambiente.

Criamos um projeto.

Criamos um arquivo.

Escrevemos código C++.

Fizemos Build.

Executamos.

Modificamos.

Executamos novamente.

E registramos nossa evolução.

Ainda estamos extremamente distantes de:

  Game Engine
SFML
Renderer
Physics
Game AI
Farming System
Tests
Tools
Production

Mas agora existe uma diferença fundamental.

Temos algo sobre o qual podemos construir.

Nosso projeto começou praticamente assim:

  CppGameEngine/
└── main.cpp

Não existe motivo para sentir vergonha dessa simplicidade.

Muito pelo contrário.

Nos próximos meses, essa estrutura poderá crescer enormemente.

E quando isso acontecer, não teremos recebido uma arquitetura pronta.

Teremos acompanhado cada problema que fez aquela arquitetura nascer.

Essa é a jornada que estamos começando.

Próximo capítulo

Capítulo 02 — Entendendo o código que acabamos de executar

No próximo artigo vamos voltar para:

  #include <iostream>

  int main()
{
    std::cout << "Game Engineering com C++ começou!" << std::endl;
    return 0;
}

Mas desta vez não vamos simplesmente executá-lo.

Vamos desmontá-lo.

Vamos começar a entender:

• o que é #include;

• por que existe <iostream>;

• o que significa int;

• por que existe uma função chamada main;

• para que servem ();

• por que usamos { e };

• o que é std;

• o que é cout;

• o que significa <<;

• o que std::endl está fazendo;

• por que as instruções terminam com ;;

• o que significa return 0;

• e como o compilador começa a interpretar aquilo que escrevemos.

E então faremos algo especialmente importante:

vamos começar a quebrar nosso programa de propósito.

Porque agora que conseguimos fazê-lo funcionar, chegou a hora de começar a entender por quê.