Banner for Project Escalion

Why do we love to do moonshot projects, despite knowing that the odds are not exactly in your favor?

There’s a very narrow line of difference between a “hobby project”, and a “moonshot project”. A hobby project does not demand anything, and nothing much is expected out of it. If it helps someone out in the wild, that is beautiful. Sometimes hobby projects become larger than life, such as the Linux kernel. More often than not, hobby projects teach us a lot, and are genuinely fun to do. I have contributed to a lot of them, and I expect to continue such contributions possibly throughout my life.

A moonshot project is different. This is when you let go of all rationality, and just believe deeply in a cause that you want to fulfill. Moonshots can fail, and when they do, they fail spectacularly.

However, moonshot projects are also the ones that carry the drive that lead to their eventual success.

This is a story of how a bunch of non game-dev naifs are trying to build a game engine. But don’t worry, our goals are not entirely lopsided.

Ok, enough inspirational intro ||| what is this

On the surface, Project Escalion is yet another game dev engine.

“BOO!!! ANOTHER GAME DEV ENGINE?? I’LL GO USE $(insert-game-engine-of-choice)” - You, who’s reading this, maybe

We leave no stone unturned when it comes to chasing hype:

  • RUST
  • GPUI
  • NATIVE
  • NO WEB TECH
  • LINUX, WINDOWS, MAC
  • SUPPORTS ALL SPECS FROM POTATO TO HYPERCOMPUTER

But, trust me, we are not just here to chase tech trends and make another Open Source project that dies in the corner. This is a little bigger than that.

Khoury Club

On a very broad level, Project Escalion is an official upcoming-as-of-fall-2026 student club at Northeastern University’s Khoury College of Computer Sciences (which I am starting w/ the help of some people I met in CY 5770 Spring 2026).

I currently serve as the Executive Vice President of the club, working alongside Dhairya Bhatia and Kunal Deb. That sentence, while technically accurate, doesn’t really tell you what the club is about. If anything, it sounds like every other programming club on campus.

The original idea behind Escalion was remarkably simple: build a game engine (for fun) (not clickbait) (must watch)

No grand roadmap, and certainly no illusions that we’d be competing with the likes of Godot or Unreal anytime soon. The appeal wasn’t that we thought the world desperately needed another game engine. Rather, it was the engineering challenge itself.

After all, I am an Operating Systems developer working with people across a broad range of AI/ML, Software Engineers, Data Scientists, Cybersec experts, and no-tag programmers on a kind of project that none of us have worked with: a game dev engine. How are we all here?

There are surprisingly few software projects that naturally pull together graphics, systems programming, networking, mathematics, tooling, asset pipelines, physics, user interfaces, and collaborative software engineering into one codebase. A game engine just happens to check almost every box.

Of course, this also makes it one of the hardest kinds of software to write.

Every subsystem opens the door to another rabbit hole. Rendering means graphics APIs and shader pipelines. Physics means numerical methods and linear algebra. Asset loading leads to file formats, tooling, and editor development. Before long you’ve accidentally signed yourself up to reinvent thirty years of software engineering because you thought it would be “a fun summer project.”

Naturally, we thought that sounded like an excellent idea. An excellent idea, that we have limited time to execute. So limited that we have to now build upon a roadmap that helps us achieve this dream, but also give back to the student community who are helping us (for free) in some way.

More Than Just Another Engine

Whenever someone hears that you’re building a new game engine, the first question is usually why?

It’s a completely fair question.

There are already excellent engines available today. Godot has become the poster child for open-source game development. Unreal powers some of the largest games ever made. Unity, despite its ups and downs over the past few years, is still one of the most approachable ways to get into game development. If your only goal is to ship a game, we’d be foolish to suggest throwing all of those tools away and starting from scratch.

That’s never been the point.

Over the past few weeks, as we’ve discussed what Escalion should actually become, we’ve realized that the engine is really just the moonshot. It’s the excuse that brings together people who enjoy solving absurdly difficult engineering problems. Whether or not we eventually reach version 1.0 almost becomes secondary to what we learn while trying.

More importantly, it forced us to ask a much bigger question:

What kind of club are we actually trying to build?

The Club We Wanted Didn’t Exist

Suppose you’re a student who’s interested in game development.

Maybe you’ve spent years programming in C++ and want to understand rendering pipelines. Maybe you’ve never opened a game engine before but have dozens of ideas for mechanics. Maybe you’re fascinated by backend systems and think synchronizing hundreds of players across a network sounds more interesting than writing shaders. Or perhaps you’re an artist who simply wants to work with programmers on something creative.

All of those people would describe themselves as wanting to “make games.”

They’re also looking for completely different experiences.

Our initial instinct was to have everyone contribute to the engine. After all, that’s what the club was founded around. The more we talked, however, the more we realized that this approach would satisfy almost nobody. It would be intimidating for newcomers, overly restrictive for experienced developers, and completely exclude people whose interests lie outside low-level engine development.

Instead of asking everyone to fit into one project, we decided to broaden what “game development” means within the club.

Three Tracks

The result is a structure that naturally split into three tracks.

The first is the original vision: game engine development. This is where people interested in graphics, physics, mathematics, memory management, ECS architectures, and systems programming can dive as deep as they’d like. It’s unapologetically low-level, and probably the closest thing to the moonshot that inspired the club in the first place.

The second track focuses on making games rather than engines. Members are free to use Godot, Unity, Unreal, or any other engine they’re comfortable with. The emphasis here isn’t on rebuilding technology that already exists, but on understanding game design itself. Mechanics, pacing, animation, art direction, level design, and user experience are all engineering problems in their own right, even if they don’t involve writing a renderer.

The third track grew out of a conversation that, admittedly, had very little to do with graphics. Modern multiplayer games are essentially distributed systems. Synchronizing players, managing game state, handling latency, designing backend services, securing network traffic, and scaling infrastructure are all classic software engineering problems. Taking an existing open-source game and gradually making it multiplayer turns out to be an excellent excuse to learn databases, Redis, networking, concurrency, and production backend design without needing to deploy a global MMO on day one. We intentionally kept the first milestone simple: two players, one map, over a local network. Even that turns out to be an interesting engineering challenge.

Open Source First

One thing that all three tracks have in common is that they’re fundamentally collaborative.

That’s why we decided early on that everything we build should be open source.

The obvious benefit is that anyone can learn from the code, contribute improvements, or fork projects into their own experiments. The less obvious benefit is that contributing to an open-source project teaches skills that most university assignments simply don’t.

Using Git by yourself is easy.

Using Git with twenty contributors is an entirely different experience.

Writing meaningful pull requests, reviewing someone else’s work, breaking large ideas into manageable issues, resolving merge conflicts, discussing architecture, and learning how to politely disagree are all skills that transfer far beyond game development. In many ways, those lessons are more valuable than the software itself.

That’s one of the reasons we think Escalion is relevant even for students who have no intention of becoming game developers.

Teaching Before Building

Another conclusion we reached was that the club shouldn’t immediately devolve into everyone pitching their dream game.

As exciting as that sounds, it’s also a great way to end up with twenty abandoned repositories after three weeks.

Instead, we’re planning to organize weekly workshops covering different aspects of game development. Some will focus on technical topics such as networking or graphics, while others will look at design decisions, animation, asset creation, and even reverse-engineering existing open-source games to understand why they work. Game development is one of those fields where software engineering and creative design constantly overlap, and we’d like our workshops to reflect that.

We’re also hoping to collaborate with students interested in digital art. Games aren’t built by programmers alone, and neither should a game development club be.

Looking Ahead

The timing is fortunate. Escalion has recently become an official student organization, which means we’ll soon be introducing the club during orientation events and Fall Fest. Before asking new members to join us, though, we’d like to have something tangible to show. Over the summer, each of us has taken ownership of one area—whether that’s multiplayer systems, game development, or asset creation—with the goal of building small demonstrations and workshop material before the semester begins. They won’t be polished products, but they’ll give us something concrete to teach from.

Will we eventually build a fully featured game engine?

Maybe.

Maybe not.

Moonshots are called moonshots for a reason.

But if, in a few years’ time, Escalion has helped students contribute to open source for the first time, taught them how large software projects actually come together, introduced artists to programmers, and convinced a handful of people that systems programming can be genuinely fun, I’d consider that a success regardless of whether our renderer ever supports deferred lighting.

Next Steps (for you)

“I am a student in Northeastern (Boston campus) and I love this. Where do I join?”

Email either one of us:

See you around :)

“I am not a student in northeastern”

Q; Want to contribute?

Our repo will be Open Source and will welcome contributions

Q; Are you an industry professional?

We would love for you to inspire our students w/ your knowledge and skills. Email either of us above.

More guidelines for non students soon :)

“Uhh, Kush, will you stop doing low level systems dev stuff?”

Nope. More on that on this space per usual soon.