The Struggles of Making Games
Tags: gamedev, godot
Published: 2024-07-10 19:47:07

---
title: The Struggles of Making Games
published: true
description: How gamedev is complicated
tags: gamedev, godot
# cover_image: https://direct_url_to_image.jpg
# Use a ratio of 100:42 for best results.
# published_at: 2024-07-10 18:35 +0000
---

Ok, I'll try to write this post in both [portuguese](#pt) and [english](#en). 

### <a name="en"></a> English

When I started making games around 2018, it was just for fun. I was excited about my progress with JavaScript, and the idea of using some of that knowledge to make games felt like a natural leap.

But there's more to the story.

When I was 10, I made simple games with [Game-Maker](https://en.wikipedia.org/wiki/Game-Maker) 
<small>(note that this is not GameMaker, it's Game-Maker, with a `-` in the middle; totally different products, like something Microsoft would name)</small>

At 13, I toyed with RPG Maker 2000, which was super innovative at the time. Lots of events and many small RPGs that never went anywhere. I remember trying to make one, and the best I could do was create some half-baked enemies and a nonsensical story that went nowhere.

At 15, with a good friend from my youth (who I still miss), we messed around with PHP to create a little map for use while playing GURPS.

A few years later, while talking with a coworker, we had just finished playing [Cave Story](https://en.wikipedia.org/wiki/Cave_Story), which had received a fan translation. I discovered it was made by just one person. Soon, we were discussing, "Why don't we make a game?"

This was back in 2005, almost 10 years before Godot existed and about 5 years (if not more) before anyone had free access to Unity. But the world wasn’t hopeless, and [Allegro](https://liballeg.org/) was there to save the day.

> By the way, that page looks the same as when I first saw it in 2005.

As I learned to write code in C, something I had never done before (the closest was a bit of BASIC, lots of Excel functions, and some Lisp for AutoCAD), but nothing was going to stop me from progressing.

After a few days, I had a `sprite` on the screen that I could move with the arrow keys, basically the `hello world` of any game dev!

Conversations came and went, and my coworker didn’t want to make the `sprites` for the game anymore. All I had left was a `png` file full of dreams.

In 2013, when I graduated in Industrial Design, I made a board game for my final project, one of many I created during my university years. Sadly, I shared very few with friends (something I should have done much more).

Before I knew it, it was 2018, and I was opening the newly released Godot 3. I started making little games again, and usually, the same thing breaks me: "Art."

How to make the "_Art_." I understand the process of "_design_," I can do it, and I can write code where I can understand myself well enough. But the "_art_." That I need to define.

What is "_art_"?

> The first two things that come up in the dictionary are:
> 1. The ability or skill to apply knowledge or execute an idea.
> 2. A set of means by which something can be practically realized.

And what is "_art_" for me in the context of Game Dev?

> Art is the process by which design material is converted into `assets` for a game.
> In this case, graphics, music, code, dialogues, sound effects...

Alright, if _art_ is everything that makes a game, a _game_.

**So, what’s the problem?**

The problem is that, even with effort, I still can’t reach a quality level that satisfies me. I can make music, sound effects (even if most are just _blips_ and _blops_), and I can create the pixel art that I love.

But I don’t enjoy this process. Opening my text editor to write code is fun, opening the pixel editor and designing a character is cool... but...

Animating is a pain,

Pixel art is fun, but animating is a real drag.

Composing music is cool, but man, it takes me almost an entire day to compose **one** song, and it still feels subpar.

Sound effects never bothered me; just grab some objects around the house and record with the mic, throw in tons of effects, and it’s done.

I enjoy coding, and I usually can make way more than **one** mechanic a day for my tiny games.

<center>So what to do?</center>
<center id="dont-know-en"><b>I have no idea</b></center>
<br/><br/>

But let me tell you what hasn’t worked so far:

### Writing a Game Design Document (GDD)

Of course, the process maniac here decided to put a process into making games. Many hours of planning have been done, and my list on [itch](https://shinspiegel.itch.io/) remains the same.

For every item on [itch](https://shinspiegel.itch.io/), I must have at least 3 other GDDs that never left the paper. And for every game there, I have at least 5x more material in GDD to continue the game.

What doesn’t work?

Overplanning and not seeing results.

The more I prepare, the less perceptible the results are. It just feels farther from finishing. There are always more `sprites` to be made than I have lifetime to create, always more music to be composed than I have the capacity to make.

And remember, I’m a hobbyist at this, and my drawing and composing skills are limited. (To not call it _mediocre_)

### Kanban, Trello, Jira...

No matter the type of board, it’s just a more visual way of doing a GDD, and simpler. The more information on each card, the worse; the less information on each card, the worse.

I tried putting cards with tags, colors, drawings, icons, but in the end, it’s just effort that I don’t see where it’s going, and that I could be using to write more code or make more graphics.

Between a board and a checklist, I prefer the list.

### Simple text files or Markdown?

If it’s a checklist, why not go straight to text files?

Markdown is the new `.doc` for developers, but with fewer color effects for words and no way to link to a data sheet, but it works well enough, honestly.

It works as mind map. But when it starts getting heavier than that, it loses its point, especially if you want to include time estimates or try to create a pseudo-Trello. _It doesn’t work_. Don’t try it, you’ll get hurt!

Now, if it’s just "to-do lists" or a simplified version of GDD, it "_works_" within limits.

### And the future?

So what now that I’ve compiled all the information? As I said [here](#dont-know-en), I have no idea. But all mistakes lead you forward, helping you learn and become a better dev, or in this case, a better game dev, right?

I hope so.

That’s it for today, thank you.

(()=>{})()

<br/><br/><br/><br/>

### <a name="pt"></a> Portugues

Quando eu comecei a fazer jogos em meados de 2018, era apenas uma brincadeira. Estava empolgado com meu desenvolvimento em JavaScript e pensar que poderia usar parte do conhecimento para fazer jogos foi apenas um salto natural.

Mas, existe algo que precede isso.

Quando tinha 10 anos, fazia jogos simples com [Game-Maker](https://en.wikipedia.org/wiki/Game-Maker) 
<small>(repare que esse não é o GameMaker, é o Game-Maker, com um `-` que separa o nome; produtos totalmente diferentes, parece até a Microsoft dando nome a produtos)</small>

Quando tinha 13 anos, brincava com RPG Maker 2000, que era super inovador na época. Vários eventos e muitos pequenos RPGs que nunca chegaram a lugar algum. Lembro de ter tentado fazer um e o melhor que consegui foi criar meia dúzia de inimigos e uma história sem pé nem cabeça que leva de lugar algum para lugar nenhum.

Quando eu tinha 15 anos, junto com um grande amigo de juventude (de quem sinto falta até hoje), fizemos uma brincadeira em PHP. Era apenas para ser um mapinha para usar enquanto jogávamos GURPS.

Alguns anos depois, enquanto conversava com um colega de trabalho, tínhamos acabado de jogar [Cave Story](https://en.wikipedia.org/wiki/Cave_Story), que havia recebido uma tradução de fã, e eu descobri que tinha sido feito por apenas uma pessoa. Logo entramos no assunto "por que não fazemos um jogo?".

Isso foi em 2005, quase 10 anos antes do Godot existir, e uns 5 anos (se não mais) antes de qualquer um ter acesso (gratuito) à Unity. Mas ainda assim o mundo não estava perdido, e [Allegro](https://liballeg.org/) estava aqui para te salvar.

> Inclusive, essa página continua igual desde que eu a vi pela primeira vez em 2005.

Enquanto eu aprendia a escrever código em C, algo que nunca fizera antes, o mais perto que cheguei foi um pouco de BASIC e muitas funções de Excel, além de um pouco de Lisp para AutoCAD, mas isso não iria me impedir de progredir.

Depois de uns dias, eu já tinha um `sprite` na tela e conseguia movê-lo com as setas do teclado, basicamente o `hello world` de qualquer game dev!

Conversas vão e vêm, e meu colega de trabalho não queria mais fazer os `sprites` para o jogo, e a única coisa que me restou foi um arquivo `png` com sonhos ali.

Em 2013, quando me graduei em Design Industrial, fiz como projeto de graduação um jogo de tabuleiro, um de muitos que fiz ao longo dos anos na universidade, e tão poucos compartilhei com amigos (algo que deveria ter feito muito mais).

Quando me dei conta, era 2018 e eu estava abrindo o recém-lançado Godot 3, e então comecei novamente a fazer joguinhos. Geralmente o ponto que me quebra é o mesmo: "Arte".

Como fazer a "_Arte_"? O processo de "_design_" eu entendo, sou capaz de fazer, escrever código onde consigo me entender o bastante; mas a "_arte_", essa eu preciso definir.

O que é "_arte_"?

> As duas primeiras coisas que aparecem no dicionário são:
> 1. Capacidade ou habilidade para a aplicação de conhecimento ou para a execução de uma ideia.
> 2. Conjunto dos meios pelos quais é possível obter a realização prática de algo.

E o que é "_arte_" para mim no contexto de Game Dev?

> Arte é o processo pelo qual o material de _design_ é convertido em `assets` para um jogo.
> Nesse caso gráficos, música, código, diálogos, efeitos sonoros...

Certo, então _arte_ é tudo o que faz um jogo, _jogo_.

**E onde está o problema?**

O problema é que eu, mesmo com esforço, ainda não consigo atingir um ponto de qualidade que me deixe satisfeito. Sou capaz de fazer músicas, efeitos sonoros (mesmo que a maioria sejam _blips_ e _blops_), e consigo fazer a pixel art que tanto gosto.

Mas eu não me divirto nesse processo. O processo de abrir o meu editor de texto e escrever código é divertido, abrir o editor de pixel e fazer o design de um personagem é legal... mas...

Fazer animações é um saco,

Pixel art é legal, mas fazer animações é um belo pé no saco.

Compor música é legal, mas pai amado, eu levo quase um dia inteiro para compor **uma** música, e ainda assim fica meia boca.

Efeitos sonoros nunca me incomodaram, basta pegar uns objetos pela casa e gravar com o microfone, jogar toneladas de efeitos e está pronto.

Código eu me divirto, e geralmente consigo fazer muito mais do que **uma** mecânica por dia para meus jogos minúsculos.

<center>E então o que fazer?</center>
<center id="dont-know">**Eu não tenho ideia**</center><br/><br/>

Mas deixa eu te falar o que não funcionou até agora:

### Escrever um Game Design Document (GDD)

Claro que o maluco dos processos aqui iria decidir colocar processo para fazer os joguinhos, e muitas horas de planejamento já foram feitas e minha lista no [itch](https://shinspiegel.itch.io/) continua no mesmo.

Para cada item no [itch](https://shinspiegel.itch.io/), eu devo ter pelo menos 3 outros GDDs que nunca saíram do papel. E para cada jogo ali, eu tenho pelo menos mais 5x mais material em GDD para continuar o jogo.

O que não funciona?

Planejar demais e não ver resultado.

Quanto mais eu preparo, menos resultados são perceptíveis, apenas que está longe demais de terminar. Sempre tem mais `sprites` para serem feitos do que eu tenho tempo de vida para fazer, sempre tem mais músicas para serem compostas do que eu tenho capacidade de fazer.

E lembre-se, eu sou um hobista nisso, e minha capacidade de desenho e composição são limitadas. (Para não chamar de _meia-boca_)

### Kanban, Trello, Jira...

Não importa o tipo de board, isso é apenas uma forma mais visual de um GDD, e mais simplista. Quanto mais informações em cada cartão, pior; quanto menos informação em cada cartão, pior.

Tentei colocar cartões com tags, coloridos, com desenhos, com ícones, mas no fundo, isso é apenas esforço que não vejo onde está indo, e que poderia estar usando para fazer mais código, ou fazer mais gráficos.

Entre um board e uma lista com check-list, prefiro a lista.

### Arquivos de texto simples, ou Markdown?

Se é check-list, por que não ir direto aos arquivos de texto?

Markdown é o novo `.doc` do desenvolvedor, mas com menos efeitos de cores para as palavras e não tem como conectar numa planilha de dados, mas funciona bem o bastante, sinceramente.

Funciona como organização de pensamentos. Mas quando começa a ficar mais pesado que isso, perde o sentido, principalmente se quiser colocar estimativas de tempo, ou tentar fazer um pseudo-Trello. Não funciona. Não tente, você vai se machucar!

Agora, se for apenas "listas do que fazer", ou uma versão simplificada de GDD, "_funciona_" dentro dos limites.

### E o futuro?

E o que fazer agora que compilei todas as informações, como eu disse [aqui](#dont-know), não tenho ideia. Mas todos os erros te levam para frente, te fazem aprender a se tornar um dev, ou nesse caso um game dev, melhor, não?

Espero que sim.

Isso é por hoje, obrigado.

(()=>{})()