diff --git a/docs/IDEAS.md b/docs/IDEAS.md
deleted file mode 100644
index 679f859..0000000
--- a/docs/IDEAS.md
+++ /dev/null
@@ -1,8 +0,0 @@
-- Naturschuetzer in einem Brachland
-- Jahreszeiten -> mehrere Generationen von Bienenstaemmen
-- Kasten sauber machen
-
-- 1. Samen saehen
-- 2. Zuckerwasser aufstellen
-- 3. Kaesten aufstellen
-- 4. Baueme pflanzen
\ No newline at end of file
diff --git a/docs/roadmap.md b/docs/roadmap.md
deleted file mode 100644
index 2465c55..0000000
--- a/docs/roadmap.md
+++ /dev/null
@@ -1,11 +0,0 @@
-- [x] enums for other assets
-- [ ] Player animation for tools and switching
-- [ ] Timer Class (init, activate, deactivate, update) for the engine and for player animation with tools 53:50 https://www.youtube.com/watch?v=T4IX36sP_0c&t=1924s
-- [ ] Change UI textures
-- [ ] Change Map texture and change to non procedural map (Tilemap with tiled and tmx)
-- [ ] Gameplay UI 
-- [ ] Init values should be stored in a seperate file and loaded. When clicking new game game should reload all init values
-- [ ] Create layers enum and render layers in their order. removes code order rendering. Group same layer (z) height object in one layer
-- [ ] Fix asset include rotation temporary fix with 180
-- [x] Custom Font and Title in Menu
-- [ ] Cursord logic can be moved from game and menu to main but deactivatet at logo
\ No newline at end of file
diff --git a/docs/style.md b/docs/style.md
deleted file mode 100644
index a1bfcbf..0000000
--- a/docs/style.md
+++ /dev/null
@@ -1,107 +0,0 @@
-
-# Coding Style Guide
-
-This document outlines the coding style and conventions to be followed.
-
-## 1. **File Structure**
-
-- Header files should be wrapped with include guards to avoid multiple inclusions:
-  ```c
-  #ifndef PHYSICS_H
-  #define PHYSICS_H
-  ...
-  #endif // PHYSICS_H
-  ```
-
-## 2. **Naming Conventions**
-
-- **Functions:** Function names should use `CamelCase` starting with a upercase letter.
-  - Example: `UpdatePhysicsDirection`, `UpdatePhysicsVelocity`
-
-- **Structs:** Struct names should use `CamelCase` starting with an uppercase letter.
-  - Example: `Physics`
-
-- **Variables:** Use `CamelCase` starting with a lowerase letter for local and parameter variables.
-  - Example: `vector`, `newSpeed`
-
-## 3. **Function Design**
-
-- Functions should be named descriptively, indicating the purpose or action performed.
-  - Example: `UpdatePhysicsDirection`, `UpdatePhysicsVelocity`
-
-- Functions should take pointers when modifying variables outside their scope.
-  - Example: `void UpdatePhysicsDirection(Vector2 *direction, Vector2 vector)`
-
-- Ensure function parameters have clear names to indicate their role.
-  - Example: `UpdatePhysicsVelocity(Vector2 *velocity, Vector2 *direction, float *speed)`
-
-- Functions should be concise and focused on a single task. Avoid functions with multiple responsibilities.
-
-## 4. **Struct Design**
-
- - Prefer composition, where structs are composed of other structs or primitive data types. This allows for more flexible and modular designs.
-   - Example:
-   ```c
-   typedef struct {
-    Vector2 position;
-    Vector2 direction;
-    Vector2 velocity;
-    float speed;
-    } Physics;
-   ``` 
-   Here, instead of trying to create a hierarchy of structs, we compose a Physics struct with relevant fields like `position`, `direction`, and `velocity`.
-
-## 5. **Indentation & Formatting**
-
-- **Indentation:** Use 1 tab for indentation. Never use spaces.
-  
-- **Spacing:** Place a single space after keywords like `if`, `for`, and `while`, and around operators (`=`, `+`, `-`, etc.) for readability.
-  - Example: `*velocity = Vector2Scale(*direction, *speed * GetFrameTime());`
-
-- **Braces:** Use braces `{}` even for single-line blocks for consistency and future-proofing. 
-  ```c
-  if (condition) {
-      do_something();
-  }
-  ```
-
-## 6. **Pointer Usage**
-
-- Use pointers when passing large structures or when modifying variables outside the scope of the function. 
-  - Example: `Vector2 *position`, `float *speed`
-
-- Avoid unnecessary dereferencing and use `*` clearly to indicate pointer dereferencing.
-  - Example: `*position = Vector2Add(*position, *velocity);`
-
-## 7. **Consistency in Function Calls**
-
-- When calling functions, parameters should be passed clearly, and care should be taken to avoid modifying data unintentionally unless needed.
-
-- Example:
-  ```c
-  UpdatePhysicsDirection(&physics->direction, direction);
-  UpdatePhysicsVelocity(&physics->velocity, &physics->direction, &physics->speed);
-  UpdatePhysicsPosition(&physics->position, &physics->velocity);
-  ```
-
-## 8. **Comments and Documentation**
-
-- Strive for clarity through descriptive naming and simple logic.
-- Add comments to explain non-obvious logic, design decisions, or complex algorithms.
-- Do not state the obvious; let the code speak for itself where possible.
-
-## 9. **End of File**
-
-- Always ensure that header files end with the appropriate closing include guard and a new line after the last line of code:
-  ```c
-  #endif // PHYSICS_H
-
-  ```
-
-## 10. **General Rules**
-
-- **Modular Design**:  Break code into small, focused functions and modules with clear interfaces.
-- **Refactoring**: Regularly refactor code to maintain simplicity and performance
-- **Don't Repeat Yourself**: Reuse code by creating helper functions to avoid duplication
-- **Avoid magic numbers:** Use constants or defines instead of hardcoded values.
-- **Code readability:** Prioritize code readability and maintainability over shortness or cleverness.
\ No newline at end of file