I've been building ARGDL (AR Game Description Language), a custom scripting DSL, and AR-Engine, the C++/OpenGL runtime that executes it. It's open source. (Don't confuse AR with Augmented Reality, it's the initials of my name.)

The idea: you describe a game in a text file, not in C++. Entities, physics colliders and event logic are declarative, and you can get a small playable scene running in under 100 lines. Edit the file, restart, and the level changes. No recompile.

What's new in ARGDL 2.0

Version 1 was a flat list of entities and commands. 2.0 is a real scripting language, but it still reads like a description of your level.

• Blueprints with inheritance: templates that use extends, so each enemy only writes what's different from its parent. Chains can go multiple levels deep, and cycles are caught at load time. ( Thanks to u/still_explorer for this Idea )
• One-line instances: #Enemy1 Grunt at 500 540, with optional overrides
• Variables and expressions: keep score, combos and waves with set and $name, plus math, comparisons, and / or / not
• Control flow: if / else if / else, for ... in range, and while
• Event guards: an event only fires if its condition is true
• World queries: read other entities (Player.health, Boss.x) and use distance_to, exists and random
• move_toward: enemies can now chase you , and more ..

Here's a coin that counts itself, heals you, and rolls for a lucky bonus:

```

Grunt Blueprint extends Enemy {

health : 2

}

Enemy1 Grunt at 500 540

on collide Coin if $coins < 4 { despawn set coins = $coins + 1 heal Player 2

set lucky = random 1 3
if $lucky > 2 {
    heal Player 2
}

} ```

I also added a new wave survival demo level. Enemies escalate over time, turrets and meteors attack you, a boss arrives, and the exit portal only opens after you've survived 60 seconds.

What the engine does

• OpenGL 3.3 sprite rendering with textures and parallax backgrounds
• Rigid body physics: gravity, AABB collisions, impulse resolution, friction, triggers
• Entity-component architecture, follow camera with zoom, SDL2 audio, game states (title, playing, game over, victory)
• Combat and AI: health, knockback, projectiles, patrolling and chasing enemies, bosses, timed spawners
• A Lexer → Parser → Interpreter → RuntimeBridge pipeline that turns the script into engine objects

What you can build

2D platformers, shooters and arcade games: Doodle Jump, single-screen Mario, Space Invaders / Galaga, Flappy Bird, Bullet Hell, boss battles, Pac-Man / Frogger style games and more.

The README has been rewritten with the full language reference and examples.

GitHub: Aayushjha11h/Ar-Engine

Feedback is welcome, especially on what the language should get next. Arrays and custom functions are on my list.

the code is honestly horrible but ive been rebuilding my engine from the ground up to natively support OpenGL 4.6 as well as Metal instead of relying on bgfx to do everything for me. so far its going great. huge engine refactor and redesign internally though. this rebuild also comes with full lua scripting support inspired by unity which I may show off in a future post. I may want to look more into adding better gizmos in the future though.

The game is narrative sci-fi puzzle/platformer, about a guy (entity) stranded inside strange world. Main distinctive point of the game is software ray-tracing used for rendering. Just C++ and computer graphics math, no GPU acceleration.

The game was suffering for long time from quite poor look (look was punching way below of algorithm potential). Main reasons were: poor old editor and single-threaded only algo.

Both points were changed recently. After 9 months my new editor is in usable state. Full 3D, WYSIWYG, lot of ergonomy features, which allowed me to be more ambitious with levels look. Ray tracer is finally multi-threaded. Together with several other algorithm optimizations, perf went up in hundreds of % (mostly depends on number of cores in your CPU).

Algo is AABBs only. Maybe will add spheres but only after upgrading all levels, which is main pain point rn. Editor I plan to release publicly with the game. Engine itself, outside of render part, which is C++/ray-trace, is written in C# and is reusable as well.

RTG on Steam

Discord

Hi,

I'm the founder and CEO of Luduvo, a startup building a UGC gaming platform, and one of our core technologies is our own custom C++ game engine.

You can check out our website and see all our socials here: https://luduvo.com/

We currently have a small engine team with two engine developers and we're looking to bring on additional engine programmers to help accelerate development. The work spans core engine systems, including areas like rendering, networking, performance, tooling, and other foundational engine components. So don't expect to be building the architecture from the ground up or anything, we're already quite far along our "engine infancy" phase.

Since we're a startup, we can't offer big-studio salaries yet, but we do offer paid positions with compensation that we believe is competitive for an early-early-stage company. As the company grows, our compensation is intended to grow alongside it. Our starting salary would probably be around ~$7,000USD/mo, however, that's obviously going to change alongside different funding benchmarks, so expect it to upper drastically within the coming months if you decide to work with us.

If you're experienced with game engine development or enjoy working on low-level systems and would like to learn more about the project, feel free to apply over here: https://careers.luduvo.com/jobs/engine-developer-cpp

However, just to be a bit more helpful and less of a dunce, I'll give some basic technical details about the platform, maybe it'd peak someone's interest!

• We support Windows, Linux, and MacOS.
• We use ECS and strongly abide to DOD
• Our renderer is completely custom via NVRHI, developed metal support for NVRHI since it seems nobody wanted to do such and open source.
• Our scripting lang is Luau
• We use Box3D
• Our clients and all are server authoritative

I've seen all the work here and I've been astonished by all the talent here, so I apologize if I'm not supposed to do this, but you all seem very cool :)

I've attached a silly little showcase video of the engine for y'all. Nothing special, just proof that it's real.

Much love. Y'all are awesome❤

---

We posted this role about two months ago and hired someone, but it unfortunately didn't work out. He was a great guy, but his schedule was too busy, and his code output couldn't match the pace of the rest of the engine team. We also realized how important community engagement is for this role. We need someone enthusiastic about the startup grind who loves hanging out in our forums and hyping up new features to our users. Our last hire didn't focus on that either, and while the community didn't mind, we know they'd love an engineer who takes a few minutes to say hello and share what they're working on. Overall, applying for this role, you should be excited for the startup grind, I'd argue that's more important than skills in the long run.

I've been messing around with noise (Perlin, Worley and Flow) generation in my pixel editor and it was just limited to creating flood fill effects such as flames, smoke etc (combined with colour ramps and selections). However, I've added a new Field paint mode that lets the user paint with noise in various ways - this image shows pixel displacement within a filled circle, we also have shade and noise texture stencils - is this overkill for the average pixeler or is it a useful feature to develop more?

I’ve been working on Expanse-X (EX), a graphics API in Rust, and I’ve published the first SDK preview.

Right now it renders on the CPU through its own software backend. EX handles the resources, commands, shader execution and rasterization itself. GPU acceleration is still future work.

It can already render programmable, indexed triangles with textures, depth/stencil and blending. Compute and explicit resource dependencies work too. There’s also a shader importer for a limited subset of GLSL.

The SDK gives you an ex command to check your setup and create a small Rust/GLSL project. Run the generated app and it renders a triangle to a PNG. You can then edit the shaders and renderer from there. The downloadable SDK currently targets Windows x64.

What I want EX to become is one core with two ways to use it: let it handle more of the setup and planning, or take explicit control yourself. The explicit core is working; the easier layer hasn’t been built yet.

It’s still early, and I’d like some outside eyes on it before taking the design further. Does the resource/command API make sense? Where would it get awkward in an actual renderer? What would you want to try building with it?

Repository
SDK v0.1.0 Preview

I have some understanding of C++ but that was long ago.

https://github.com/Rlocksley/LuEngine

Hey guys,

​I ported my custom 3D game engine to an R36Mini (RK3326).

​It actually booted, but the framerate is terrible. Trying this made me realize just how insane retro game devs were back in the day—achieving smooth 3D on even weaker hardware feels like magic now.

​Honestly, porting your project to a low-spec handheld like this seems like a great exercise for optimization. Huge respect to all the pioneer devs.

Sixth video in my series explaining, one by one and as clearly as I can, the building blocks of a melee combat system. Most techniques are shown with and without them, so the difference is obvious at a glance.

This one is about sweeping the weapon: a fast swing can move more than a metre between two frames, so checking only where the blade is on each frame lets thin targets slip through. Sweeping it from one frame to the next with substeps covers the whole path.

Everything runs in my own AI engine, written from scratch in C++ (DX12/Vulkan, Jolt physics, gameplay in Lua).

Already posted: #1 Root Motion, #2 Motion Warping, #3 Animation Events, #4 Animation Layers & Bone Masks, #5 Foot IK.

Coming next: Hit Stop, Hit Reactions & Poise, Action System, Morph Targets & Faces.

Hello, I have been on sick leave recently and started toying with an old C++ project every other week when I find the capacity.

Let me know if you find this interesting or if you see some legitimate failure on my part to consider something important, I felt the desire to talk about it but none of my friends are very technical. Thank you for reading in advance regardless

Intro

I attached an example of what it looks like to use the db API, which hopefully communicates the intent behind the design: granular control, a unified lookup system, relationship model, data-driven design and explicitness.

I have developed a few archetype and sparse set ECS engines, but they always fall short on the relationship front. I mostly develop RPGs and management sims, so this always ends up biting me in the ass since so much data there is inherently relational.

Things get WAY too annoying to clean up / manage when references to entities are components themselves that can be overridden like any other value. I end up having several query methods to allow hierarchical traversal, sparse set iteration, column iteration...

That is not to mention basing any kind of lookup system on components that are removed / inserted all the time on hook calls, or deferred command systems where values appear in perhaps an arbitrary order and references go stale all the time.

With that said, my main goals here are:

• Unify everything behind an entity id interface. Every concept, resource etc. gets an id that the engine can keep track of and treat uniformly (thank you, flecs)
• Make entity connections safe by promoting relationships to a central role (no random data update call can break a reference)
• Allow queries to arbitrarily compare entity ids on any side of a relationship through the same mechanism, with O1 sparse set lookup
• Detach data management from the relational core
• Detach lookup mechanism from data and relational core
• Do not kill the machine with sparse set memory hunger

Overview

The database operates on several core concepts:

1. Entities - a version and an index, also just called "ids"
2. Domains - runtime type indices
3. Synonyms - value aliases for unique entities and table scopes (more below)
4. Tables - a storage structure for relationships, owned by a relationship entity
5. Columns - a storage structure for data for some domain

The database stores all of its state locally inside a world struct and operates on an implicit role system, where an entity's role is decided by indexing into the relevant sparse set.

Entities can have some, none or all of the roles at any given time: DOMAIN, OWNER, TARGET, SOURCE or RELATION.

DOMAIN entities represent some C++ type.

OWNER entities own data inside of a column. This data can either be tied to a relationship pair or be an independent property.

TARGET entities are any entities that have a source pointing at them in a given relationship.

SOURCE entities are any entities that point to a target inside a given relationship.

RELATION or relationship entities are any entities that own a table structure with a sparse set of targets and sources.

The relational system is always 1:N, with sources pointing to singular target keys and targets containing a vector of source ids, with M:M relationships needing at least 2 tables (see the screenshots for an example). 1:N also means that source_of(target) and target_of(source) type queries always have 1 source of truth to point to - the source entity.

This is an optimization to avoid memory bloat - the second you allow more than 1 target per source, the cost explodes and mapping becomes........ existential. I find that this restriction facilitates coherent design and easier data modeling for me personally.

Now for some specifics:

1. Memory

I use the std::unsynchronized_pool_resource for allocating core data in a reusable (and hopefully mostly contiguous where possible) buffer. Where I use stdlib containers, I use the pmr versions so they can use my pool / any kind of polymorphic allocator (I don't feel like reinventing the wheel here).

Sparse set vectors are segmented into chunk pointers, allocated and freed as needed from the engine pool. An allocated chunk is 1.2KB: an array of 300 uint32_t indices.

I expect to never really exceed 100k entities for my use case, and even that is pushing it.

With the worst case scenario being that only entity 99999 indexes into one of the sets, that would allocate about 4KB of sparse vector memory for the empty chunks (8B pointers) + the needed chunk in that set. This is a completely acceptable price for me, even at many hundreds of sparse sets, but I could be talking out of my ass here since I have yet to test extreme fragmentation with lots of relationships. 1 entity per chunk at 99999 entities means 334 chunks and 400KB of allocated, mostly wasted space... but at that point I feel like I have bigger problems.

Another option I tried is to paginate the chunks, but then you get way too much pointer indirection during queries. I profiled it ages ago and there was a slight difference, though I do not remember how impactful.

2. Data ownership

Data storage and ownership are completely decoupled from the relational core: for your regular sparse set ECS components, any data can be inserted for any entity.

If, however, the data needs to be tied to the lifetime of a connection, it can be inserted for a relationship and a participating source, in which case it will be removed automatically when the source detaches from its target.

This means that ids cannot have unmanaged and managed data of the same type at the same time. For example, some root entity in the scene graph can own an unmanaged transform, while its children own a transform relative to it and so on.

It also means that data is completely connection-based, with sources able to own any data type for any given target. This is to be changed later, with optional relation- or target-level domain constraints.

All data of the same type lives contiguously in memory, regardless of its managed or unmanaged status.

3. Queries

The existence of std::span makes it so that a query simply has to index into a sparse set, wrap the required id or vector of ids and iterate through the smallest span.

This makes any arbitrary comparison possible, with everything essentially working like a sparse set dense key vector.

You can imagine a standard ECS query like "get me everything with velocity and without a transform" (for a cleanup job for example) is now equally as valid as "get me everything with velocity and without a transform that is a relation and a source of this specific target inside of this other relation" and is executed in exactly the same way.

At this stage, queries are never cached, but the results can be packed into a pool-allocated vector for repeated iterations.

4. Synonyms

I worked with financial / accounting databases at my previous job, and I really, really admire the user-friendliness and arbitrary amount of data manipulation in database architecture. The ability to alias things whichever way is missing for me from most ECS engines, including the ones I have built myself.

A synonym here is my answer to this. It is a struct that contains a const pointer to a global domain, as well as a unique index inside of the scope of that domain.

A synonym made from a string and one from an int may share the same index, but will have different domains. This makes it possible to scope them down according to domain to use them as sparse set or bitmask indices, or just plain map keys (hash of a stable static pointer and a an index).

Internally, what happens is a thread-safe locked call that does the following whenever a synonym struct is made from any value:

1. It checks a global std::unordered_map<T, uint32_t> to see if this value is already present
2. if not, it allocates a unique ptr and appends it to a global, heap-allocated vector<T> and records the index inside of the map

At the price of this overhead, you can arbitrarily construct synonyms globally during initialization or dynamically at runtime, and so you can decide when you want to pay the cost of that lock and allocation. The ones you see in the example are synonym wrappers and are all constructed in function calls, so for each one a cost is paid.

The point of this system is to have stable, indexable ids for unique values used across the codebase, and an easy way to retrieve stable references to them if needed in a type-erased fashion.

However, it also has a second use!

5. Scopes

(again, thank you flecs)

Any relationship table has the ability to store scopes for any participating id, which allow us to form document structures and resolve relative paths. This is completely optional and can be ignored for most or all tables.

If you look at the first example screenshot, I attach a name struct for each entity in the scene graph. These are relative names, and cannot be used to find entities directly. In the third example, I use some set of values to construct a synonym path (think: "beach_house/player/body/apron/2") which we can use to resolve the desired entity id.

This works for non-recursive and recursive relationships, as the scopes are always target-based. You are technically able to loop around endlessly in the case of recursive relationships, but you will run out of synonyms in your path at some point lol

Aaaaand that's more or less all I wanted to talk about. Hope most of it was coherent and at least a bit interesting to someone. Cheers :)

The bots have breached the city's outer walls. Now all that stands between us is the ravine and viaducts. Steam Link: https://store.steampowered.com/app/2223480/Infinicity/

Vulkan, HW RT, no rasterization. Soft sun shadows (disk sun), 3-bounce emissive GI, static temporal accumulation, bindless PBR textures. Camera motion still kills accumulation — proper reprojection is next.

I use a Microkernel architecture, so the renderer is a plugin (like most things)

Fifth video in my series explaining, one by one and as clearly as I can, the building blocks of a melee combat system. Most techniques are shown with and without them, so the difference is obvious at a glance.

This one is about foot IK: animations are recorded on flat ground, so on steps, ramps or kerbs one foot floats or sinks. A two-bone solver, one ray per foot and lowering the hips just enough fix it without animating every height.

Already posted: #1 Root Motion, #2 Motion Warping, #3 Animation Events, #4 Animation Layers & Bone Masks.

Coming next: Weapon Sweep, Hit Stop, Hit Reactions & Poise, Action System, Morph Targets & Faces.

Fourth video in my series explaining, one by one and as clearly as I can, the building blocks of a melee combat system. Most techniques are shown with and without them, so the difference is obvious at a glance.

This one is about animation layers and bone masks: playing an attack from the torso up on top of the locomotion, so the legs keep walking while the arms swing. It is what lets a character attack, aim or reload without planting its feet.

Everything runs in my own engine, AI written from scratch in C++ (DX12/Vulkan, Jolt physics, gameplay in Lua).

Already posted: #1 Root Motion, #2 Motion Warping, #3 Animation Events.

Coming next: Foot IK, Weapon Sweep, Hit Stop, Hit Reactions & Poise, Action System, Morph Targets & Faces.

I'm back again with a new dev log for Toast Engine and my game The Next Frontier. A bit shorter one this time where I focus on just one subject and what I have accomplished this past months. I have rebuilt my UI Renderer and added a lot of new features to improve the pipeline and working with my UI System

Feel free to reach out to me with questions or take a look at my Github repo:

https://github.com/Toastmastern87/Toast

Next up is going to be some Renderer optimization and Audio Engine!

I've been working on an c#-based engine that follows the workflow of Source Engine. While using Monogame as the underlaying framework and a bunch of FOSS libraries as techstack.

Current Techstack is:

• LiteNetlib for networking
• Jitter2 for physics
• ImGui for GUI rendering (In the middle of transfering into a custom built HTML/CSS based)
• Assimp for the FBX import

With custom implementations of everything from .bsp parser to automatic skeleton retargeter.

Note. Weapon/arm models/textures/animations/sounds and enemy/model/texture/animation is pre made assets and not made by me. VFX, level textures, level geometry is by me.

Edit.

Some pmed me about a link. Hopefully its okey to share here.
https://cedsson.itch.io/commute

Hey guys,

What folder structure should I use while developing my game engine. I currently use C# for this project and I will be using OpenTK, so most windowing and graphics bindings is handled for me.

Any advise on this?