From 0f57b5f61ebcc827669d7042978541af5dd75c8f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominik=20Madar=C3=A1sz?= Date: Tue, 27 Jul 2021 19:15:04 +0200 Subject: [PATCH 1/5] meta: add an actual README --- README.md | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 64 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index dda89e6..f25ab23 100644 --- a/README.md +++ b/README.md @@ -1 +1,64 @@ -# eco2d +
+ eco2d +
+ +
+ +
+ discord +
+ +
+
+ Small C99 2D game engine with focus on prototyping. +
+ +
+ + Brought to you by @zaklaus, + @inlife + and contributors + +
+ +# Introduction +zpl.eco2d is a small framework / game engine made out of curiosity. It attempts to bridge several libraries to create a playable sandbox with ease of extensibility and with performance in mind. The goal is not to create a generic 2D game engine, but to build a prototype of a game that can be further used for various experiments. As such, + +The game runs on top of [raylib](https://raylib.com/) technologies and makes use of the [zpl](https://zpl.pw/) ecosystem alongside the **cwpack** library for data serialization. The game logic and lifecycle is maintained with the use of [flecs](https://github.com/SanderMertens/flecs/) library and its suite of tools that help us improve the development efficiency. + +It was built with networked game sessions in mind from the ground up and therefore provides 2 major ways to play the game: +* Networked game (UDP) - networked sessions benefit from the use of [enet](https://github.com/zpl-c/enet/) library. +* Local Only sessions - Data is streamed via local buffers. + +In both cases, the game engine does not differentiate between these 2 options and makes the concept of server<>client infrastructure fully abstract. Gameplay logic is only tied to living entities, where entity might happen to represent a networked client / local controller. + +All data is transferred via packets that are fully automated by our own serialization rule system, which uses the **cwpack** library in the background. + +On top of that, the game client is also capable of spinning up multiple client heads and cycle between them, which allows us to easily debug new features locally without having to physically start the server. + +In the abstract sense, we call the Server the game master hosting all gameplay rules and features, while the Client represents a terminal sending key inputs and receiving data to render. + +## Major things to do +* More believable world generation. +* Networking implementation, the communication part is done, but there's currently no way to start a headless server or connect to it anyhow. +* Improved rendering - the current world structure does not allow for layered blocks, but it's something worth looking at. +* UI and visual effects + +# Build the project +We use CMake to generate project files and manage builds. +You can do the following on the command line to create and build this project: +```sh +git clone https://github.com/zpl-c/eco2d.git +cd eco2d +cmake -S . -B build +cmake --build build +``` + +Run the following command to see all the options: +```sh +Windows: +build\Debug\eco2d.exe -? + +Linux: +build\eco2d.exe -? +``` From d12810207234394f99fe14c6e8f6880a75d28520 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominik=20Madar=C3=A1sz?= Date: Tue, 27 Jul 2021 19:16:45 +0200 Subject: [PATCH 2/5] Update README.md --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index f25ab23..e6a27d7 100644 --- a/README.md +++ b/README.md @@ -34,6 +34,8 @@ In both cases, the game engine does not differentiate between these 2 options an All data is transferred via packets that are fully automated by our own serialization rule system, which uses the **cwpack** library in the background. +Data is streamed in or out using the [librg](https://github.com/zpl-c/librg/) library, thanks to which all clients only receive data relevant to their location. + On top of that, the game client is also capable of spinning up multiple client heads and cycle between them, which allows us to easily debug new features locally without having to physically start the server. In the abstract sense, we call the Server the game master hosting all gameplay rules and features, while the Client represents a terminal sending key inputs and receiving data to render. From 945214a5e489fe24babd1afc7f6b87010125a40d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominik=20Madar=C3=A1sz?= Date: Tue, 27 Jul 2021 19:21:27 +0200 Subject: [PATCH 3/5] Update README.md --- README.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/README.md b/README.md index e6a27d7..32bd19c 100644 --- a/README.md +++ b/README.md @@ -10,7 +10,7 @@
- Small C99 2D game engine with focus on prototyping. + Small C99 2D game engine with a focus on prototyping.
@@ -22,28 +22,28 @@
# Introduction -zpl.eco2d is a small framework / game engine made out of curiosity. It attempts to bridge several libraries to create a playable sandbox with ease of extensibility and with performance in mind. The goal is not to create a generic 2D game engine, but to build a prototype of a game that can be further used for various experiments. As such, +zpl.eco2d is a small framework/game engine made out of curiosity. It attempts to bridge several libraries to create a playable sandbox with ease of extensibility and with performance in mind. The goal is not to make a generic 2D game engine but to build a game prototype that anyone can use to build various experiments. As such, -The game runs on top of [raylib](https://raylib.com/) technologies and makes use of the [zpl](https://zpl.pw/) ecosystem alongside the **cwpack** library for data serialization. The game logic and lifecycle is maintained with the use of [flecs](https://github.com/SanderMertens/flecs/) library and its suite of tools that help us improve the development efficiency. +The game runs on top of [raylib](https://raylib.com/) technologies and makes use of the [zpl](https://zpl.pw/) ecosystem alongside the **cwpack** library for data serialization. The game logic and lifecycle are maintained using [flecs](https://github.com/SanderMertens/flecs/) library and its suite of tools that help us improve the development efficiency. -It was built with networked game sessions in mind from the ground up and therefore provides 2 major ways to play the game: +It was built with networked game sessions in mind from the ground up and therefore provided two significant ways to play the game: * Networked game (UDP) - networked sessions benefit from the use of [enet](https://github.com/zpl-c/enet/) library. * Local Only sessions - Data is streamed via local buffers. -In both cases, the game engine does not differentiate between these 2 options and makes the concept of server<>client infrastructure fully abstract. Gameplay logic is only tied to living entities, where entity might happen to represent a networked client / local controller. +In both cases, the game engine does not differentiate between these two options and makes the concept of Server <>client infrastructure entirely abstract. As a result, gameplay logic is only tied to living entities, where the entity might represent a networked client / local controller. -All data is transferred via packets that are fully automated by our own serialization rule system, which uses the **cwpack** library in the background. +All data is transferred via packets fully automated by our serialization rule system, which uses the **cwpack** library in the background. Data is streamed in or out using the [librg](https://github.com/zpl-c/librg/) library, thanks to which all clients only receive data relevant to their location. -On top of that, the game client is also capable of spinning up multiple client heads and cycle between them, which allows us to easily debug new features locally without having to physically start the server. +On top of that, the game client can also spin up multiple client heads and cycle between them, which allows us to easily debug new features locally without having to start the Server physically. In the abstract sense, we call the Server the game master hosting all gameplay rules and features, while the Client represents a terminal sending key inputs and receiving data to render. ## Major things to do * More believable world generation. * Networking implementation, the communication part is done, but there's currently no way to start a headless server or connect to it anyhow. -* Improved rendering - the current world structure does not allow for layered blocks, but it's something worth looking at. +* Improved rendering - the current world structure does not allow for layered blocks, but it's something worth looking into. * UI and visual effects # Build the project From b6412033f2d2eb61cb345636891569abc40777dc Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominik=20Madar=C3=A1sz?= Date: Tue, 27 Jul 2021 19:23:27 +0200 Subject: [PATCH 4/5] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 32bd19c..c4f457f 100644 --- a/README.md +++ b/README.md @@ -22,7 +22,7 @@ # Introduction -zpl.eco2d is a small framework/game engine made out of curiosity. It attempts to bridge several libraries to create a playable sandbox with ease of extensibility and with performance in mind. The goal is not to make a generic 2D game engine but to build a game prototype that anyone can use to build various experiments. As such, +zpl.eco2d is a small framework/game engine made out of curiosity. It attempts to bridge several libraries to create a playable sandbox with ease of extensibility and with performance in mind. The goal is not to make a generic 2D game engine but to build a game prototype that anyone can use to build various experiments. The game runs on top of [raylib](https://raylib.com/) technologies and makes use of the [zpl](https://zpl.pw/) ecosystem alongside the **cwpack** library for data serialization. The game logic and lifecycle are maintained using [flecs](https://github.com/SanderMertens/flecs/) library and its suite of tools that help us improve the development efficiency. From d3099a11af40468928cc359accda532a00ca0b36 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominik=20Madar=C3=A1sz?= Date: Tue, 27 Jul 2021 19:39:43 +0200 Subject: [PATCH 5/5] Update README.md --- README.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/README.md b/README.md index c4f457f..a3105cd 100644 --- a/README.md +++ b/README.md @@ -46,6 +46,10 @@ In the abstract sense, we call the Server the game master hosting all gameplay r * Improved rendering - the current world structure does not allow for layered blocks, but it's something worth looking into. * UI and visual effects +# Media +![image](https://user-images.githubusercontent.com/9026786/127201607-936241ee-762e-4630-b52f-e75ae72c3ed3.png) +![image](https://user-images.githubusercontent.com/9026786/127201653-f0ca5626-24a9-4294-98ac-1a62aff0e1e5.png) + # Build the project We use CMake to generate project files and manage builds. You can do the following on the command line to create and build this project: @@ -64,3 +68,10 @@ build\Debug\eco2d.exe -? Linux: build\eco2d.exe -? ``` + +# License +zpl.eco2d code is licensed under the BSD 3-Clause license, as seen [here](LICENSE). + +Assets under the **art** folder are released into [Public Domain](https://creativecommons.org/share-your-work/public-domain/cc0/) unless otherwise stated. + +Third-party vendors are licensed according to their respective authors.