A giant list of older games re-implemented or made to work natively on Linux with Luxtorpeda (a steam compatibility tool, nicely selectable from within Steam itself).

Compatibility layer here: https://github.com/luxtorpeda-dev/luxtorpeda

Play Gothic 2 on modern systems with ease! Open source reimplementation of the game engine.

Unlock, re-lock, and change at will any achievements in Steam. Open-source, linux-based, very interesting.

An amazing little diy arcade machine and the building process simulating your working day in an Amazon warehouse.

Small distractions and reasonable emulation clones to learn simple frontend/backend development

Tutorial on creating a simple game with an ecs structure running in the browser.

(In-progress at time of bookmarking, up to Ship chapter, drawing the entity)

image resource, tilemap assets

entity: a unique id and a collection of components
component: a data container
query: a way to gather collections of entities that match some criteria, for use in systems.
prefab: a pre-defined collection of components and even other prefabs to quickly build entities
event: a message to an entity and it's components

This library is heavily inspired by ECS in Caves of Qud. A true ECS library with entities only being ID numbers

Bevy is a refreshingly simple data-driven game engine built in Rust. It is free and open-source forever!

Virtual machines and cheat VAC anti-cheat software

Virtual machines and cheat VAC anti-cheat software

Swept Points collision detection

Movement algorithms, path finding etc

One of the advantages of an ECS architecture is that you are running your systems over only entities that those systems apply to which helps support a large number of entities at once.

​
If you're putting everything into an ECS system you'd still expect most of your walls to have very few components. For example they may have a render component, materials component, and a position component. Meanwhile a lot of your systems would apply to components that walls don't possess, like an AI component, a velocity component, etc. So if your ECS system stores components in a way that either caches a list of entities with that component or stores the component information in way where iterating over all entities with that component won't iterate over entities without that component you shouldn't see significant slowdown in that respect.

​
That said where you would see slowdown in this example is in doing things like calculating collision or computing line of sight. If your look-up for whether a tile is blocking is get all entities at position -> check each entity for a 'blocks sight' component then you're doing a lot of legwork for something that's already computationally expensive. If you have to do that every time an entity is trying to answer a question like "can I see x tile" or "can I move to y tile" that's going to sink your performance.

​
I think what you'd need to do in that case is plan ahead for this type of work build structures on top to help. For example you may build a component for static collision blockers (for entities that don't move or disappear often) and whenever an entity gains/loses that component or is added/removed with that component you recalculate a base collision map as a 1d/2d/3d boolean (or enum) array. That way you'd have that data already computed and when you need to do something like pathfinding you can use the pre-computed data structure rather than having to query a lot of information from the ECS system every time. Then if you need dynamic collision on top of that (for entities that move often) you could use a second component for that but it would be a much smaller amount of entities that you'd be looking at to incorporate that data.

Marketing // PR // Getting your game noticed