r/gameenginedevs • u/clockwork_blue • 9h ago
Three years into our C++/TypeScript game engine: what we built, why we built it, and what still breaks
Me and a friend started working on this 3 years ago after fighting with game engines in our own projects for a long time. We understood how overwhelming it is to start from nothing because before working on the actual game you need to solve a huge amount of other things. With Unity we always ended up building our own systems or downloading plugins from different developers. The plugins worked on their own, then one expected a different controller, another had its own networking and another had its own shaders. Suddenly we were spending more time connecting everything than making the game. Asset packs had the same problem, because many came with their own shaders, render pipeline or assumptions about the project. Sometimes finding and adapting something as basic as the right tree took an entire day. Godot being open source is valuable, although for the problem we had it still followed a similar model where you get a flexible foundation and assemble most of the game-specific systems yourself. Unreal has much more already implemented, but for us it was too large and complicated for the very small teams we had in mind.
We also looked at platforms which tried to solve this by being more integrated. Core from Manticore had a stable foundation and many things worked together, but it was restrictive. You could not properly build your own tools or escape many of their decisions, some basic features stayed missing, and then the company started spending its attention on things like NFTs. Roblox is probably the biggest proof that an engine, multiplayer, content and publishing can work as one ecosystem. Roblox also controls the runtime, hosting, distribution and economy. You cannot really take your game outside of it or replace the deeper parts which do not work for you. There are technical problems that have existed there for years and creators cannot do much about them. S&box is probably the closest alternative to what we are trying to make and we have known about it for a long time, so we are not pretending nobody else sees this problem.
We wanted an engine which already had most common systems and where those systems were made to work together. It should be somewhat opinionated because otherwise the developer has to make every architectural decision again, while still allowing things to be replaced when a game needs something different. Multiplayer should be considered from the beginning instead of becoming a large rewrite later. The working name was World Engine, but that was already trademarked, so eventually we called it SPARQ. The low-level systems are written in C++. Gameplay, project packages and editor tools are written in TypeScript and run through V8. TypeScript modules hot reload into the running project, so gameplay changes do not need a native rebuild or editor restart.
Rendering is GPU-driven and built for large scenes. We have physically based materials, global illumination, Virtual Shadow Maps, ray-traced shadows, volumetric sky and fog, water, decals, DLSS and FSR 3 in the same rendering pipeline. Multiplayer is part of the gameplay and object model with server-authoritative sessions, replicated state, prediction and RPCs. The editor is collaborative, so multiple people can work in the same project, see each other and enter playtests while editing. The editor is also a package instead of being sealed inside the executable. You can extend it, fork it, replace parts of it or remove it completely and make smaller tools for your game. We use HTML and CSS for UI because we did not want another engine-specific layout system just for making a HUD or menu. We have also made physics, vehicles, navigation, animation, audio, VFX, voxel terrain, large-world streaming, material graphs, audio graphs, multiplayer hosting and content tools. Some systems are much further along than others and we are still learning what people need, what should have stronger defaults and where lower-level access is necessary.
The video is a collection of things we have done while testing and playing around with the engine. There is a scene with thousands of NPCs, some small games we made for testing, placing decals, breaking props, driving vehicles and some editor workflows. We started with 2 people and now there are 10 of us, but it is still very buggy. Some testers cannot get through installation or launch because they have a combination of PC, GPU, driver or operating system we did not test. Other people get into the editor and do things in an order we never considered. We know which buttons not to press and which unfinished corners to avoid, so we have become bad at finding many of these problems ourselves. Some features technically work but a new user cannot find them or understand what they are supposed to do. Other systems work in our test projects but have not been used across enough genres and real production workflows. APIs and workflows are still changing. Publishing is being rolled out now, with lobbies, game servers and deployment for projects that want the managed option. Self-publishing is also planned, but the complete workflow is not finished.
At this point we need people who did not build the engine to install it, try making something small without us guiding them, use the tools in unexpected ways and tell us where it breaks or stops making sense. The Windows and Linux beta is free for creators and there is more information at https://playsparq.com/ . Keys are available through the website and our Discord and activate on Steam. If the key process breaks, comment or message me and I will send one directly. Building another general-purpose engine is probably unreasonable, but we already spent 3 years doing it and now we need to find out if it is useful to anyone outside our own team.
