Home | Documentation | Atomic Chat | Github

What is your impressions from Atomic game engine?


I’m new here so would like to ask a bunch of general questions. How would you compare it to Unity ? How mature is it, reliable, how easy to use ? How compatible it is with Blender ? How successful it is for Android ?


The Atomic Game Engine is still new. It is recommended that you use Spriter. I am also new to the Atomic Game Engine. I do have to say that the documentation isn’t good, also there are no real tutorials for it or training. So you would have to read the wiki and the document for C#, Javascript and the other scripting language that is currently available in the engine.

I am trying to teach myself Atomic so that I can start doing tutorials and improve the wiki for beginners. As far as I am aware Blender isn’t support. But I could be wrong.


The idea basically not bad, the Urho3d which is the engine behind the Atomic, seems relative good and not too big engine, and Atomic make the using of this a little bit easier. But it is under development, and many edges a little bit rough at this moment. The documentation is poor, the designer is not as sophisticated as Unity or for example the Godot. But the engine seems better then godot - az least to me was a little disappointment when I tried to run my first app on this engine, moving a sprite from the left side of the screen to right side, and it lagged on my PC - with 8GB RAM, 4 Core processor, NVidia 3D accelerated video card… I also tried Atomic, and my test apps runs good both on PC and on my android phone, without lagging.


Hello there gentlemen :slight_smile:

Here’s my honest input:

Depends on your requirements. In many aspects they are similar, they’re both fully featured game engines with somewhat high-level scripting and heavily cross-platform. Here are the main differences in my opinion:

Atomic Pros:

  • Modern C#, highly performant Mono or coreCLR on supported platforms as opposed to Unity’s stone age Mono, which includes a Garbage Collector so slow that brings anything heavy on processing to prohibitive performance levels.
  • The (native) engine performance is also an order of magnitude better. I’ll never understand why GameObjects are so heavy in Unity. In Atomic Nodes are as lightweight as it gets. Basically you have much more freedom to do things in a ‘naive’ way. Culled static nodes with no logic have almost no impact on processing.
  • Some of the best in class opensource libraries. SDL2, Bullet, Box2D, Recast/Detour, nothings libs, assimp, and a kickass renderer which although a bit outdated is comparable to bgfx in performance.
  • Full source code access with bindings generator. Need to draw a fully animated tilemap from data on managed side at the highest performance possible? No problem! Add a function to draw it directly in the C++ side with minimal data passing and it gets exposed on the managed side, so the heavy lifting has native performance. Found a bug and need to fix it immediately? No problem too. While Unity does license the source code, it’s a big ball of mud while Atomic’s elegant and simple.

Unity Pros:

  • The editor. Atomic is progressing quickly but Unity’s editor is ahead. It’s fully scriptable and the API is mature and well documented.
  • The asset store. Although a lot of assets have terrible quality, overall it’s a good resource to get things done quickly.
  • 3rd-party integrations. Ad networks, IAPs, social media, cloud services… they all have official ready-to-use plugins.
  • Documentation/Tutorials. Unity docs are far from perfect, but there’s no lack of tutorials, either official or not.
  • API. Unity lacks some pretty obvious features like Runtime Navmesh, Decals and Input, but the features that are there are fully documented and the API is more battle-tested.

It’s forked on Urho3D which is very mature and reliable.
If you have experience with game development, it’s not hard to use, besides some unusual namings, it’s pretty standard in terms of ECS and API.

I don’t think you can just drop a .blend file in the assets folder use it like in Unity. You’ll have to export your models. That being said apparently assimp does support blend files but I’m not sure if it’s up to date or otherwise the current state of the importer, but I think supporting blend files directly is a plausible feature for the future, as well as PSDs.

Not sure what you mean. I’m not aware of any ‘success’ stories on Android so far. In terms of deployment Android can be a pain in the rear but besides some possible annoyances it’s safe to assume in the worst case it’s just annoying/tedious to deploy on it. Android isn’t anything new at this point.

For 2D games, yes, Spriter and Tiled are two tools that could help tremendously. Sure, the documentation really needs work.

In terms of performance you’ll hardly beat Atomic. Only a hand-optimized custom native engine stand a chance. The core is extremely simple and efficient, there’s no obvious unnecessary overhead. I really believe Atomic is almost as efficient as it gets because it’s extremely simple/lightweight and yet employs all the optimizations you’d expect in a top notch engine.


I meant how buggy it is for Android (building for and executing on it). gattila said it’s alright there. Thanks guys.


Alan covered it pretty well. Atomic is rock solid under the hood, but needs lotsa improvements in its editor UI, docs and tutorials before it can really take off.

Longterm though, and this is what’s awesome, it’s in better shape than anything else out there to finally replace Unity/Unreal with a great FOSS engine. Which is what the future needs.

Use it and share what you learn and we will all march forward together. :wink:


Thanks for info. But it’s not so rock solid: I tried to launch two examples on Android. Basic3D example works. But Chickens isn’t working (just black screen). (Ubuntu 16.04)


Sorry, I meant ‘rock solid’ under the hood. Could have sworn I said that.

Building a desktop demo to “Android” and expecting it to run without any porting effort could be a pretty tall order for any cross-platform engine. Even Unity projects typically require a degree of refactoring to move from platform X to a specific flavor of Android or even a specific Android device.

But under the hood, Atom has solid Urho3D genes.


The chickens example may have a regression, it has run on Android in the past, here it is running on the NVIDIA Shield:

There is a lot of different Android hardware out there, though as the chest example runs, probably something specific to the chickens scene. I would suggest disabling nodes/components to narrow down what may be causing it.


After I scaled down textures (50% of size) it was able to work on my device. But I was unable to move camera by finger.


What core optimizations atomic has on top of urho? The quoted lines can’t be said for urho which is quite old and slow compared to modern engines, so i’m puzzled by that seeing that engines with fully multithreaded systems like mt rendering (bgfx for example) and physics engines (physx for example) while the core code that glue it all together is also fully async and mt should perform uncompatably better to urho, so if atomic is that fast i’m curious why because urho certainly isn’t.


I’m no rendering expert, but on what API? Because unless you’re talking about some very recent stuff we don’t support like Vulkan, multi-threaded rendering is not faster, and it might in fact be slower. I’m quite confident that on the rendering department we’re not that bad considering the current technology.

Regarding the other points, yep, running subsystems like AI and Physics on separated threads is certainly desirable, in the latter example there’s the problem of syncing, you could do like UE4 though and have a separated simulation for objects that aren’t an important part of the gameplay though.

I also agree that PhysX is a better physics engine and supporting multi-threading is huge these days. Plus it also has the edge in terms of hardware accelerated physics these days. PhysX is my go-to 3D engine these days without a question, along with Chipmunk which is also multi-threaded and faster than Box2D, the only caveat is the lack of CCD or any other speculative collision detection technique, but they are quite slow anyway, and in most cases you can approximate the shape with casts for a much more performant and reliable solution to tunneling, not to mention that CCD as implemented in Box2D is quite flawed compared to other speculative CDs which are 100% flawless like Humper.

EDIT: Oh, and do you have any numbers or otherwise tangible evidence to backup your claims?


modern rendering is fully multi-threaded