
Olá a todos! Faz tempo que não escrevo por aqui, pois estive ocupado e não programando muito. Mas prometo que voltarei a trabalhar com joguinhos e coisas interessantes para que eu possa movimentar mais esse site.

Dessa vez estou trazendo um novo projeto, que comecei apenas como uma forma de experimentar TUIs (Terminal User Interfaces) e ter alguma coisa simples pra mexer de vez em quando sem ter que abrir 5 programas diferentes (Ah! o desenvolvimento mobile).

# A ideia

A ideia inicial do projeto apareceu pela necessidade de ter uma junção de:

1. Obsidian: criar, editar e organizar notas com facilidade
2. Zotero: Ler arquivos PDF e destacar trechos
3. Inverter cores de um PDF pra não perder a visão (não devíamos ter mantido no computador o padrão da cor real do papel, não foi uma boa ideia)

Seria meio que um sistema para auxiliar na condução de pesquisas científicas, principalmente de revisão da literatura, junto com um diário de pesquisa e organização de tarefas.

Sim, um escopo gigantesco não é mesmo?!

Nessa mesma época eu havia começado a estudar Go, e fiquei sabendo de uma ótima ferramenta para construir TUIs, o [Charm\_](https://charm.sh). Na verdade o Charm é uma coleção de bibliotecas com esse propósito. Sabendo da existência dessa ferramenta fiquei com uma pulga atrás da orelha querendo construir algo com ela. Depois de tantos anos mexendo com CSS puro, interfaces gráficas de Flutter baseadas em OOP, o que faltava experimentar eram interfaces de terminal. (Não me faça lembrar de quando montei UIs em Java)

Enfim, acabei reduzindo o escopo do projeto a apenas um Obsidian de terminal, que eu pudesse pelo menos ler o conteúdo de um PDF. Sendo no terminal, não seria voltado para o usuário final, mas para os estranhos que curtem essas paradas. Ainda assim, acho a ideia de um Zotero modernizado boa, e não descartarei ela por completo (realmente odeio coisas feitas em Java, e se o Zotero é feito em java, ele deve morrer).

Eventualmente, um dia qualquer sozinho numa das minhas hambúrguerias favoritas, me bateu a inspiração pra começar esse projeto, aquele tipo de inspiração que começa por: "quer saber, eu vou fazer isso agora, e semana que vem estará feito". Falhei miseravelmente.

# A primeira tentativa

Minha primeira tentativa foi muito mal sucedida, confesso. Após abrir a pasta e listar por todos os arquivos, através das funções oferecidas pelo pacote `os` da linguagem go, me vi com uma lista única de arquivos, sem a possibilidade de ter arquivos dentro de pastas, e nem pastas dentro de pastas.

Óbvio, o sistema de arquivos são armazenados em árvore, então precisaria reconstruir essa arvore de arquivos enquanto itero sobre os arquivos do diretório selecionado (no caso o diretório do próprio projeto). Mas, pra alguém que tinha estudado árvore mais de 1 ano atrás, sem nunca ter implementado nada sobre elas, a ideia ainda estava confusa.

Usando a abstração de árvore fornecida pelo Charm e muito ChatGPT, a única coisa que consegui foi uma confusão total e alguns código recursivos que não faziam sentido algum pra mim.

Nesse momento, meu pedido havia chegado e eu tinha prioridades maiores na mesa.

# Reencontro de um problema

Como havia comentado no começo desse post, ainda estou ocupado finalizando alguns detalhes do meu bacharelado, mas ao mesmo tempo, não posso deixar de programar 100%, faz parte da minha natureza.

Por isso, estava procurando algum projeto para trabalhar que não exigisse: anos de estudo de algum tópico extremamente específico (ffmpeg); nem a complexidade de um formato de arquivos de décadas de idade (PDFs); muito menos algo que fizesse meu cérebro queimar de tanta novidade e complexidade (Computação gráfica). Ao mesmo tempo procurava algum projeto que não exigisse programas ou procedimentos secundários, como abrir um servidor; abrir emuladores; game engine; dezenas de abas com documentação e perguntas do StackOverflow.

Precisava de algo direto e que eu conhecesse minimamente, pra buscar aquela sensação de realização que só a programação, a criação de algo do absoluto (mais ou menos) zero, pode trazer.

Essas ideias circularam na minha cabeça quando pensava sobre o que programar. Quando me lembrei daquele maldito problema, de arvore de arquivos, que havia me derrotado meses.

Olhando em retrospecto parecia um problema simples: é uma lista de arquivos, mas ao encontrar uma pasta, cria uma nova lista e recomeça o processo do 0. Se fizer de forma recursiva e direta fica mais fácil do que parece.

> Cabe lembrar que, entre esses meses que se passaram, trabalhei em um dos mais apressados e complicados projetos que já tive na carreira. Onde aprendi sobre a importância de ser eficaz, direto e simples. Quando vi o problema pós-projeto, parecia muito mais simples do que quando encontrei-o pela primeira vez.

# Uma segunda olhada

Revisitando o projeto me deparei com algo que não reconhecia como minha criação, mas de fato era um frankenstein: junção de códigos da documentação do Charm, códigos gerados por LLVMs diferentes, e algumas suturas entre eles de minha autoria.

Fiquei em dúvida: deveria apagar tudo e começar do zero? Ou deveria tentar salvar o que prestava (não muito). Confesso que cheguei a apagar o projeto, mas, delicadamente, recuperei-o da lixeira. Com fé de que havia algo de bom restante naquelas linhas confusas.

Infelizmente não tenho como mostrar-lhes como estes códigos se pareciam (e acho que nenhum de vocês suportaria), pois na época não havia criado um repositório para o projeto, e não compartilhei com ninguém, pois o mundo era um lugar melhor sem aquelas linhas.

Apaguei maior parte do código, principalmente referente a geração da arvore e iteração sobre os arquivos. Naquela hora, decidir que iria implementar a estrura de árvore sem nenhuma abstração ou auxílio de terceiros, iria parar e pensar sobre como resolver aquele problema. E foi uma das melhores ideias que tive.

# A solução

A melhor forma de solucionar qualquer problema é simplesmente descontruí-lo até um ponto que se saiba resolver. Se uma árvore esta parecendo um problema complexo, simplifique-a para algo mais simples: uma árvore nada mais é do que um elemento que tem vários filhos (uma lista), sendo que esses filhos podem ter outros filhos, logo, uma árvore é uma lista com listas dentro, De forma que vire um looping possivelmente infinito.

Falando assim parece até idiota ter um semestre inteiro pra estudar grafos (brincadeira, a complexidade vem em outra parte dos grafos).

Então a solução é simples: passar por todos os arquivos adicionando eles como filhos de um nó pai, quando achar uma pasta, fazer o mesmo para ela como se ela fosse o nó pai, quando chegar ao fim, insere todos os nós achados no nó atual.

Se pensar de forma recursiva fica ainda mais fácil de implementar. E explicando assim, o Renato do passado só parece ainda mais idiota por não ter solucionado isso antes do lanche ficar pronto.

# O código

Para o código criei um tipo chamado `Node` para representar cada um dos elementos da árvore, adicionei todas as informações que poderiam ser úteis para o resto do meu programa, como o caminho para o arquivo (`path`); se ele é ou não uma pasta (`isDir`) e também um ponteiro para o próprio pai (`Parent`), que pode ser usado para caminhar pela árvore de forma mais fácil e fazer algumas checagens extras caso necessário.

Além disso, tem a função principal: `walkNodeAndGetChildren`, que é bem auto-explicativa, ela passa por todos os arquivos uma pasta de um diretório x ( recebido como argumento em `dir`), cria e adiciona todos os arquivos como filhos de um nó, também passado por argumento (`node`). Caso o filho atual seja uma pasta, chamamos (`walkNodeAndGetChildren`) novamente para esta pasta.

Segue o código em Go:

```go
type Node struct {
	Name     string
	Path     string
	IsDir    bool
	IsOpen   bool
	Parent   *Node
	Children []*Node
}

func main(){
	baseDir := "."
	root := &Node{Name: baseDir, IsDir: true, Path: "."}
	root.Children = walkNodeAndGetChildren(".", root)
}

func walkNodeAndGetChildren(dir string, node *Node) []*Node {
	files, _ := os.ReadDir(dir)
	for _, file := range files {
		path := fmt.Sprintf("%s/%s", dir, file.Name())

		walkedNode := &Node{
			Name:   file.Name(),
			Path:   path,
			Parent: node,
			IsDir:  file.IsDir(),
			IsOpen: false,
		}

		if walkedNode.IsDir {
			walkedNode.Children = walkNodeAndGetChildren(path, walkedNode)
		}

		node.AddChild(walkedNode)
	}
	return node.Children
}
```

Nota-se a concatenação do diretório atual com o nome do arquivo atual na primeira linha do `for`. É uma operação simples que resolve dois problemas: criar o caminho do nó que estamos passando atualmente e conseguir o caminho para a próxima chamada da função caso o nó seja uma pasta. É um detalhe bobo, mas eu achei interessante como foi fácil fazer tudo de uma só vez depois que já tinha a lógica.

# O charme

Mas é claro que essa é só uma parte da solução e do que vim aqui apresentar-lhes. Pois o verdadeiro charme é na visualização disso tudo usando a biblioteca `Charm`.

Primeiro, para organizar tudo centralizei esse componente em um novo arquivo e estrutura chamada `FileTree`, que contem algumas informações, além de diversas funções que auxiliarão a percorrer o nossa árvore criada com tanto carinho. Segue algumas informações iniciais sobre essa estrutura:

```go
type FileTree struct {
	InitialNode  *tree.Node
	hoveringNode *tree.Node
	SelectedNode *tree.Node
}

func (f FileTree) Init() FileTree {
	baseDir := "."
	root := &tree.Node{Name: baseDir, IsDir: true, Path: "."}
	root.Children = walkNodeAndGetChildren(".", root)

	return FileTree{InitialNode: root, hoveringNode: root.Children[0]}
}
```

Nota-se, primeiro, os campos existentes nessa estrutura: `InitialNode`, que indica o pai de todos os arquivos, o nó primordial; `hoveringNode`, como o objetivo é fazer uma visualização, é importante saber sobre qual arquivo o cursor esta atualmente, guardamos ele aqui; `SelectedNode`, esse ainda esta sendo pensado, mas ele guarda o último nó selecionado para visualização, não tem tanta importância ainda.

Para navegar dentro da árvore de arquivos e alterar o `hoveringNode` corretamente, escrevi algumas funções bem interessantes para pegar o nó acima e abaixo do nó atual dependendo do contexto. A implementação atual não é perfeita (já achei alguns bugs), mas é muito interessante:

> As funções ainda estão atribuídas a estrutura `Node`, uma péssima escolha de design, mas facilmente corrigível, após finalizar esse texto ajusto esses detalhes

```go
// Navegar para cima
func (n *Node) GetNodeAbove() *Node {
	currentIndex := n.Parent.GetChildIndex(n)
	if currentIndex == 0 { // é o primeiro arquivo de uma pasta?
		// Se não tem ninguem em cima, ou é o primordial, não da pra subir
		if n.Parent == nil || n.Parent.Path == "." {
			return nil
		}
		return n.Parent
	}
	//Se esta subindo, e não é o primeiro, o próximo nó é o irmão de cima
	next := n.Parent.Children[currentIndex-1]
	// Essa parte esta dando problema, não entraremos aqui por agora
	if next.IsDir && next.IsOpen {
		return next.GetDeepestChildOpen()
	}
	return next
}
```

Começando pela navegação para cima: que código simples, apenas alguns comentários e já é possível entende-lo por completo. O primeiro passo é entender quem é o node que estamos atualmente (`n`). Ele é o primeiro nó? é o último? é uma pasta? Sabendo isso podemos tomar uma decisão sobre onde o cursor vai. Se for o primeiro nó de uma pasta, devemos subir para o pai dela (se ele existir). Se não subimos para seu irmão de cima, e se ele for uma pasta, vamos para o filho da pasta mais profunda aberta. Tandam! temos a navegação pra cima.

> A parte da pasta mais profunda ainda esta dando alguns problemas, mas espero conserta-los depois que tiver uma ordenação correta dos nós. Mas o concerto é basicamente seleciona o arquivo mais profundo, se ele for uma pasta e tiver aberto, selecionar o arquivo mais profundo dessa pasta, e assim por diante.

---

A navegação para baixo:

```go
func (n *Node) GetNodeBellow(isFirstInteration bool) *Node {
	if n.IsDir && n.IsOpen && len(n.Children) != 0 && isFirstInteration {
		return n.Children[0]
	}
	currentIndex := n.Parent.GetChildIndex(n)
	if n != n.Parent.LastChild() {
		return n.Parent.Children[currentIndex+1]
	}

	//Evitando mover caso seja o último node
	if n.Parent == nil || n.Parent.Path == "." {
		return nil
	}
	return n.Parent.GetNodeBellow(false)
}
```

Acredito que existam formas melhores de fazer ambas as operações que mostrei, mas essa é a forma que eu achei e isso que importa (até o momento que deixar de funcionar).

# O resultado

Depois de alguns ajustes de estilização do Charm (lipgloss na verdade, mas faz parte do Charm) o resultado me agradou muito, foi um dos momentos mais gratificantes que tive com programação nos últimos meses (estou a um tempo sem programar nada). Ver a minha própria arvore de arquivos feita praticamente do 0 com concatenação de strings foi como ver meu primeiro site HTML-CSS quando comecei a programar 5 anos atrás.

É incrível pensar que, mesmo depois desses anos, ainda é possível encontrar esse mesmo sentimento de gratificação, como se fosse a primeira vez, apenas fazendo coisas levemente diferentes.

Segue o resultado:

![arvore resultado](arvore-resultado.gif)
Ainda tem vários problemas com a abordagem atual, como o espaçamento que fica entre uma pasta com arquivos e os outros arquivos do pai dela (ver no gif, pois é difícil explicar em palavras). Acredito que esteja havendo alguma concatenação de um `\n` extra em algum lugar, mas não consegui identificar onde exatamente ainda.

Existe algum caso onde o resultado de `GetNodeBellow` resulta em um `nil` fazendo com que o programa inteiro quebre. Ainda preciso investigar melhor, mas acredito que seja por uma falta de "esperar" algo carregar, não tenho certeza.

Sobre o resultado do programa em sí, também tem seus problemas. O conteúdo do arquivo aberto esta sendo mostrado utilizando um viewport do bubbles (outro pacote do Charm). Contudo, esse conteúdo esta bem estranho, acredito que eu tenha cometido algum erro tentando seguir o exemplo da documentação. Preciso rescreve-lo para ver se concerto.

Além disso estou tentnao mostrar a arvore de arquivos e o conteúdo do arquivo aberto lado a lado, porém, o método `JoinHorizontal` simplesmente não faz a junção horizontal permanente, mas sim apenas estática e momentânea. Fazendo com que a arquivo de arquivos seja sobrescrita pelo conteúdo do arquivo aberto:

![bug-final](bug-final.gif)

Os outros problemas são mais relacionados a TUI do Charm, e espero que a solução seja simples.

Volto em breve com a continuação desse projeto se tiver resultados com esses casos.

Outra questão que precisa ser melhorada é a abertura de arquivos maiores, eles simplesmente quebram totalmente o programa tentando guardar o arquivo inteiro como uma string. É uma otimização interessante de realizar e provavelmente da um post por si só.

Enfim, vou ficando por aqui, até a próxima.


Arvore de arquitos em uma TUI


In this post, which is kind of a tutorial, I will show you how I [Renato](/team/renato) implemented this blog's dark theme system, how to implement it on your own with CSS only. How CSS variables work and why use CSS only for it instead of a simples package.

# Understanding CSS Variables
Like in any real programming language you can declare variables and use them, even not been a programming language you can declare variables in CSS as well. 

A CSS variable is declared using double-dash `--name` plus a semicoma and then the value of this variable:  `--example: blue;`.

These variables are created inside scopes and can only be used for those inside that scope. So if you create your variable in a `.blog-page{}` scope, it will only be available for its children.

Using a CSS variable is like calling a function `var()` with the parameter being the name of your variable. 

Look this example of the scope and use of a variable:
```css
.cool-page{
	--best-color: #382F60
}
.cool-page h1{
	color: var(--best-color)
}

.another-page h1{
	color: var(--best-color)
}
```

In the first `h1` use (*.cool-page h1*) the variable will work perfectly. But in the second one (*.another-page h1*) it will not work. Because the variable is only declared in the `.cool-page` scope.

CSS variables can be anything:
- Colors;
- Sizes;
- Fonts;
- Borders;
- Shadow;

And any kind of CSS value that can be used in CSS can be stored in variables to be used later.

When I started this website I created all my variables in the `:root` class, so every other element could use it (you can use HTML or body tag instead as well).

Another thing to notice is that you can **overwrite** variable values in another CSS element, so if you declare `--cool-color` in the *root* element, you can overwrite it inside of *body* and change the value for all those which are inside of it.

Those variables are very useful if you want to test palettes, change fonts easily, etc. So even if you are not going to a *dark-theme* implementation, I recommend you to use CSS variables.

# Making Dark Theme With CSS Only
So, you can define and use variables in all your code. If you define it all in the `:root` you can use it anywhere. Changing only one variable you will change the value for all the elements that use it.

The dark theme with CSS only is based on this idea:

> Build all your styles with variables, then, when you change the theme, change the value of all the variables.

To change these variables we can define the variables in the `body{}` element. Define your variables there and create a `body.dark{}` element as well and overwrite all the variables there:

```css
body{
	--cool-color: #382F60;
	--font-color: #2d2d2d;
}
body.dark-theme{
	--cool-color: black;
	--font-color: white;
}
```

The idea is to change the *body* class depending on the theme that you want to use.

---
If you declare all your variables and overwrite them in the `body.dark` you can already test it by adding a *class* to the *body* in your browser.

# Changing Themes Inside Next.JS
There are problems changing CSS inside *Next-JS* thus it's a server-side rendering, but it's still possible.

But first a context: I created a theme switcher on my page, and the code that I will explain now is inside this component.

---
Thus we are using Next-JS, we need to set some *useState* to manage the state of the theme. Then we can create a simple function to change the theme depending on the theme that is already set.

```jsx
 const [theme, setTheme] = useState('light-theme');

 const switchTheme = () => {
	 if(theme === 'dark-theme'){
		 setTheme('light-theme');
		 return;
	 }
	 else{
	 	setTheme('dark-theme');
	 }
 }
```

But until here we are just saving this value and not applying it in the class of the body. To do so, we will need a `useEffect()`. This *useEffect* has two reasons to be here.

The first is to let us know if the website is loaded, thus this function only executes when the website finishes the pre-load.

And the second is to know if the code is being executed in the server (during the server rendering) or during the client access.  That's why we need to have a **loaded** state. We will set this **loaded state** as *true* if the  `useEffect` execute and then we will pass to the *body* the class of the theme that we are at.

```js
 const [loaded, setLoaded] = useState(false);


 useEffect(() => {  // if we are at the client side,
	 setLoaded(true); //  set loaded as true
	 document.body.className = theme; // and add the class to the body
 });

```

If you don't use the `useEffect`, the framework might don't build the project or even don't run the page.

---
Now, when constructing your *theme switcher* you need to use this *load* variable to check if is everything allright to render (if we are at the client and if all the page has already been rendered):

```tsx
 return(
	 <div onClick={() => switchTheme()}>
		 {
			 loaded?
				[themeSwitcher]
			 : <></>
		 }
	 </div>
 )
 ```

# No Colors on Loading Problem
Thus, the code to decide the theme that is active only executes when the page loads. You may have a problem with no defined colors when your website starts to load (before the "choose theme" function be executed). To fix that you have two options:

## Option 1
Instead of creating two classes for the body `.dark-theme` and `.light-theme` you can create only one and add or remove it on the *change theme* code, instead of changing from one to another. In this way, the no-class colors will be loaded instantly.

## Option 2
You can define *general-colors* (that don't change) and main colors in the `:root` element. In this way, these *general-colors* will be loaded on start and overwritten if needed after the *change theme* code execute. This helps if you want to add more themes in the future and it's the option that I choose, mainly for readability.

```css
:root{
	--header-color: blue;
}
body.light-theme{
	/*just uses the defined in the :root*/
}
body.dark-theme{
	--header-color: black;
	/*overwrite the root color after the loading*/
}
```


# Other Methods
Of course, you could  use a package, but personally I always rather do it myself instead. In this way, you learn more about your tools and how things work.

Anyways, it's that. Any questions or advice you can send me on my [Twitter](https://twitter.com/nerat0). I always post some updates about this blog there as well. See ya!


The Easiest Way to Achieve Dark-Theme

Since I [changed the Rings project to be an isometric tower defense](/blog/a-big-turn-in-the-rings-project) , I've been having some problems with the 2D representation of things in this perspective. Why, you may ask? The thing is that the isometric view is exactly what I described—a representation of the actual 2D top-down game. However, when I started this project, I wasn't considering that isometric would entail more than just a different way of drawing. Unfortunately, this oversight has led to some coding issues

# The beginning of the problem

When I first started making changes to the project's categories, I was only thinking about the mouse interaction with the isometric tiles. So, I followed a tutorial to accomplish this and continued from there.

Initially, my focus was primarily on how the mouse was interacting with the units on those tiles. I considered aspects such as hover detection and the potential problems that could arise, such as:

- What if the unit is taller than the tile? How can I prevent the selection from going to the wrong tile?
  ![test](behind-tower-selection.webp)
- What if there's a unit positioned behind another unit? How can I select the intended one?
  ![second](unselectable-tile.webp)

These small problems overshadowed the magnitude of the challenge I was facing.

# The realization

I implemented the unit placement and deletion functionalities, created a simple targeting system, and developed a Bullet class. I was about to start working on the actual defense mechanisms that the towers would perform.

Next, I began coding the system responsible for firing at the target as soon as it entered the unit's range. However, I encountered a roadblock and couldn't figure out a simple solution. On the surface, it was just a matter of calculating the intersection of circles. Yet, inexplicably, I couldn't make it work.

To create the range ellipse, I used an ellipse since the game had an isometric view. Technically, it wasn't a perfect circle. However, I found myself attempting to calculate ellipse intersections using 2D positions, needlessly complicating everything.

Eventually, when I stopped working on the project, I started reflecting on the issue.

> The state of enemy detection
> ![current-colision](current-colision.webp)

If I have the 2D grid of every tile and the tile position of every unit, why not calculate the range intersection in the top-down view of the tiles and then convert this result later before rendering?

That's precisely what I have started implementing this week as I return to the project after almost a year.

# Let's start by looking at things

Something that has always facilitated this kind of implementation for me is the visualization of the context. Whether it's a simple `print` statement to display the behavior of a variable or even coloring a `<div>` to understand how it affects the entire website's layout (yes, that has happened).

That's why I've decided to develop a top-down debug view for the game. This will not only facilitate the new implementation but also aid in understanding future features and identifying bugs. It's currently a work in progress.

The debug view has helped me realize the issue with my current approach to the isometric perspective. I was constantly thinking in isometric terms instead of considering the underlying 2D representation. In reality, the isometric view doesn't actually exist!

I encountered significant difficulties in determining the actual 2D positions of the elements, to the extent that I had to revisit sections of the code to understand how things were placed, drawn, and recognized in the game.

Questions like how the mouse determines the tile it is hovering over, how the tiles are stored to create a grid, and how to convert coordinates into tile positions (matrix positions) prompted me to reconsider a substantial portion of our rendering and computing pipeline.

> The complexity of the current pipeline far outweighs the simplicity it is meant to achieve."

# Get a step back and rethink the pipeline

Basically, my current plan is to refactor all the isometric-related code to create a simpler pipeline that the entire game can follow, and one that can be easily modified if necessary.

I will store the tile position of every entity and transform it to isometric coordinates during rendering.

> The current debug view ![current-debugger](current-debugger.webp)

Another issue I encountered is the abundance of variables that complicate matters. For instance:

Should the `Unit` class store both `screen_position` and `tile_position`? If I only need the screen position when necessary, wouldn't it be better to transform it dynamically? I don't believe it would require excessive computing power.

```python
class Unit(Entity):
	tile_position: Vector
	screen_position: Vector`
```

---



Why am I passing the game to the `UnitManager` instance? And why did I name the parameter `window`?

```python
class UnitManager:
	def __init__(self, window):
 		self.selected_unit = None
		self.window = window

class Game:
	def __init__(self):
		self.unit_manager = UnitManager(self)
```

As I rewrite this _Top-down to Isometric Logic_, I'm likely to come across more nonsensical code here and there. But for now, that's the plan.

Now, I'll proceed to complete my top-down visualization as I once again refactor this code. Take care not to disrupt your own pipeline in your project!

The Problem with Isometric Graphics


In the [last post](/blog/the-refactoring-process-in-rings-code) I presented you the Rings project, a repository where I (Renato) started implementing some basic systems that I would use in game development in the future. First, as I said in the last post, the idea was to make a rogue-like top-down shooter, but some days ago, I decided that to keep it simple and with the least amount of complexity, Rings should be a Tower Defense game.

# The complexity thing

When you start to think about how to manage multiple abilities that interfere with one another; hundreds of bullets can collide, bounce, go back and pass through stuff. You start to think that Python and Pygame maybe is not the right choice for the job, and starting everything from zero with a new language is kind of a hard decision as well.

But now imagine a game with static units, fixed targets, simple upgrades, and a stateless game loop, you can accept Python as a decent tool for the job.

But, to add more dynamics to the game, I decided to implement an isometric style. The main idea was to bring the semi-3D perspective and the strategi feeling that this kind of graphics brings to games. The first games of **Age of Empires** used those graphics for example. And I think that this is a way to make things more challenging.

![unit_selection](age-of-empires.webp)

# New inspirations and the main idea

Since the rogue-like games exploded in the last few years, the idea is to go against this, for more strategic gameplay. Recently I played [Rogue Tower](https://store.steampowered.com/app/1843760/Rogue_Tower/), rogue-like tower-defense with voxel graphics, its a pretty fun game, but I get bored with it after the first plays, the range of builds is not diverse enough that you want to experiment with other types of stats and machines.

A game that does this part very well is [ Despot's Game: Dystopian Army Builder](https://store.steampowered.com/app/1227280/Despots_Game_Dystopian_Army_Builder/), which goes for an auto-battle (TFT vibes) with class combinations and power-ups.

So, the idea is to mess up with those concepts in a [Bloons TD 6](https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwjH36jBtbX6AhV7s5UCHYc0ALMQFnoECAsQAQ&url=https%3A%2F%2Fstore.steampowered.com%2Fapp%2F960090%2FBloons_TD_6%2F&usg=AOvVaw1Q3-OUytRLn3tVpRT1PUBm) style as well. With a variety of units each one with its purpose and class, so you can play with those kinds of combinations.

Since I'm a noobie game developer, my ideas and implementations probably will go pretty badly, but the idea is to experiment with everything before making a serious game.

# The Game so far

It's important to say that we don't have any style concept formed so far, don't have gameplay and the base of Pygame start code continues there. For the first interactions of the game, I focused on doing the isometric stuff (that is harder than it looks). Then I created an `UnitManager` to take care of the unit placement and delete.

To make the Unit selection I needed to work better on detecting which Tile and which Unit I was hovering with the mouse, It's kind of tricky but it does the job.
![unit_selection](unit_selection.webp)

I still need to improve the isometric-to-plane logic, because now I'm stuck on the code to detect if an enemy enters a unit range, and I cannot use the isometric position straight ahead, I need to make some kind of conversion. I need to calculate those collisions in the flat plane and then, only transform to isometric when needed (to draw and calculate mouse collision with units).

I made a simple shoot system just to try it out, but need to fix those collisions before showing anything.

# Some problems

Finally, as things progress it get's harder to develop some stuf, that's why we should build things different. But at the same time we need to make things work before refactoring it. Another thing that I'm facing is unit testing problems.

What, where and how to test thing in a video-game code? Should you test it with all things turned on? (like graphics) Or should you just test the intern things like sub-functions? Given that things change brutly during early development, those test can start to requiring more work then the real code, and it's kind ok to do that, since those tests hold your software together and protected from future mistakes.

Anyways, I need to start testing as soon as possible. I Will write abou testing when I make it.


Arvore de arquitos em uma TUI

Recomendations