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

Inspiration for roguelites

If it's taking days to find the problem, then you're probably doing something wrong. Learn from the experience, and improve your process.

Version control. Use it. Commit often. Work on a single feature at a time within any given branch. Use version history to quickly diagnose when a bug was introduced (either by inspection, or by bisection testing for it).

Tests. Write them. Unit tests are the simplest starting place, and will immediately help you diagnose when your code isn't even meeting your requirements for the desired use-case. Unit tests also make it easy to fix bugs, as you can practice TDD (test driven design) for bug fixes by introducing a test case that reproduces the problem -> fixing the problem -> success.

Tests. Build them. There's a lot of things in games that are easier to visualize than code. Have a test level that can contain a test layout for every single feature in the game. Have a spot to test the jump, the long-jump, the bouncy shot, the target tracking shot, etc. etc. etc.. Go there often, and make sure everything still works, and every new thing works as intended in isolation.

Tests. Record them. Sometimes things are hard to reproduce. Build you game with deterministic replay capability. Always record your inputs while playing, and have a mode to play them back. Here's a good GDC video for Retro City Rampage talking about how useful this technique is. This lets you easily reproduce bugs from yourself and from your testers.

Tests. Diff them. For visual systems, build a screenshot diffing tool. Using #4 as a starting point, capture screenshots every X frames. If those screenshots differ from your "golden" captures, then you broke something.

Tests. Smoke them. A "smoke test" is a test where you leave the game doing something all night (or on some kinda fast-forward) to make sure things still work in 24hrs. This is really important for things like open-world games with no loading screens which are going to be played for many hours in a stretch. Sometimes things creep up in the background over time (memory leaks, floating point errors, broken timers, etc.), and you wouldn't normally see them in your short REPL cycle of development.

Version control. Use presubmit checks against all the tests you just wrote. Keep yourself and others from commiting broken code to the repository.

Roguelike Rendering Pipeline - Layering of data

Units tests and roguelikes // Game unit testing // pragmatic unit testing

Selling consumer products is hard. Selling video games is, arguably, even harder. The market is huge but it’s also very crowded. There’s so much noise on Steam (21 new games/day in 2017 [1]) and other distribution platforms that it’s insanely tough for new game developers to figure out how to sell games and what metrics to watch. This article will go over, what I think is, the most important metric for any game launching on Steam, namely the number of wishlists.

Entity Component System programming pattern approaches explained for roguelike games