numpad / ecs-sandbox Goto Github PK
View Code? Open in Web Editor NEWExperimental game-engine sandbox using OpenGL and ECS.
Experimental game-engine sandbox using OpenGL and ECS.
We need a generic interface to work with, this should provide the foundation for:
terrain feels to simple just floating in the air, remove the void by adding a water (or something similar) plane.
Player should be able to have conversations with NPCs.
Dialogs are for example:
Currently the timestep/framerate is unrestricted if vsync is disabled.
See: Fix your timestep
To get a real understanding what the engine currently can handle and what still needs to be done I want to create a small minigame to test its limits.
To make it easier to develop in the beginning:
Some ideas to make it more interesting later on:
Juice:
Sometimes about 1 in 4 chunks is not rendered on a few devices,
Seems to be consistent per device.
Normal rendering in the billboard_instance_frag.glsl
shader is not working.
Loading screen with progress rendering while dungeon is generating.
Fix builds, libraries.
Currently builds are working fine on my setup. Improve this to work on all systems with the least amount of work for the end user.
CMakeLists.txt
to use vcpkg librariesREADME.md
Basic deferred shading is implemented, but the current implementation is far from optimal. I need to think about the data we need in the G-buffer, how we actually lay it out to stay efficient and especially how we organize this in code.
Todo:
Challenges:
Instead of depth sorting entities based on their CPosition on the CPU before rendering back-to-front we could remove the sorting and simply discard
all pixels of a CBillboard which are transparent.
Pros:
Cons:
[0] : Still need to benchmark this on low and high end systems. But less work on the CPU would definetly be benefitial
[1] : Semi-transparency can be made possible again, but requires work (two systems, one for semi-transparent billboards and one for "fast" billboards) and coordination between those two
The G-buffer currently contains world space position (rgb16f) data. This is redundand as the data can be reconstructed form the depth buffer.
Additionally, by storing the world space position we will run into precision problems at some point.
Create a document/graphic/... of some sort to describe the components, systems and events used.
Per system:
Per component:
Per event:
[1]: Is ExO important? F.ex. RenderSystem depends on data from PositionUpdateSystem, otherwise every rendering would be a frame too late.
Add a overworld where the player has his personal space.
features should include:
The current AssetManager implementation is very basic; it has subpar code quality, bad error handling/feedback and is not extremely performant.
Ideas:
base/{images,sounds,...}
and modXY/{images,...}
)ChildAssedManager
doesn't find a resource, the parent is checked.Examine a better way to handle Assets, topics that need a rework:
Performance:
Currently very flexible system, f.ex. AM::getAudio() tries to return a already loaded audio, if that is not yet loaded, call ::loadAudio() and return this instead. Does this make sense performance wise or is there a better system which is still flexible enough? Switch from path to ID keys for Asset key/value pairs.
Memory handling:
Should resources be freed after not being used for a specific amount of time and no more references to it? Or on a per-scene/level basis?
Add usable inventory, this should include:
Triplanar rendered terrain is really simple and boring. Add paths and other features that can be added on top of the base texture at specified positions. (decal rendering?)
Per vertex specified type of terrain, so the vertex decides which texture should be used for it.
Add props that are generated with the terrain to make the world more interesting.
This includes bushes and similar static models but also dynamic stuff such as tables or barrels (3d physics engine?)
lib/ should be exclusively for stuff not developed by me. The idea was to improve and extend the sgl library in parallel to the ecs-sandbox, while it would be better practice (also for forced reusability) it is easier to just develop it as part of the ecs-sandbox ecosystem.
Think about releasing it as a separate project later once the sgl library is mature & versatile enough.
Cameras are currently not that usable, need to rethink their design and functionality/expected tasks.
main.cpp
still does much camera work)I'm not sure why this library is missing. Are there more detailed build instructions available? I'm very interested in this project.
Add support for decal rendering. Used for terrain details, blood splatters after taking damage, etc...
Steps to reproduce:
This does not seem to happen when resizing the window by changing its size, only when the resize happens instantaneously (like fullscreen, or switching between tiled and floating in bspwm)
Add QoL improvements for shaders. Reloading of shader sources should be possible with minimal user changes. Templating would be great, see example 1
below.
#version 450 core
uniform sampler2D uTexture;
in vec2 vTexCoord;
out vec4 FragColor;
void main() {
vec3 color = texture(uTexture, vTexCoord).rgb;
// define an inline uniform. this will be initialized with the default value and can be edited with ImGui with no further changes.
color = color * [[float:uBrightness = 1.0]]
FragColor = vec4(color, 1.0)
}
generate random dungeons using wave function collapse.
When reloading all shaders (press & hold "p"), the game begins consuming RAM.
Probably problematic: sgl::shader#link()
Steps to reproduce:
This bug seems to appear only when no previous Decals have been created and removed from the registry.
Building on Windows does no longer work as of 1473c51. Find a way to build and include LuaJIT
on all platforms.
Currently(?) LuaJIT
is only available through vcpkg on Windows.
Automatically build the project on new tags using GitHub Actions.
Add a concept of items, those can be:
Consist of:
Different types of items:
Besides normal rooms in the dungeon were the player has to fight mobs/traverse traps, it would add variation to runs to include special rooms that are optional but provide the player with more stuff to do. Those rooms should be semi-randomly added (max. 1 shop per floor, ...) and only occur from time.
Ideas for rooms:
[0]: Game changing meta progression. Not yet decided if this is allowed.
[1]: Cosmetic-only meta progression. This should be fine in any case.
Provide a docker image which is capable of building the project.
Implement a CI/CD pipeline and automatically create releases when tagging a new version / merging into master.
The player should be able to continue playing exactly where they left, this requires the whole World and everything in it (and possibly much out of the Worlds scope) to be completely serializable.
[1]: Does this make sense? The only case I can currently think of is enqueued events that are buffered until next frame.
[2]: This probably makes sense. Maybe for saving while in a cutscene or something similar.
[3]: Definetly makes sense, but maybe not part of AssetManager? To load all previously active Assets. Maybe this will be handled differently.
Currently there is no concept of collisions with the terrain.
Entitys should have a collider component which detects and handles collision with terrain below them. Also this should handle collisions with walls and slopes.
implement audio (OpenAL-soft)
ToDo:
Currently chunks are handled pretty awkwardly, Terrain is split up in too many layers of abstraction (ChunkedWorld, ChunkedTerrain, SignedDistanceTerrain, Terrain, Grid2D).
A rework of these would be great.
Add a wrapper around the base window. Abstract settings, initialization and the gameloop into it. Support for gamestates/scenes is also required to cleanly work with menu, settings, core game and so on, think of something to work with it as flexible as possible. (Pause scene overlaps the game, transition between menu > start game and the game, ...)
implement a particle system (with possible sub systems?)
Required features:
We need a clear line between engine and the actual game. Additionally, the main()
function is huge which seems like a bad decision.
Abstract more stuff into either engine or user code.
I need to decide if the game should tend towards a more roguelike or -lite experience. Currently there is no preferred decision as both could be interesting to play, yet currently it seems to me that a roguelite is easier to design "correctly" in terms of balance and replayability.
(When I use the terms roguelike & -lite, I mostly refer to meta-progression only)
The latest windows build (at 6d7df63) produces artifacts on most CBillboards.
The game should be as accesible as possible; Controller support is a must and will become even more important once we will implement local coop.
Controller input is just as important as mouse&keyboard, maybe it will even become the preferred/recommended input method. Both Xbox and Playstation controller icons & button images are required. The correct button image should be shown even in local coop (Player1 with PS: press X to buy, Player2 with Xbox: press A to buy)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.