| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
During this iteration, with some few features, I realized that the current Core architecture doesn't allows (or is very difficult) to add some required features for a game engine (especially for the Editor) so I decided that we should remake the Core architecture with some stuff in mind. It also means that the language could totally change (from c++17 to rust, zig, c++26, c#) but it must be discussed.
Important
I'm currently passively searching for collaborators to remake the Core of the project. If you interested, don't hesitate to poke me on Discord, here is my discord id: "miouzora".
Here is some elements I found that we should take in account:
Full Changelog: 0.3.4...0.3.5
During this release, not many things were done because of the work of the dynamic plugins. As I said in the previous release, dynamic plugins required 3 new kinds of schedulers: StartingUp, Running, ShuttingDown. But while spending most of my time on it, I realized it added too much complexity and rigidity to the engine and I ended up closing the branch of the implementation of the feature again. Tbh I kinda feel sad about it but I made another step in the editor creation which is non-negligible data that could be used later. You can see this PR to get more information about it.
But something was added to have a better project creation process which is project templates.
You can now create and work on a project using 2 simple commands which are:
xrepo add-repo engine-squared-xmake-repo https://github.com/EngineSquared/xrepoxmake create -l c++ -t engine-squared YOUR_PROJECT_NAMEBy doing that you will be able to create a basic project with integrated folder architecture and tests. No more "look at examples and tests to understand the project".
Full Changelog: 0.3.3...0.3.4
During this release I planned to do a lot of different tasks but starting with the most important one: dynamic plugins. This is needed in multiple contexts: cross-language execution, fast iteration development, the editor. But this feature raised a looooot of questions as I put in this diagram which is the main explanation of the delay of planned issues. The main question here, is "how to cleanly update a plugin?" and, for now, it would be with StartingUp, Running, ShuttingDown states. Those states would be used inside schedulers to know which systems should be called.
This release also allows to avoid cloning the whole repository to be able to use it as you can see here.
Full Changelog: 0.3.2...0.3.3
This PR wasn't that big and contains only few utilities with an addition of a codebase improvement tool (clang) and some documentation improvements. During this release, the major stuff done is the creation and "brainstorming" around the editor that you can find here with some stuff about it here. Sadly a lot of questions are not shown as I don't know where to put them to make it easy to draft quickly, that's the reason why I'm doing it currently locally. Some stuff are very important for me as the Editor is a very big project and MUST follow the philosophy of the engine.
Full Changelog: 0.3.1...0.3.2
This release mainly adds documentation (important ones) like how to use tools or how to do a release or ADR. Also, some modifications were made to the readme file. And a definition of usage of AI inside the project was defined (here). Something that wasn't present before, so some stuff inside the repository will be against it but is subject to change when updating the project.
Full Changelog: v0.3.0...0.3.1
This release marks two big changes in the evolution of Engine²: the goals and the organization.
The goals of the project change: from a game engine focused on making realistic physics with appealing graphics for vehicle games to having a completely free engine design. And here, “free” has multiple meanings:
Engine² makes you able to understand it, use it, and contribute to it easily—for you, artists. Any kind of artist should be able to take the project in their hands and make stuff with it. If you are an engine programmer, game designer, sound designer, tool programmer, and so on, you will have the possibility to create and express yourself. And as I like to say: “For me, the quality of a game is reflected in the messages it conveys.”
Engine² is not made to create realistic games nor small arcade ones. This project is made to help you create any kind of project. If you want to make something, you will be able to do it. Anything is possible.
Engine² will not force you to spend any money to use any of the services it provides. It’s 101% free to use.
Engine² makes every process, planning, and evolution visible and understandable by the community. The point here is to know the priorities of the engine, its direction, and to let the community impact most of the engine.
Before, we had a very specific planning method named “Die&Retry” (D&R), which worked pretty well for a school project scale, but as Engine² grows, it is now too time-consuming for the new goals, especially since we went from four to one contributor in the project.
For reminder, the “Die&Retry” planning method comes from agility and sprints. It is composed of two kinds of sprints: “Game” and “Engine” ones.
The goal here is for the first sprint to make a very, very simple game in a short period of time using user tools and requirements (fast shipping, AI-driven implementation). While making this game, no engine modification must be required, and everything must be implemented in the game repository. It verifies the engine in a real user experience context and allows us to face the same questions and frustrations.
After the first sprints, we make a postmortem of the game: what worked, what didn’t, what should be easier to make in the engine. From all feedback found, everything can then be thought out for the engine: structured, built, tested, and shipped. This part requires more time than the first one since everything should be thought through to work and be well integrated with the engine.
This method was used two times during v0.1 and v0.2 with the games Rolling-ball and ES-RS, and it worked pretty well. For example, the first one gave us 21 feedbacks of very different sizes, from “add a shutdown system for the window plugin” to “remake the whole camera plugin.” But now Engine² has new goals that can’t be fulfilled only by this method.
Some things are now more prioritized, like having a well-documented and accessible project or having an editor. Those cannot be targeted through a D&R method. So I will take another path that corresponds to classical sprints. As I don’t really know the perfect amplitudes of sprints, I will start with sprints of two weeks. Considering some other transversal stuffs, I will try to express the planning through issues and GitHub projects that you can find here, here, and here. This will be done through the usage of AI, which I will try to use as best as I can. No implicit choices about the usage of AI. I will use it and try my best with it. Don’t hesitate to tell me through issues or Discord how I should improve stuff like those.
Full Changelog: v0.2.1...v0.3.0
Full Changelog: v0.2.0...v0.2.1
Full Changelog: v0.1.1...v0.2.0
Full Changelog: v0.1.0...v0.1.1
| Back | FazBrowse Home | New Git URL |