# Should a game loop be in their own fiber?
**URL:** https://forum.crystal-lang.org/t/should-a-game-loop-be-in-their-own-fiber/350
**Category:** Offtopic
**Created:** [January 30, 2019, 8:12pm UTC](https://forum.crystal-lang.org/t/should-a-game-loop-be-in-their-own-fiber/350 "2019-01-30T20:12:45Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@girng](https://forum.crystal-lang.org/u/girng)
#### Post date: [January 30, 2019, 8:12pm UTC](https://forum.crystal-lang.org/t/should-a-game-loop-be-in-their-own-fiber/350/1 "2019-01-30T20:12:45Z")
This one is really puzzling me because I don’t know which is the correct way.
For example, two ways that I can think of:
### A. One main game loop:
- `spawn game_loop`
- game\_loop is a method that has a tick rate of **15 times a second**. It loops through all the games, **the players in those games** , sends out positional updates, hp/mp regen, etc.
### B. Each game has their own game loop
- Each time a Game class is created (new game), the class has its own `game_loop` fiber, that handles all the players in the game, hp/mp regen, etc.
I currently use option **A**. Why? I actually don’t have a definitive reason. I think one 15hz loop is enough compared to if there were 100 games open. Which would be **1500** iterations per second. _HOWEVER_, those iterations are spread out in individual fibers.
Any thoughts or insight? Thanks in advance!
---
### Author:  [@RX14](https://forum.crystal-lang.org/u/RX14)
#### Post date: [January 31, 2019, 9:37am UTC](https://forum.crystal-lang.org/t/should-a-game-loop-be-in-their-own-fiber/350/2 "2019-01-31T09:37:12Z")
Surely the same amount of work has to be done either way. So 15 iterations vs 1500 iterations, but doesn’t each of those 15 iterations take 100x as long with 100 games?
---
### Author:  [@mavu](https://forum.crystal-lang.org/u/mavu)
#### Post date: [January 31, 2019, 10:14am UTC](https://forum.crystal-lang.org/t/should-a-game-loop-be-in-their-own-fiber/350/3 "2019-01-31T10:14:50Z")
I would prefeer method B, because it is easier to split apart once you have too many games to be handled by one thread and need to start forking to use more processor cores.