# GameFrame Discussion

# I. Very important decission

Is the game gonna be used as:

* Library?
* **Pro:** More independent, faster build time, way less code
* **Cons:** Users must still rebuild the game loop
* Framework?
* **Pro:** Dependent, users have little control over game flow, more flexibility (source code is provided)
* **Cons:** Harder to work with, longer compile-time especially when rebuilding
* Both?
* A library that is wrapped by an external framework as a game example upon which user can build their game?

> I think personally I prefer a framework that is already familiar to me

Libraries are nice, however except for callback there is really no way to change their implementation as far as I know, so users are likely to have to build their main game loop, event handler, ... again every time they use the lib, and are likely to develop their own framework.

# II. Events

## 1. What does an event system of a game engine require?

Here, we only discuss machine events such as mouse and keyboard inputs, window resizing, .... Player's death, enemy's spawn and such are not included.

* Event must be used to get user's input (of course)
* Possible to save the events to a file and play them back (hard to get right, though), most likely for debugging only
* How to deliver events to game objects modularly and efficiently?

> A scene graph with Node::handleEvent(Event&) would work, but is it too low level? Normally, only a few game objects need the events information that happened outside of the game world. And I feel like giving the extra window events information to the whole scene is inappropriate. How about this? Imagine the events data stay on the sky and game objects are under the ground. Whatever object needs the information (for example, player controller - which can either be a game object or an `ECS::System`) will register to the "sky" and get notified. Ideally, the "sky" we are referring to does not expose the raw events, and also wraps the events into something more world-related, such as `REGISTER_KEY_PRESSED` or `WORLD_SIZE_CHANGED`.

* You said events should be ideally `int` or such. I think it will meet its downfall when we need to identify the event type. Eventually, we will have to cast them to enum or string for identification in order to be able to refer to the event type in source code (unless you go brute force and callback() every event, then the identifiers lie in functions naming)

## 2. Implementation

I have been researching and then found 2 ways for events to be called: immediately, via callbacks (like in `glfw`) or saved inside a queue containing a struct with event identifier and data (like in `SFML`). In my humble opinion the callback and the way we process the event is pretty the same concept. **However**, imagine when we need an event A at 2 different places with different purposes. One single callback cannot satisfy both, right? On the other hand, if a light class containing data is provided then the processing can be arbitrary.