
Yesterday (01/05/2022) we made our first reunion, sadly with only two of us personally ([Renato](/team/renato) and [Bruno](/team/bruno)) and one via Google Meet. But even in this situation, we did a lot of progress.

-   We choose a font: Robot for the body of every text (Maybe try Open Sans in the future).
-   We tried some palette colors 
-   Improve the overall CSS structure with new variables

# Choosing Fonts
To choose the font we made some kind of display of the possible options. Between the options was:

- Mukto
- Inconsolata
- Open Sans
- Roboto
- Nunito

We ended up with Roboto, just because the time was running out. Maybe I will test some Open Sans in the future


# Trying Palettes

It was a lot of fun and we are excited to improve each time more this website and write new and improved articles here.

  
Between the pallets tested we have these:

![mouse-palette](mouse-palette.webp)

---

![granito-palette](granito-palette.webp)

---

![baleia-palette](baleia-palette.webp)

---

![cimento-palette](cimento-palette.webp)

----

I liked the gray one. But will try nome others in the future, thus it's nothing defined yet. Maybe a bluer grey. 

  

To improve the palette swap I created many variables to centralize the styles of the website. In the future, I want to make a Dark Theme as well, but to do this will need to make some changes again. 

  

And to document the moment, we decided to shoot some photos *(and I made some effects by hand)*:

![painted-1](painted-us.webp)

Reunion 0.1


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.


Reunion 0.1

Recomendations