
A ideia desse texto começou comigo reclamando de alguns problemas (totalmente skill issues) que tive com a linguagem Odin e seus ponteiros e procedimentos, depois, tentando recriar o problema original que tive em uma versão reduzida e apresentável do código, acabei resolvendo o problema. Então o texto se tornou sobre como organizar a solução de forma que ela ficasse mais bem estruturada, com um design de software melhor de trabalhar e de expandir e alterar com o tempo.

Porém, jogos são complexos, e achar essa solução mais limpa, ou até mesmo testar outras soluções já seria um desafio extra. Dessa forma, o texto virou um incentivo pra eu estudar sobre Data-Oriented-Programming (algo que estou adiando a quase 1 ano pra estudar) e _composition_, além de outros _patterns_ que poderiam resolver o problema.

Durante o começo desse estudo, encontrei um dos posts mais interessantes que já vi na internet, onde o autor Eric Leppert trazia um exemplo simples de regra de negócio e tentava fazer essa regra ser obedecida através apenas das definições de OOP do C#.

> Ótima leitura [Wizards and Warriors](https://ericlippert.com/2015/04/27/wizards-and-warriors-part-one/) do Eric Leppert

Diante dessa leitura pensei que talvez, esse post poderia ser apenas uma demonstração, assim como a do Eric, sobre soluções problemáticas para uma regra que, inicialmente, é simples.

---

A verdade é que software design é uma das coisas que mais me encantam, sempre tive discussões intermináveis na minha cabeça sobre como eu implementaria X sistema pra ser escalável e expandível, mas nunca consegui colocar em prática essas discussões. E o Eric coloca de uma forma muito interessante. Claro que no caso dele ele já sabe a solução, e eu ainda não. Mas acho que vai ser uma boa iniciativa pra buscar esses designs melhores e soluções interessantes, além de me direcionar para concretizar as minhas ideias, sistemas e estudos.

Então aqui veremos uma das minhas primeiras tentativas implementando um sistema com uma mentalidade mais voltada para Data-Oriented-Design e Composition, onde eu falho miseravelmente, mostrando o quanto ainda tenho que aprender e melhorar.

Veremos também alguns comentários que tentam refutar as minhas próprias explicações para o que eu acho e fiz quando escrevi aquele código. Acredito que essa abordagem de aprendizado seja boa:

1. você enfrenta um problema;
2. tenta lidar com ele com o que você sabe e se frustra tentando; (este post)
3. estuda sobre possíveis soluções tendo seu problema em mente durante;
4. volta pra solucionar o problema com o conteúdo aprendido; (o próximo post)
5. se frustra de novo.
6. resolve o problema

## O Problema

Estava testando algumas abordagens diferentes do que eu geralmente costumo fazer, testando o que eu entendia sobre _composition_ e _Data-Oriented-Programming_, abordagens que tenho ouvido muito falar no meio do desenvolvimento de jogos, mas que nunca experimentei na prática.

Diante disso comecei um projeto onde tentaria implementar alguns sistemas usando o que eu estava entendendo sobre _composition_.

> Esse exemplo em questão foi desenvolvido em Odin, usando Raylib para renderização

## Estrutura Base

O que temos aqui é um sistema de _Colliders_ e _Entities_, onde a ideia é que entidades tenham _colliders_, porém não como propriedades diretas delas, evitando acoplamento.

> Na verdade essa ideia se originou de um vídeo que eu vi de otimização de memória, que me deixou super interessado em aprender sobre Data-Oriented, porém fui implementar estudos mais aprofundados sobre a teoria. O vídeo: [Intro to Data Oriented Design for Games](https://www.youtube.com/@nicbarkeragain)

A ideia então é ter sistemas, que são _arrays_ de entidades de um mesmo tipo e são responsáveis por gerenciar essas entidades e disponibilizar métodos que agem sobre os dados desse sistema. Aqui temos um `CollisionSystem` que tem uma lista de _Colliders_:

```odin
Collider :: struct {
    position: Vec2,
    radius: f32,
}

CollisionSystem :: struct {
    colliders:  [dynamic]Collider,
}

update_collisions :: proc(sys: ^CollisionSystem) {
	for i in 0 ..< len(sys.colliders) {
		for j in i + 1 ..< len(sys.colliders) {
			a := &sys.colliders[i]
			b := &sys.colliders[j]
			r := a.radius + b.radius
			if distance_squared(a.position, b.position) <= r * r {
				//colided
			}
		}
	}
}

add_collider :: proc(sys: ^CollisionSystem, collider: Collider) -> ^Collider {
	append(&sys.colliders, collider)
    return &sys.colliders[len(sys.colliders) - 1]
}

```

Também temos uma estrutura `Entity` onde guardamos os dados gerais e é o centro do nosso design, suas propriedades podem eventualmente serem convertidas para sistemas à parte quando necessário.

```odin
Entity :: struct {
    name: string,
    position: Vec2,
    collider: ^Collider
    color: rl.Color,
}
```

## A Primeira implementação - O problema do ponteiro

A ideia inicial era que a entidade tivesse um ponteiro para seu _Collider_ de forma que ela pudesse muda-lo quando precisasse, como fazer o _collider_ seguir a posição dela. A primeira implementação ficou mais ou menos assim:

```odin
player_collider := Collider {
	position = player.position,
	radius   = 30,
}

enemy_collider := Collider {
	position = enemy.position,
	radius   = 30,
}

player.collider = add_collider(&collision_system, player_collider)
enemy.collider = add_collider(&collision_system, enemy_collider)

//Durante o update
player.collider.position = player.position
enemy.collider.position = player.position

update_collisions(&collision_system)
```

Esse exemplo funciona bem até adicionarmos mais _colliders_ na lista, quando eventualmente o _garbage collector_ limpa todos os ponteiros existente (ou algo do tipo) e o `player.collider` passa a ser um ponteiro invalido. Então quando ele tenta atualizar seu próprio _collider_, boom!

```
post(46201,0x16bf23000) malloc: Heap corruption detected, free list is damaged a
t 0x600000f8bf90

*** Incorrect guard value: 0
post(46201,0x16bf23000) malloc: *** set a breakpoint in malloc_error_break to de bug
```

Logo, ter um ponteiro na entidade para o seu _collider_ não funciona, pelo menos não dessa forma. Talvez um `raw pointer` seria o correto a se utilizar aqui, mas isso leva a outros problemas e dificuldades também.

## A Solução para os Ponteiros Perdidos

Dessa forma, como não podemos apontar diretamente para o nosso _collider_ temos que achar outra forma de acessar esse _collider_. A solução mais óbvia é armazenar, na entidade, o índice do *collider* correspondente da lista do `CollisionSystem`.

Assim temos uma forma fácil de acessar o elemento em questão que não depende de funcionalidades internas da linguagem que não temos controle. A única desvantagens é se tivermos algum tipo de ordenação na lista, e como isso não existe ainda, não temos com o que se preocupar.

```odin
Entity :: struct {
    name: string,
    position: Vec2,
    color: rl.Color,
    collider_index: int,
}

add_collider :: proc(sys: ^CollisionSystem, collider: Collider) -> int {
	append(&sys.colliders, collider)
	return len(sys.colliders) - 1
}

// cria colliders...

player.collider_index = add_collider(&collision_system, player_collider);
enemy.collider_index  = add_collider(&collision_system, enemy_collider);


// [Durante o update]
// Atualizar posição do collider com base na entidade
collision_system.colliders[player.collider_index].position = player.position;
collision_system.colliders[enemy.collider_index].position = enemy.position;

update_collisions(&collision_system)

```

Essa implementação já resolve o nosso problema de perda de ponteiros, apesar de limitar a nossa capacidade de manusear a lista de _colliders_. Porém, como o sistema de colisão não sabe nada sobre a entidade, não temos como manipular ela durante um callback de `on_collide()` por exemplo. Como poderíamos, por exemplo, empurrar o nosso jogador para trás quando ele encostasse em um inimigo?

O que poderia ser feito é inverter essa lógica: O colisor sabe da entidade, e a entidade é dependente do colisor, mas isso só levaria ao mesmo problema, porém invertido. E é ai que os problemas da minha ignorância sobre esses padrões começam a aparecer mais.

## Quem Aponta para Um, Aponta para Dois

Pedindo uma ajudinha pra IAs Generativas, foi indicado a seguinte solução: a adição de um `raw-pointer` no meu _collider_ que aponta de volta para a entidade.

> Essa solução me da arrepios sempre que penso sobre ela. Mostrando como LLMs podem te direcionar para a pior solução de todas.

```odin
OnCollideProc :: proc(ctx: rawptr, other: ^Collider)

Collider :: struct {
	position: Vec2,
	radius:   f32,
	ctx: rawptr,
	on_collide: OnCollideProc,
}
```

Porém, isso leva a necessidade de alguns _casts_, o que não me parece muito interessante a longo prazo:

```odin
player_collider := Collider {
	position = player.position,
	radius   = 30,
	ctx = rawptr(&player),
	on_collide = proc(ctx: rawptr, other: ^Collider) {
		entity := cast(^Entity)ctx; //cast :(
		entity.color = rl.YELLOW;
		fmt.println("{} colidiu com algo!", entity.name);
	},
}
```

## Isso funciona (?)

Claro, essa solução "funciona", mas nem sempre funcionar é realmente _funcionar_! Fazer um `is_odd` usando a negação da função `is_even` do pacote `is_even` em javascript também funciona, mas não deveria ser aceito como uma solução valida, assim como essa também não deveria.

Outro detalhe: essa solução "funciona" para o player, mas não para os _enemies_, o `on_collide` entre os inimigos simplesmente não funciona, pois estamos nos referindo a uma cópia do inimigo e não ao inimigo mesmo. E transformar a lista de inimigos em uma lista de ponteiros para inimigos não da certo (eu testei).

---

A questão aqui é: o quão granular deve ser a composição de elementos? O certo seria ter um _collider resolver_ que seria responsável por lidar com o resultado das colisões, e este cara saberia da entidade e do colisor? Talvez ninguém deveria saber sobre ninguém e um terceiro deveria cuidar de tudo?

Pesquisando um pouco sobre essa questão vi algumas sugestões de que tudo deveria ser vetores/arrays de _structs_ (inimigos, entidades, posições, acelerações) de forma bem granular, e a entidade deveria guardar o índice para cada um desses componentes. Mas isso ainda não resolver diretamente a influência que a posição da entidade tem no _collider_ vice-e-versa.

Diante disso, decidi parar e estudar as soluções existentes, e buscar algo que fosse simples, funcionasse e fosse de fácil utilização/implementação.

## Conclusão

A verdade é que não vale a pena tentar reinventar a roda sendo que existem soluções que já foram encontradas, debatidas, testadas e utilizadas no mundo real. Se frustrar tentando é só um exercício pra colocar a mão na massa e se interessar e bater de cara com o problema.

Dito isso, vou estudar algumas soluções mais simples que são implementáveis aqui, nada muito distante e complexo como um ECS (Entity-Component-System) por enquanto. Vou tentar trazer algumas dessas soluções pra cá e comentar sobre o que acho delas. Mas me anima imaginar o quão praticas elas podem ser.


Minha primeira tentativa com Data-Oriented em Game-Dev

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.


A Big Turn in The Rings Project


Hi There! I would like to introduce to you one of my (and Back to Pixels) project **Rings**. And perhaps show some big refactorings
that I did some days ago.

# Presenting Rings

Rings is a pygame video-game project that initially was inspired by [Enter the Gungeon](https://enterthegungeon.com) and [Nuclear Throne](https://nuclearthrone.com) (even the sprite animation test was done using its sprites). But with time (and some studies) I realized that this scope was too big for my first game, and by the time I was pretty into [Vampire Survivors](https://store.steampowered.com/app/1794680/Vampire_Survivors/), so I decided to redirect Rings to be a "stand-still" rogue-like game. Aiming to try some video-game software architecture and push to the limits that python can do as a game development language!

> The name rings was referring to the upgrades in the game, that would be rings that you could use, a maximum of 10.

But a complete game is still a big scope for someone that studies and has a full-time job. So, my current idea is to develop each feature of a simple game development framework just to experiment with some module architectures.

And here today I will show you what was _Rings_ was before and after some cool structural changes that I made based on some simple things that I've learned recently.

# How It Was and Where it is Going

Since I'm just developing feature to feature, my architecture thing was not that important, so I kept the code struct as the simple pygame tutorial would give you, which is, extremely bad, but with the simple _check-events_, _update entities_, _render entities_ order.

But after seeing some [DaFluffyPotato](https://www.youtube.com/c/DaFluffyPotato) live streams I start to recognize a pattern in his code. He put everything into a _Game_ class, and passes this game class to everyone inside it (this part is pretty dangerous but ok), and inside this class, he has a _world_ attribute (of the class World) and an _Input_ attribute (of the class Input) and so on for every major thing in his game. He also had some classic structs such as a list of _entities_ and a list of projectiles.

Anyways, this architecture can help a lot such in debugging (because um can tear apart things easily) and in modularity.

So that's where I aimed to when refactoring Rings for (almost) the first time.

# Some Bad Code

Here I will show you how the code was (it is a little bit longer, so maybe I will change it in the future)

```python
configs = json.load(open('config.json'))

pygame.init()
pygame.mixer.pre_init(44100, -16, 2, 512)
pygame.mixer.set_num_channels(32)
pygame.display.set_caption("Rings")
pygame.mouse.set_visible(False)

FONT = pygame.font.Font("res/Pixellari.ttf", 22)

global debugging
game_time = 0
base_screen_size = configs['resolution']
screen = pygame.display.set_mode(
	(base_screen_size[0],base_screen_size[1]),0,32
)
display = pygame.Surface((300,200))
clock = pygame.time.Clock()
screen_real_size = display.get_size()
camera = Vector(0,0)

player = Player(Vector(10,10))
player.load_animations()

TILE_SIZE = 20

game_map = [...]

cursor_img = pygame.transform.scale(
	pygame.image.load('res/mouse.png').convert(), (44, 44)
)

cursor_img.set_colorkey((255, 0, 0))

camera_speed = 20
debugging = True
running = True

while running:

	for event in pygame.event.get():
		check_events(event,player)

	mx, my = pygame.mouse.get_pos()

	true_mx = mx
	true_my = my

	mx -= (screen.get_width() - base_screen_size[0]) // 3
	my -= (screen.get_height() - base_screen_size[1]) // 3
	mx /= base_screen_size[0] / display.get_width()
	my /= base_screen_size[1] / display.get_height()

	camera.x = player.position.x + 7 - screen_real_size[0] /2 # the +7 is half of the size of the player, to certralyze
	camera.y = player.position.y + 7 - screen_real_size[1] /2

	player.is_not_walking = not player.is_moving_right and not 		player.is_moving_up and not player.is_moving_down and not player.is_moving_left


	scroll = camera
	scroll.x = int(scroll.x)
	scroll.y = int(scroll.y)

	display.fill((30,30,30))

	collision_tiles = []
	tile_rects =[]

	y = 0

	for row in game_map:

	x= 0

	for tile in row:
		#<big tiles logic and draw>
		for t in row:
			#<more logic and draw world stuff>

	player.update(mx, collision_tiles,camera)
	player.draw(display,debugging)

	screen.blit(pygame.transform.scale(display, base_screen_size),

	((screen.get_width() - base_screen_size[0]) // 2,

	(screen.get_height() - base_screen_size[1]) // 2))

	screen.blit(cursor_img, (true_mx // 3 * 3 + 1, true_my // 3 * 3 + 1))

	if debugging:

		utils.draw_text(FONT, "FPS: " + str(int(clock.get_fps())), screen, (10,10))

	pygame.display.update()
	clock.tick(60)
```

> I removed some unnecessary parts

# Some less-bad code

```python
class Game:
	_entities: list
	game_time: int
	player: Player
	window: Window
	world: World
	mouse: Mouse
	camera: Camera

	def __init__(self):
		configs = json.load(open("config.json"))
		self.window = Window(configs)
		self.mouse = Mouse(self.window)
		self.world = World()
		self.player = Player(self)
		self.player.load_animations()
		self.camera = Camera(
				self.player,
				self.window.screen_real_size
		)


		self._entities = []
		self._entities.append(self.player)
		self.running = True
		self.clock = pygame.time.Clock()
		self.FONT = pygame.font.Font("res/Pixellari.ttf", 22)


	def update(self):
		self.world.update()
		self.mouse.update()
		self.camera.update()
		for entitiy in self._entities:
			entitiy.update()

		pygame.display.update()
		self.clock.tick(60)

	def draw(self):
		self.window.display.fill((30, 30, 30))
		self.world.draw(self.window.display, self.camera.position)

		for entitiy in self._entities:
			entitiy.draw(self.window.display, self.camera.position)


		self.window.blit_displays()
		self.mouse.draw(self.window.screen)

	def run(self):
		while self.running:
			self.check_events()
			self.update()
			self.draw()

game = Game().run()
```

Even with this "better" code, there are always things to improve everywhere. Such as an Input class to handle all the input commands and logic (that I hid in this example), or some particles and sound managers (that I didn't implement yet).

As Uncle Bob says in "Clean Architecture":

> Good (clean and well architectured) code, should look like a well-written poem

The new rings architecture looks like some Ok poem, but I think it could be better, mainly in the _Player_ class (the animation system is kind of messed up). In the end, all I did was hide things properly and reallocate them where they should be.

All the world logic and drawing are inside the _World_ class, for example, and the same thing applies to all the other pieces of the game. It's clear that I don't have much to organize, but it was a good starting point to do all these refactorings.

# What Rings have until now?

Rings started as an experiment, just me trying to implement some cool game-development features. So, the project doesn't have much, just some split, badly implemented simple features, like particles, animations, collisions, and sparks (that I just copied from DaFlufy). But those simple things that I have will be re-write and documented here in the future.

For now, the game looks something like this:

![game-screen-shot](game-screen-shot.webp)

> I used the Nuclear Throne animation to test some stuff ;)

# Conclusion

As I said, Rings are only the start, and I pretend to turn it into a simple rogue-like game, and that's some of the things I will bring her to the game-studio blog.

I will bring some cool implementations and mainly focus on game-design architecture.

Hope you like it and Thanks for reading! You can follow all **Rings** articles in [tag/rings](/blog/tag/rings)

You can check out this project on my [RenatoCesraF/Rings](https://github.com/RenatoCesarF/Rings)


4

Posts in the category Game Dev

Posts in the category