# tomlooman/ActionRoguelike: Inside Project Orion, a UE5 C++ Co-op Sample Game

> Project Orion is a co-op action roguelike sample built in Unreal Engine 5 and C++, published on GitHub by Tom Looman. It is a teaching codebase first and a game second, and the main branch doubles as an experimentation ground where features can lag behind the rest of the project.

**tomlooman/ActionRoguelike** — Co-op Action Roguelike in Unreal Engine C++

- Repository: https://github.com/tomlooman/ActionRoguelike
- Website: https://tomlooman.com/unreal-engine-sample-game-action-roguelike
- Stars: 4,608 · Forks: 824
- Language: C++
- License: not declared
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/tomlooman-actionroguelike

## What Project Orion solves, and who it is actually for

Unreal Engine C++ documentation tends to describe individual classes rather than a whole game. The gap between knowing what a GameplayTag is and knowing where an ability system should sit relative to an attribute component is where most learners stall. Project Orion is Tom Looman's answer to that gap: a complete co-op action roguelike sample whose stated goal is to be "easy to understand, learn from and adapt to your own games."

The audience is narrow and clearly stated. The README points readers at the Professional Game Development in C++ and Unreal Engine 5 course, and it keeps separate branches for course students: UE4-Lecture29-FinishedProject for the original UE4 version and UE5.6-CourseProject for the current course, with a commit URL per lesson. If you are not working through that course or teaching from it, you are reading someone else's teaching material, which is still useful but not what it was arranged for. The main branch is explicitly a "playground for experimentation," so the code there is not the same artifact as the course branches.

## How the action system, attributes and tags fit together

The architecture visible in the README is component-oriented. An AttributeComponent holds health and similar values. An Action System, described as "similar to Gameplay Ability System in design," drives abilities: a dash that teleports via projectile, a blackhole ability, a magic projectile attack, a "Thorns" buff that reflects damage, and a burning damage-over-time effect. GameplayTags mark up Actors, Buffs and Actions, and event-based logic drives UI and gameplay reactions rather than polling.

That combination is the interesting part. Tags give you a string-addressable vocabulary for state, the attribute component gives you numbers, and the action system gives you behaviour, with events wiring them to UMG widgets. It is a smaller design than Epic's Gameplay Ability System, which is the point: you can read the whole flow in one repository instead of tracing through a plugin. The trade-off is that you inherit whatever simplifications the sample makes, and the README does not document where those simplifications would break under a larger ability set.

Around the player systems sit the game-mode pieces: EQS queries for bot and powerup spawn locations, a bot spawning system where bots cost points and the gamemode gains points over time, a DataTable holding bot information, and DataAssets holding enemy configurations loaded asynchronously through the Asset Manager. Minion AI runs on behavior trees with custom C++ nodes covering roam, see, chase, attack and flee or heal, with EQS picking attack and cover locations. Multiplayer support is claimed for all features.

## Getting the project running and opening the ability code

The README does not give install commands. It gives you a branch to pick and a repository to clone, and the rest is standard Unreal Engine workflow: clone, open the .uproject with the matching engine version, let the editor build the C++ modules, then play in editor. The main branch targets Unreal Engine 5.6, and the top-level layout includes ActionRoguelike.uproject, Source/, Content/, Config/, Binaries/ and CollectedPSOs/.

Clone the branch that matches your engine rather than defaulting to master. The README names the branch for course students:

```bash
git clone -b UE5.6-CourseProject https://github.com/tomlooman/ActionRoguelike.git
```

Course students should use that branch, because the README says it carries a commit URL for each lesson, which makes it possible to diff your own work against the intended state at any point. If you want the finished UE4 course code instead, the branch is UE4-Lecture29-FinishedProject.

Once the project is open, the experimental systems are the first thing to look for. The README states that many experimental features are disabled by default behind #define directives so they can be toggled on or off at compile time. The exact directive names are not listed in the README, so read the source files to find them before assuming a feature is missing.

The projectiles are the concrete example. The README describes both an object pooling mechanism and an experimental data-oriented approach to projectiles that uses no Actors at all, and it warns that this may affect stability and is not always multiplayer-ready yet.

## Where the main branch will bite you

The README is unusually direct about this: the main branch is "a bit of a playground for experimentation of new systems," and those systems "may affect stability and is not always supporting multiplayer yet until the systems stabilize over time." Read that as a statement about the branch you are most likely to clone by default.

The multiplayer claim deserves the same scrutiny. The feature list says multiplayer support exists for all features, while the same README says experimental systems are not always supporting multiplayer yet. Both statements can be true at once, but only if you know which features are experimental, and the README does not enumerate them beyond the projectile example. If your goal is to study networking, start from the course branch and treat the main branch as a preview.

There is a second, quieter cost. The project is a moving target: the README says the game on the main branch has been updated over the years to keep up with the latest Unreal Engine release, and that new features are added alongside articles and tutorials on tomlooman.com. A codebase that tracks engine releases is a codebase whose APIs shift under you. The last push to the repository was on 2026-09-06.

## Alternatives, and the difference that matters

The obvious comparison is Epic's own samples, particularly Lyra, which ships with Unreal Engine and demonstrates the Gameplay Ability System at production scale. The difference in approach is the point of Project Orion. Lyra is built to show Epic's recommended patterns for a shipping multiplayer game, which means a large amount of framework code and abstraction between you and any single behaviour. Project Orion is built to be read: its action system is deliberately a smaller, GAS-like design rather than GAS itself, and the README frames the whole project around being easy to understand and adapt.

If you want to learn the real Gameplay Ability System, Lyra is the better teacher and Project Orion will teach you a simplified cousin. If you want to see how health, tags, abilities, AI, spawning and UI connect in one readable pass, the smaller design is an advantage. The README also points outward to its own documentation page and to a separate article on implementing a save game system, which is where the project expects you to go for depth beyond the repository.

## Licence, assets and the cost of keeping up

The repository does not state a licence, so treat the code as unlicensed until you confirm otherwise with the author. The assets have a clearer boundary, and the README spells it out: the game assets are licensed for use with the Unreal Engine only, and without a custom license you cannot use them to create sequels, remasters, or otherwise emulate the original game, or use its trademarks, character names or other IP to advertise or name your game. The Unreal Engine EULA applies. The README adds a useful carve-out: this restriction covers the assets referring to Epic's Paragon, and you can still use the project code and content to build your own Unreal Engine game. Whether your specific use falls inside that carve-out is a question for a lawyer, not for this article.

Upgrade cost is the recurring expense. The main branch tracks the latest engine release, currently 5.6, and the README notes features are added over time. Every engine upgrade is a potential round of compile fixes in C++ modules, and the experimental systems behind #define directives are the most likely to need attention. The project also ships PSO precaching and bundled PSOs for Windows DX12, plus an Async Line tracing example, which are the kind of platform-specific pieces that tend to need revisiting on engine updates.

## Conclusion

Adopt it if you are learning Unreal Engine C++ and want a working reference for action systems, GameplayTags, AI behavior trees and multiplayer plumbing, or if you teach that material and want a codebase students can read. Do not adopt it as a shipping game: the README states the main branch is a playground for experimental systems, and the bundled Paragon assets are licensed for Unreal Engine use only, so you cannot build a sequel or remaster from them without a custom license. Before you clone, confirm which branch matches the engine version you run, since the README points course students at UE5.6-CourseProject while the main branch tracks Unreal Engine 5.6.

## FAQ

### What is Project Orion in the tomlooman/ActionRoguelike repository?

It is a co-op action roguelike sample game made in Unreal Engine 5 and C++, described in the README as an expansion on the game built during Tom Looman's Professional Game Development in C++ and Unreal Engine 5 course. The main branch targets Unreal Engine 5.6 and is described as a playground for experimental systems.

### Which branch of tomlooman/ActionRoguelike should course students use?

The README directs C++ course students to UE5.6-CourseProject for the current UE5.6 version of the course, which has a commit URL for each lesson, or to UE4-Lecture29-FinishedProject for the original UE4 course code going back to UE4.25.

### Does tomlooman/ActionRoguelike support multiplayer?

The feature list states multiplayer support for all features, but the README also warns that experimental systems may affect stability and are not always supporting multiplayer yet until they stabilize. The README does not list which features are experimental beyond the projectile example.

### Can I use the assets from tomlooman/ActionRoguelike in my own game?

The README states the game assets are licensed for use with the Unreal Engine only, and that without a custom license you cannot use them to create sequels, remasters or otherwise emulate the original game, or use its trademarks or character names. It adds that you can still use the project code and content to build your own Unreal Engine game.

## Sources

- [Issues](https://github.com/tomlooman/ActionRoguelike/issues)
- [Project website](https://tomlooman.com/unreal-engine-sample-game-action-roguelike)
- [README](https://github.com/tomlooman/ActionRoguelike/blob/master/README.md)
- [tomlooman/ActionRoguelike on GitHub](https://github.com/tomlooman/ActionRoguelike)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tomlooman-actionroguelike